Plunging into .NET Development

Weblog Pieter Gheysens
Microsoft .NET Development - C# - Enterprise Library - Visual Studio 2005 Team System - Compuware DevPartner - ...

Saturday, June 14

scenario for upgrading to TFS 2008

Recently I had an assignment at a customer to upgrade their existing team development environment (Team Foundation Server 2005 Workgroup Edition) to a full blown Team Foundation Server 2008. TFS 2005 (Application Tier + Data Tier + Team Foundation Build) was installed on a Windows Server 2003 machine. That (virtual) machine survived already many years (+4) of active development and it clearly became time to foresee a hardware move for the development environment. The plan was to put in place a more powerful machine with Windows Server 2008. So, there were 2 options :
  • Installation Windows Server 2008 on new hardware - Installation TFS 2008 on Windows Server 2008 - Move Team Projects from TFS 2005 (old server) to TFS 2008 (new server)
  • Upgrade TFS 2005 to TFS 2008 on old hardware - Installation Windows Server 2008 on new hardware - Installation TFS 2008 on Windows Server 2008 - move upgraded TFS to new hardware configuration
There were a few special requirements I had to keep in mind, for instance the request to move as little as possible garbage to the new hardware configuration. So I decided to go for option 1 and do a completely fresh install of Team Foundation Server 2008 on the new hardware. That way, we would have the possibility to move only the Team Projects we needed and the customer was also only interested in moving the source code - Work Item tracking was not really used during development ... and at that time I was still confident that we could easily move Team Projects with the TFS to TFS Migration Tool, a community tool that's based on the TFS Migration and Synchronization Toolkit.

Everything went as expected until we had to move the Team Projects from the old server to the new server. I will save you all the details of what went wrong, but in short the tool (for now) isn't really suitable for big Team Projects with a lot of history. In fact - something I didn't know until now - the tool will replay all actions that occurred in the past and this will take a lot of time when you're project has been around for a couple of years. Different other issues came up that concluded us to switch to the second option.

The new TFS 2008 machine was already set up, so the next steps were to upgrade the old server to TFS 2008 and to move the upgraded TFS to the new hardware configuration. There is a guide available that takes you through the required steps to backup all TFS databases and restore them on the new environment, but it still remains a tedious job where your utmost attention is required. One wrong step could endanger the move to the new server, so follow the guide carefully. When I was finished doing this, everything seemed to work at first sight in the new environment ...

Not completely actually:
  • Old Team Projects were available, but creating new Team Projects with the wizard failed time after time due to an error during the Work Item Type Import (Error TF30170). After investigating the logfile I absolutely had no clue what was causing this and the inner exception I found resulted also in no hits in my favorite search engine. So, here's my entry in the TFS Work Item Tracking forum.
  • The next day, when the old server was put offline (Team Foundation website was already stopped before), the new Team Foundation Server on the new server stopped working. Connecting to the database wasn't possible anymore (error TF30041 : Team Foundation Server could not connect to the database). What?! The only possible explanation could be that the active Data-Tier was still the old server because putting the old server back online solved the connection problems. The guide I used for the move mentions the rename command for the Data-Tier Server and I was sure that it didn't raise any exceptions/warnings while executing this. Also after re-executing this command (TfsAdminUtil RenameDT newTeamFoundationDataTierServerName) it didn't seem to overcome the connection problems we were faced. So, we had to fix this the hard way without an automated command :
    • First thing to verify was the ConnectionString in the web.config of the Team Foundation Services (\Program Files\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\Services\). The Data Source in the ConnectionString should point to the new new server. In our case this setting was correct, so no manual changes here.
    • Next thing to verify was the server name that's entered in the TFS SQL Server Database TfsIntegration. In the table tbl_database all rows should have the new server value for the servername column. And that's what was wrong in our case : the active server name was still the old server name. Here we manually changed the value to the new server name, did a reboot of the server and everything was ok now - no more references to the old server.
Note that I do not recommend to manually edit data in the TFS SQL Server Databases. If possible, use the appropriate tools to get results, but here we bumped into the fact that TFSAdminUtil let us down.



Post a Comment

Links to this post:

Create a Link

<< Home