Maybe it’s me … maybe SSRS just doesn’t like me. But that has always seemed to be the most difficult piece of the whole Team Foundation Server integrated solution. But, now that I have that out of the way … I had challenges installing TFS into the production environment. Yes, I read the latest installation guide. I print out a checklist and go over it twice. I am well aware (from many bouts of swearing) that it is very important to make sure that you have everything in a row when installing TFS. Granted, it’s not as bad with 2008 as it was with 2005 (which was an improvement over the betas!!!), but it’s still something that you need to do.

Everything is checked. All the prereqs are installed. Did have one warning with the system scan though – it said that the processor on the app tier server wasn’t up to the recommended clock speed. Which was true. But there wasn’t just one processor … it has 4 Intel Xeon hyperthreaded processors in there! So I did ignore that.

Heading off to the races, we’re getting into the final stages of the TFS install … it’s installing Reporting Services. And it’s failing. Is it a security thing? Go check permissions for the account, make sure all is kosher there (it was). Still no go. What gives?

As it turned out, the backend Sql Server already had a default instance of Reporting Services registered to it (i.e. databases, etc) and I had not used an instance name for the TFS installation of reporting services on the app tier. Of course you have to have different instance names on the same box, but you also have to have different instance names from any Reporting Services instance that is registered/using your Data Tier server! I looked in the docs again and again … didn’t see it there. So, word to the wise: when installing Reporting Services for TFS on your App Tier server, check to make sure that there aren’t any instances of Reporting Services associated with your Data Tier server! If so, specify an instance name!

Here I was happily installing a test environment for TFS. One of the requirements for this environment is x64 so, of course, I’m installing as much as possible on x64. Of course, that does not include the TFS Application Tier … it’s 32-bit only and, while there are hacks out there to get it to install on x64, I’m avoiding that as a) it’s not supported and b) they require manually hacking the MSI file, something that I think is a Very Bad Idea. Part of this was installing TFS Build Services in Win2K3 x64; Win2K8 isn’t blessed in this environment, only Win2K3. In looking at the TFS Installation Guide, it does clearly say that TFS Build will run on x64 on WOW64 mode. And it does.

But … you may run into a little issue with installing TFS Build on x64. It’s the same issue described in this forum post. In shorts, here’s what happens:

You’re cruising along in the TFS Build install and all is hunky-dory.

You then get this error:

Microsoft Visual Studio 2008 Team Foundation Server Build Setup
Error 32000.The Commandline '"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe" -ga "[Domain]\[Account]"' returned non-zero value: 1.

Running the command manually gives you this:

[c:\windows\microsoft.net\framework\v2.0.50727]aspnet_regiis.exe -ga "[Domain]\[Account]"
Start granting SFINTERNAL\tfsbuild access to the IIS metabase and other directories used by ASP.NET.
An error has occurred: 0x800703f0 An attempt was made to reference a token that does not exist.

Keep in mind that this is IIS 6.0 on x64. By default, it’s running in 64-bit mode. And it won’t allow 32-bit applications. But … you are running aspnet_regiis from the x86 (32-but) installation folder. Hmmm … a clue perhaps? As it turns out, that’s the key to the solution. Here’s what you need to do (and it does not include a manual install): flip IIS 6.0 into 32-bit mode. Unlike IIS 7.0, IIS 6 does not support running both 32-bit and 64-bit applications at the same time. To do this, running the following from the command line:

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

When the installation is finished, you can flip IIS back to 64-bit mode – this seems to work just fine (so far, at least) by change the 1 to a 0.

Moving your TFS installation from a workgroup to an Active Directory domain? Good for you! Honestly, you shoulda started with the domain anyway but we’ll not go there right now. Maybe you didn’t have the domain in place in the beginning. I’ve been playing with the process. Well, I wouldn’t say playing as I’m not into inflicting pain on myself.

First step, of course, is to RTFM. There’s a decent article on MSDNon how to do that. When you read the article, it seems pretty straightforward. Not necessarily simple – it’ll make you wish you’d started out in a domain – but straightforward. Follow the steps and all should be good, right? Well, it’s all good on the TFS side. When you get to the end and you’re thinking to yourself “Phew … almost done with this” you come across this little tidbit at the end of the article:

No tools are available to automatically change SharePoint Products and Technologies and Reporting Services users and groups and their role memberships from local accounts (used in workgroups) to domain accounts. Although the local accounts will still work as local accounts, you might want to take advantage of the flexibility and management of Active Directory groups. Both SharePoint Products and Technologies and SQL Server Reporting Services will show the users and groups and their role memberships for each site or report folder. You can populate SharePoint Products and Technologies and Reporting Services to use new or existing Active Directory groups depending on your new deployment.

It’s so small that, in the context of the article, you just might miss it. And remember – you can’t edit permissions for SharePoint or Reporting Services from TFS Explorer; that’s why they have the TFS Admin tool. And that’s exactly what you have to do … go project by project and set the permissions for SharePoint and Reporting Services. If you have a lot of projects, this gets to be mind-numbing. This is a VERY good reason to use groups for your management!!! Even if they are local groups, you can put the domain members in there and be done with with … no TFS Admin tool required (except for setting up the initial permissions).

But wait, there’s more. The local machine administrators group doesn’t have access to any of the SharePoint sites for Team System!! So you have to log in to TFS with a local account that has admin rights on the SharePoint sites. And is a server admin on TFS as well. Then you can go about fixing up the permissions. One more thing – I was adding the local machine Administrators group to every SharePoint (Full Control) and Reporting Services (Content Manager) site. You cannot add BUILTIN\Administrators as the group into the TFS Admin Tool (it gives you an error) … you have to add the group as “.\Administrators”. But SharePoint doesn’t like that syntax for the local administrator’s group and fails when you try to apply permissions. Once you refresh the view. you’ll see the Administrators groups listed as “BUILTIN\Administrators” (then why couldn’t I just add it like that??). You can then set Full Control permissions for the SharePoint site and apply your changes.

I really hope that they improve the permission/security management story in TFS 2010. I’ve not seen anything about that, but it sure would be nice.

Edit: Forgot to mention this … you’ll also need to change the account for the SharePoint Timer Service to the domain account for the TFS Service. If you don’t, OWSTIMER.EXE will very happily eat your CPU cycles. Once I changed the account to the domain TFS Service account, all was good.