Tales from the trenches… or Tips for Team Foundation Server Installations in Dual Tier, Mixed x64/x86 and Multi-Domain Environments…

Yes, after reading that title you are probably thinking: wtf is he doing? But trust me this is not some fancy environment, just a formal development environment. See here:

devlab_tfs1

We have a production AD and run our own development lab domain. Our developers work in production and our servers are virtualized in devlab. We have decided to run a development sharepoint, so TFS will be using just that, and we decided to go two-tier (application is on TFS, and data tier is on it’s own database, in case we need to scale out later and because it’s cleaner).

So far so good, I soon found out that TFS can only be installed on a 32-bit machine, so I scrubbed the VM and had to restart. But this was going to be only the first of many problems I encounter. This is not going to be an in-depth report, rather more a summary of problems I had and solutions I found with some tips…

Always use a slipstreamed SP1 TFS Setup CD. Look around on the internet to find guides on how to do that. Otherwise there are problems with connecting to SQL Server 2008.

1. Use any kind of snapshot technology (we run on Hyper-V so that’s no problem) and don’t try to repair a “went wrong” installation of any of the involved systems. That causes more hassle than redoing some of the steps.

2. Read the installation guide and install Reporting Services on the application tier.

3. Switch of User Account Control (at least during setup) on all machines. That caused a couple of problems. 

4. When installing TFS remember to use http://sharepoint:80/sites (the full url with the port).

5. If you encounter problems with Reporting Services, start RS manager and delete the encryption keys. Yes, DELETE the encryption keys. TFS will manage that. Also make sure you aren’t running the database as Sharepoint Integrated mode, use Native instead.

6. In Multi-domain environments, where your servers are srvXYZ.devlab.local always use the fully qualified domain name during setup. Otherwise your developers Visual Studio will try to resolve srvXYZ.production.local which of course doesn’t work. It’s a pain in the a** to correct those values later. (For Reporting Services it’s actually a known bug that you can’t change it in SP1.) If you do want to do that use TfsAdminUtil (in TFS\Tools on your hard disk) and the option changeconnections.

7. Once installed, you need to install the WSS Extensions for TFS on the Sharepoint. The version on the TFS setup CD will not work on 64-bit, so go download the Powertools for TFS (generally a good idea) from here. Install that and you might run into an error, try following this guide to get those templates into WSS. (Resolution 1 worked for me.)

8. Ok, you have TFS ready, you have WSS ready and you probably only have one last step. Make sure you have an Alternative Access Mapping in Sharepoint (the FQDN) pointing to your default web application. If you have a site running at srv1, create an access mapping from srv1.devlab.local to srv1.

I think that’s most of what I encountered and I hope it helps someone else. If I remember anything else I’ll update this post.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s