Team Foundation Server 2008 qualifies as a showcase of sorts for the Microsoft platform.  It builds on several core elements of the enterprise stack, including SQL Server, Sharepoint, and IIS.  This results in a product that can be difficult to deploy and even more difficult to modify once it is deployed.

Microsoft provides a guide that documents procedures for moving all or a subset of the components, as it should.  Unfortunately, the tremendous flexibility enjoyed in deployment means that covering all possible scenarios becomes a virtually impossible task.

I am currently responsible for the TFS deployment at a client that I would describe as being of middling complexity.  It evolved from a single server deployment to a multi-server deployment.  This deployment has been moved around several times during server reorganizations and survived the upgrade from TFS 2005 to 2008.

Recently, as part of a move from SQL Server 2005 to 2008, it once again became necessary to relocate the data tier.  Just to keep things exciting, this move took place between two instances installed on the same machine (a default instance of SQL Server 2005, and a named instance of SQL Server 2008).  We did not perform an in-place upgrade of SQL Server 2005.  I am going to detail the steps involved in this process, but first I will provide a little background.  I am going to assume you are on TFS 2008 SP1 and WSS 3.0 SP2.

TFS platform background

Team Foundation Server 2008 comprises several tiers, to borrow the terminology of the documentation.  I prefer to look at the dependencies individually:

• Internet Information Services 6 or above – this is necessary for the core application services, really just a number of web services built on ASMX (and a companion Windows service), and for the optional Team System Web Access portal
• SQL Server 2005 or 2008
  • Engine – provides the platform for the databases
  • Analysis Services – data warehousing
  • Reporting Services – reporting
  • Agent – maintenance jobs that come out of the box
• Windows Sharepoint Services 3.0 – provides team sites with guidance and non-source related artifact storage

I won’t delve into the build services here, but those would obviously come into play if you were doing a complete move.  When planning a move of the databases, there are three groups of interest:  the Reporting Services databases, the Sharepoint databases, and the core databases (source control, work items, builds, etc.).

Reporting Services

I won’t spend too much time on this here, as our deployment was complicated by the existing SQL Server 2005 Reporting Services instance not uninstalling properly.  In TFS 2005, co-location of Reporting Services was required, but that is no longer the case with TFS 2008.

SQL Server 2008 Reporting Services is a big step up.  I have found the software to be much easier to install and configure than the 2005 version, which always seemed to have something that had to be cleaned up manually.  I do have one recommendation here:  go ahead and put the TFS reporting on its own instance of Report Server; it will save you the headache of having to move it later when you don’t want your project folders cluttering up another report server.

Install your instance of SSRS 2008 and select the option to manually configure it later.  Back up the SSRS 2005 encryption key and stop the 2005 service and associated app pool(s).  Move the databases to your SQL Server 2008 instance, either by detach/attach or backup/restore.  Go through the Reporting Services Configuration tool and point at the restored databases.  Restore the backed up encryption key and remove the other.  You should be able to activate this instance.

Now it is simply a question of executing TfsAdminUtil ConfigureConnections, setting ReportsUri and ReportServerUri appropriately.  Use the view switch of TfsAdminUtil to make sure of the format before changing the URIs and again afterwards to make sure the changes were correctly applied.  Test the reports to make sure they still run.  You may wish to double-check the data sources to make sure they are pointing to the correct server (wherever your data warehouse and core databases still reside).

Windows Sharepoint Services

The fun begins here.  The guide is rather vague in describing the most effective way to move the Sharepoint side of the house.  Most of what I learned about the best way to move Sharepoint came from Sharepoint documentation and forums.  While many companies may have the benefit of having staff experienced in WSS, I know that many smaller shops (or larger shops where the Sharepoint administrators don’t want TFS rolled in with the existing deployment) may not enjoy that advantage.

I will provide a little background context as to database configuration for WSS 3.0 (MOSS is similar but I have never attempted a TFS deployment on MOSS before, so I will avoid embarrassing myself). 

A good place to start is the TechNet guide for moving all of the Sharepoint databases.  If you want to go that route, you probably can follow the guide pretty closely and have a successful move, but the whole aliasing approach seems unclean to me, not to mention that it breaks down under more complex move scenarios.

