Udostępnij za pośrednictwem

Team Foundation Server 2010 Upgrade

  • Artykuł

Team Foundation Server 2010 is a major upgrade from the previous release and Beta2 was just released on MSDN (See Brian Harry's post for more information on the Beta2 release). Among the many new and updated features in this release is a set of Configuration Wizards. The Upgrade from Previous Release Wizard is the wizard to use when upgrading from TFS2005 and TFS2008.

There are two paths to choose from when upgrading to TFS 2010 Beta2: “In-Place” upgrade and “Migration” upgrade.

Path 1: In-Place Upgrade

An In-Place upgrade is defined as an upgrade where you use the same set of hardware that is running the current TFS version. In this scenario you will be uninstalling the current TFS version, upgrading any pre-req components such as SQL Server and SharePoint server, and then installing TFS and running the Upgrade Wizard.

Examples:

1.       Single Server - you are currently running TFS on a single server with SQL Server, SharePoint and Reporting Services/Analysis Services components. You would uninstall TFS and then install/upgrade TFS to Beta2 using the existing SQL Server, SharePoint and RS/AS components.

2.       Multi Server - you are using separate servers for TFS, SQL Server and SharePoint. You would uninstall TFS on the TFS Server and then install/upgrade TFS to Beta2 on that same server.

High level in-place upgrade steps (See the TFS Install guide for more details):

1.       Backup existing SQL databases

2.       Uninstall Team Foundation Server

3.       Upgrade to SQL Server 2008 (including Reporting Services and Analysis Services if using reporting)

4.       Upgrade to Windows SharePoint Services (WSS) 3.0 SP1 or later (if using portal)

5.       If using a separate SharePoint farm, uninstall existing Team Foundation Server Extensions for WSS and install TFS 2010 Extensions for WSS

6.       Run the TFS 2010 setup and select the Upgrade from Previous Version Wizard.

Path 2: Migration Upgrade

A Migration upgrade is defined as an upgrade where you using a separate duplicate set of hardware to perform the upgrade. In this scenario you will be installing the pre-req components, copying the existing TFS related databases over and then installing TFS and running the Upgrade Wizard.

Examples:

1.       Single Server - you are currently running TFS on a single server where all components are on this same server. For a migration upgrade you would set up a new separate server with the pre-req components (SQL Server, SharePoint, AS/RS), back up the TFS, SharePoint and Reporting databases from the existing server, restore them on the new server and then run the install/upgrade of TFS to Beta2.

2.       Multi Server – you are using separate servers for TFS, SQL Server and SharePoint. You would setup new servers for each separate component, backup the appropriate databases, restore them to the new servers and then run the install/upgrade of TFS to Beta2.

High level migration upgrade steps (See the TFS Install guide for more details):

1.       Backup existing SQL databases (TFS, SharePoint content, Warehouse and Reporting databases)

2.       On new hardware, install necessary TFS pre-reqs including OS, IIS, SQL Server 2008, SQL Reporting Services and Analysis Services and Windows SharePoint Services. (Note: The TFS Basic configuration will install SQL Express for you and doesn’t require Reporting Services or Windows SharePoint Services)

3.       Copy over backups from step #1 and restore databases on new hardware

4.       Configure SharePoint and SQL Reporting to connect and use these restored databases

5.       If using a separate SharePoint farm, uninstall existing Team Foundation Server Extensions for WSS and install TFS 2010 Extensions for WSS

6.       Run the TFS 2010 setup and select the Upgrade from Previous Version Wizard.

Which path to choose?

There are essentially three scenarios to choose from which will determine which upgrade path you follow:

Scenario 1: Testing Upgrade

In this scenario you want to test upgrade on a separate set of hardware while leaving the existing system running. For this scenario you follow the Migration Upgrade path. In addition you will also need to change the TFS database "stamp" on this new upgraded instance. All TFS instances have a GUID that identifies them (regardless of what url you use to acces them). Your clients will get confused if there are two TFS instances with the same GUID. To change the TFS GUID follow these commands:

1. Open a cmd window as admin on the AT

2. Change to the directory: “%programfiles%\Microsoft Team Foundation Server 2010\Tools” and run the following commands.

a. iisreset /stop

b. tfsconfig changeserverid /sqlinstance:<dataTierName> /databasename:Tfs_Configuration

c. tfsconfig registerdb /sqlinstance:<dataTierName> /databaseName:Tfs_Configuration

d. iisreset /start

e. net start tfsjobagent

You may also want to disable SharePoint and Reporting Services on the trial upgrade (using either the upgrade wizard to uncheck the options or from the TFS Admin Console after the fact), OR you could choose to copy the SharePoint and Reporting Services databases over to the trial instance before upgrade (See my post Quick Steps for a TFS 2010 Upgrade for more information on that.)

Scenario 2: Production Upgrade

In this scenario you are ready to upgrade your existing production system and plan to use the existing hardware. For this scenario you follow the In-Place Upgrade path. (Note that in this scenario that because you have to uninstall the existing version of TFS and the TFS 2010 upgrade is changing the existing data, “failing back” to that previous version of TFS will involve restoring the TFS databases from backup and re-installing the previous TFS version.)

Scenario 3: Production Upgrade with quick fall back plan

In this scenario you are going to move to new hardware at the same time as upgrading your production system, AND you will keeping the existing version of TFS running on the old hardware until the upgrade completes successfully. For this scenario you follow the Migration Upgrade path. (Note that the benefit of this scenario is that you can “fall back” and resume using the previous version of TFS on the old hardware if the upgrade fails.)

 

 

<o:p></o:p> 

Comments

  • Anonymous
    September 08, 2010
    Thanks Byran for these details, I used this for inpiration and detailed the whole process in a guide called'Rules To Better TFS 2010 Migration 'sharepoint.ssw.com.au/.../default.aspxAdamwww.ssw.com.au
  • Anonymous
    August 26, 2011
    thanks Bryan.  This helps a lot, but I could really use some more information on step 4 (configure sharepoint and sql reporting...) of your Migration Upgrade path.  I simply have no idea how to do that.