Logon failure: the user has not been granted the requested logon type at this computer

I’m currently on an engagement where I’m responsible for the design, architecture and implementation of TFS 2010 at a large Swedish financial institute.

As a first step we’re pair installing (me coaching and another guy doing the work) and configuring a TFS 2010 POC to make sure we identify all the potential challenges with the customers specific environment like AD, Policies etc.

Very well we make sure that we follow the exact installation instructions here and start our work installing SQL Server, SharePoint Foundation, TFS and lastly we configure TFS with the great new administration console. Everything looks great and no problems so far!

As a rule of thumb I always create a team project for each of the process templates that come with TFS to make sure that everything is truly working (so should you). Anyway the team project creation went perfect!

So before I go ahead and try to check-in some great code in Source Control I always try to connect to my team project portal to makes sure everything looks great, KABOOOOM!

Before we started this particular installation I told the guy I was pair installing with that if something was to go wrong it would most certainly be issues with connection to SQL Server Reporting Services. And as you can see below I was right:

image

Note: all pictures are taken from my own environment and not from customer

Here we go again I thought for myself…

I won’t bore you with all the details but after some investigation and after consulting my own virtualized TFS farm (on my bootable vhd by the way, read post here) I found that although we had granted the “reports” account the “Allow log on locally” as instructed there was a domain policy that denied the “reports” account the same rights as you can see in the picture below.

image

Note: all pictures are taken from my own environment and not from customer

We hade the AD-department make an exception for this account on this computer and just like that our problem was solved.

image

Note: all pictures are taken from my own environment and not from customer

This is just one solution for this type of problem and there are others like the password for the “reports” account being wrong etc. so make sure you check for other issues as well.

I’m sure I will remember to check for domain policies overriding the local policy the next time.

Cheers!

Hugo

Mysterious error from BTSTask.exe

So I’m currently working with a customer/partner that needs some help with building, deploying and testing BizTalk 2009 applications with TFS 2008 (other post will describe that solution) and as usual I start off in my own virtual environment where I test building, deploying and testing before I deliver the builds to the customer.

Anyway everything is working exactly like my own environment until the build script hits the “export BizTalk 2009 application as msi” section. I get this funny error message:

BizTalk Server Deployment
Error while exporting application  <my application> into MSI package. Function failed during execution…

So the first thing I try is running the same command that TFSBuild just ran in my own Command Prompt, and of course it runs without any errors. So I start looking for stuff that differs between my account and the TFSBuild service account. I go through all the permissions and security groups without any luck. So I continue with my search in the TFSBuild log and find that the temp directory for the service account looks a bit strange:

C:\users\ <TFSBuild Service Account>\Tmp\…

Can you see the problem?

There was a space in the name for the TFSBuild service account and that made the ExportApp function of BTSTask to fail. The solution in my case was to set the environment variables TEMP and TMP to nicer paths like C:\Temp or C:\Tmp and the build worked.

So don’t use spaces in your account names because you never know what problems you’ll run into.

Cheers!

Hugo