A typical Sharepoint install consists of the content databases, the search database, the Central Administration content database, and the configuration database.  The content databases, usually called WSS_Content (with or without an additional underscore and a GUID) or STS_Content_TFS (if you used the TFS install process rather than using an existing WSS installation), contain all of the project sites and associated content.  The search database (which may be named WSS_Search or similar) can be moved, but I would not bother as it is necessary to allow the sites to be recrawled regardless.  The Central Administration content database (usually called Sharepoint_AdminContent_{guid}) as well as the configuration database (usually called WSS_Config or STS_Config_TFS) should not be moved under normal circumstances.  You actually can follow the recommended procedures here as to how best to document configuration settings if you have done a lot of customization, or you can turn to a shadow copy solution such as System Center Data Protection Manager or the Backup Exec Agent for Sharepoint.

This leaves the content database(s), and I suggest you follow the guide for moving these between instances of SQL Server.  As for which farm you reattach to, I will leave that for you to decide.  If you wish to continue using the same server to host Sharepoint, you may wish to remove the farm on that server and create a new one using the Sharepoint Products and Technologies Configuration Wizard, or you can establish a new farm on a different server.  Either way you will want to choose the web front-end option rather than stand-alone.  If you are reinstalling on the same machine, keep in mind that you may need to delete the existing application pools/sites to avoid a possible error.

After you get your new farm set up, you continue with the move instructions discussed above to reattach the content databases.  Since the point of this guide is to upgrade to SQL Server 2008, you might as well bump the compatibility level of your databases after you move them.  It is also necessary to install the TFS Sharepoint extensions (I am not sure a reinstall is necessary if you used the same machine, but I would recommend it).  Keep in mind that you will need to get the download from the Power Tools if you are installing on a 64-bit server (MOSS 2007 users may wish to refer to this blog entry).  You will also need to reinstall any custom templates you may be using.

If you used a different server for your Sharepoint installation, the last step is establishing connectivity between the TFS application tier and your new location.  You will need to use the TfsAdminUtil ConfigureConnections command with the appropriate Sharepoint switches (SharepointUri, SharepointSitesUri, SharepointAdminUri, and SharepointUnc).

TFS Databases

The last step in the process involves moving the core TFS databases.  If you start by following the guide, you will get most of the way through this.  You will detach and move or backup and restore the core TFS databases (TfsBuild, TfsIntegration, TfsVersionControl, TfsWarehouse, TfsWorkItemTracking, TfsWorkItemTrackingAttachments, and TfsActivityLogging).  Take this opportunity to go ahead and change the database compatibility level to 100 (SQL Server 2008).

This is where things get interesting.  After you have followed the instructions and run TfsAdminUtil RenameDT and ActivateAT (yes, you should go ahead and run ActivateAT even if you haven’t moved the application tier), you will need to rebuild the data warehouse cube.  If your application tier does not reside on the same box as the data tier, you will probably need to install the Analysis Management Objects (AMO) for SQL Server 2008.  You will also need to make some changes to the web.config files in the warehouse web service folder and the SetupWarehouse.exe folder.  Now you can proceed with rebuilding the cube as directed.

When you go to verify that the reports are accessible, you will want to verify that the reporting data sources are set correctly.  At this point, you will find that several of the reports fail.  New versions of the reports that work correctly with SQL Server 2008 are available here.  Unfortunately, the directions in that package of corrected reports direct you to replace the reports one at a time by hand through the Report Manager interface.  This is a tedious task if you have more than a couple of projects, so I would suggest you find a machine with the SQL Server 2008 Business Intelligence Development Studio installed.  Once you have fired up BIDS, create a reporting project, create two shared data sources that mirror the two TFS data sources on the report server exactly, and add the downloaded files that are appropriate to the template you are using (Agile or CMMI).  Then right click on the project and point the targets to the root of your TFS reporting instance for the data sources and the appropriate path for your first project.  Once you have applied those changes, right click on the project and deploy the reports.  This will replace the existing reports with the corrected versions.  Then repeat the process for each project you have.

The last thing you may wish to do is make sure that the SQL Server Agent jobs for TFS maintenance exist on the new database server.  In my case they weren’t there, so I needed to use the Object Viewer Details window in SQL Server Management Studio to script all of them and move them to the new server.

Good luck and if you have any trouble with the directions, have any other tips to share, or have general questions please feel free to leave a comment or contact me.

I hope to address this question in this new site.  This site serves as the new home of my analysis as both an end-user and a technologist.  I expect this analysis to be interspersed with tips and experience across a broad range of technology topics, from Visual Studio and SQL Server to Zune and Windows Mobile.

So relax, enjoy, and join me on this journey.  Subscribe to the site’s feed, follow me on twitter, and let the games begin.