Move Team Foundation Server from One Hardware Configuration to Another
You can move TFS from one server to another by restoring it to the new hardware (also known as a restoration-based move). For example, you might want to move TFS to a server with greater capacity or improved processing speed, or you have concerns about the reliability of the hardware on which TFS is currently running. Moving TFS to a new server allows you to change the hardware that runs TFS without losing any of your project history.
To follow some of the steps in this procedure, you will need to have installed Update 2 or later for Team Foundation Server 2012. That update included the Scheduled Backups Wizard and the Restore Wizard, both of which are used as part of the move process. If for some reason you have not installed this update, you will need to follow the procedures for manually backing up and restoring your databases.
In some situations you might want to change the domain of a TFS deployment as well as its hardware. Changing the domain is an environment-based move, and you should never combine the two move types. First complete the hardware move, and then change the environment.
To perform a restoration-based move, complete the procedures in the following sections:
To perform the procedures in this topic, you must be a member of the following groups or have the following permissions:
A member of the Administrators security group on the server or servers that are running the administration console for Team Foundation.
Either a member of the SQL Server System Administrator security group or have your SQL Server Perform Back Up and Create Maintenance Plan permissions set to Allow on the instance of SQL Server that will host the databases.
A member of the sysadmin security group for the databases for Team Foundation and for the SQL Server Analysis Services database.
An authorized user of the TFS_Warehouse database.
If the deployment uses SharePoint Products, a member of the Farm Administrators group for the farm to which you are restoring the databases for SharePoint Products.
Stopping the services helps ensure that users cannot make changes to work items or check in source code to the original deployment during or after the move process.
To stop services that Team Foundation Server uses
On the server that is running the application-tier services for Team Foundation, open a Command Prompt window, and change directories to Drive:\%programfiles%\Microsoft Team Foundation Server 11.0\Tools.
Type the following command:
For more information, see TFSServiceControl Command.
Before you can move your deployment of Team Foundation Server, you must back up its databases. As part of the move, you will restore these databases to the new data-tier server. If you use reporting as part of your TFS deployment, the backup wizard will also give you the choice to back up the encryption key. Make sure that you do so, as you'll need it when restoring to the new server.
The Scheduled Backups page referenced in this procedure is part of Update 2. If you have not installed the latest updates for TFS, consider doing so. If you cannot install the latest updates, or other operational considerations preclude you from using the wizard, then skip this procedure and take a full manual backup instead.
Open the administration console for TFS and on the Scheduled Backups page, take a full backup. The backup will back up everything you configured for backup in your backup plan, but it will do so immediately, not according to the time scheduled in the plan. If your deployment uses reporting, you can back up the encryption key as part of this backup set.
(If you don't have backups configured, you'll have to create a plan before you can take a full backup.)
Once the backup completes, verify that the backup is available on the storage device or network share, and that you can access this backup from the new hardware.
To restore data for Team Foundation, you must install SQL Server on the computer to which you want to move the databases for Team Foundation Server. The version of SQL Server that you install must exactly match the version on the original server that hosted the databases, including service pack level, collation settings, and language edition. If the match is not exact, you might not be able to restore the data or Team Foundation Server might not operate correctly even if you can restore the data.
If you want to use more than one server to host the databases for Team Foundation Server, you must install and configure SQL Server accordingly, either as a farm or as individual servers.
Install SQL Server on the new server and make sure that it is operational. If your previous deployment used reporting, make sure that you include the reporting and analysis services components. You must install the same version and edition that you used previously, including service pack and cumulative update levels.
As an alternative, you can create an instance of SQL Server on a server that already has a matching version installed and restore the TFS databases to that instance, but that will require more post-restoration configuration.
For more information about options for installing and configuring SQL Server, go here.
After installing SQL Server, if your deployment includes reporting, open SQL Server Management Studio and detach the ReportServer and ReportServerTempDB databases. Otherwise you might not be able to restore these databases with the backup you created for the TFS databases.
To configure a new server or servers to act as the new application-tier, you must first install and configure the software that is required to support Team Foundation Server. This software includes the following components:
a supported operating system for your deployment configuration
SharePoint Products (if your deployment is integrated with SharePoint Products and you want to move it to the same server as TFS)
Unlike installing a new deployment of TFS, you will not be able to install SharePoint Products as part of the installation of the application tier when you move it to a new server. You must install the same version and edition of SharePoint Products that you used in your previous deployment.
Install and configure Windows, IIS (if not configured by default), and SharePoint (if using) in the new environment, and make sure that the server and its software are operational.
For more information, see the system requirements for Team Foundation Server and Move SharePoint to New Hardware for TFS.
In order to restore the TFS databases using the restore tool, you must install but not configure TFS on the new data-tier server, and then use the restore function in the Scheduled Backups node.
If you want to restore TFS databases manually using SQL Server restoration tools, you can, but that is a more difficult procedure. In addition, you will have to manually unquiesce the databases in the new deployment. The restore wizard in TFS is part of Update 2. It automatically unqueisces the databases as part of its restoration process, but that functionality is not part of SQL Server's restoration tools.
If you installed SharePoint Foundation 2010 using the steps in Move SharePoint to New Hardware for TFS, and you plan on using that server as the server for TFS, the installation bits and administration console will already be present on the server and you can skip the first two steps in this next procedure.
Launch the TFS installation media. On the Team Foundation Server Setup page, choose Install.
When the installation completes, the Team Foundation Server Configuration Center opens. Close it.
The administration console opens automatically in an unconfigured state. This is expected.
To start the Restore wizard, open the administration console for TFS and open Scheduled Backups.
Specify the path to the backup set and choose the set you created after quiescing the old deployment.
Complete the wizard and restore the databases to the new instance of SQL Server.
If your deployment uses SharePoint Products, you've already installed the same version and edition of SharePoint Products that you used in your previous deployment by following the steps in Move SharePoint to New Hardware for TFS, as mentioned above. Now, after you have restored the old deployment's content database (WSS_Content) to the new server as part of the restoration set, you must redirect the server that is running SharePoint Products to the new location of that database. This database must be operational before you can reconfigure Team Foundation Server with the new locations of its databases.
Open a Command Prompt as an administrator on the new hardware that is running SharePoint Foundation.
Change directories to Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\bin and run stsadm.exe with the following parameters, where SharePointFoundationServerName is the name of the server where you installed SharePoint Foundation 2010, and SQLServerName is the name of the server where you restored the WSS_Content database as part of restoring TFS databases:
stsadm.exe –o addcontentdb –url http://SharePointFoundationServerName/sites -databasename WSS_Content -databaseserver SQLServerName
After that command completes successfully, type the following command, where Domain\UserName is the account you used to install and configure SharePoint Foundation 2010 for use with TFS:
stsadm.exe -o addpermissionpolicy -url http://SharePointFoundationServerName -userlogin Domain\UserName -permissionlevel "full control"
From the administration console for TFS, choose Configure Installed Features to launch the configuration center.
Launch the Application-Tier Only wizard, and in Databases, specify the new SQL Server instance where you restored the TFS databases. Choose the Tfs_Configuration database from the list.
Before you close the final page of the wizard, look for the “i” symbol. It signifies information that you might want for future reference. The final page also includes the location of the configuration log.
You must update the service account for Team Foundation Server (TFSService) and the data sources account (TFSReports). Even if these accounts have not changed, you must update the information to help ensure that the identity and the format of the accounts are appropriate for the new server.
Open a Command Prompt window as an administrator and change directories to Drive:\%programfiles%\Microsoft Team Foundation Server 11.0\Tools.
At the command prompt, type the following command to add the service account for Team Foundation, where DatabaseName is the name of the configuration database (by default, TFS_Configuration):
TfsConfig Accounts /add /AccountType:ApplicationTier /account:AccountName /SQLInstance:ServerName /DatabaseName:DatabaseName
At the command prompt, type the following command to add the data sources account:
TfsConfig Accounts /add /AccountType:ReportingDataSource /account:AccountName /SQLInstance:ServerName /DatabaseName:DatabaseName
For more information, see Accounts Command.
If your deployment uses SharePoint Products and you moved SharePoint Foundation 2010 as part of the TFS move, you might need to redirect TFS to the new web application. Even if you don't, you should still repair the connection to help ensure proper performance.
If you're not using SharePoint Products as part of your deployment, or if your deployment will continue to use the old SharePoint server, you can skip this procedure.
Open the administration console and navigate to SharePoint Web Applications. If the web application still refers to the old site, or if your new deployment uses a different web application than the one listed, choose Change and update the settings.
If the information is correct, or after you have corrected it, choose Repair Connection. This helps ensure that everything is working properly.
If your deployment uses a report server, you must redirect Team Foundation Server to its location, restart the warehouse, and manually rebuild the database for Analysis Services. If you don't use reporting, skip this procedure.
Go to the Reporting node. The listed report server values are the old ones, not the new, so edit them.
Change the values on all three tabs to point to the new server. Make sure that you provide the correct information for the data sources account in the new deployment.
Choose Start Jobs to restart reporting.
Choose Start Rebuild to rebuild the warehouse.
Although you had backups scheduled for your old deployment, those scheduled backups weren't changed to back up your moved deployment. You'll need to configure them.
In the administration console, go to the Scheduled Backups node and reconfigure the scheduled backups to back up the TFS databases on the new server. For more information, see Create Back Up Schedule and Plan.
After you move to new hardware, make sure that all users, groups, and service accounts for your deployment are configured with the permissions that they require to function correctly on each server. Some permissions, such as additional permissions in SQL Server or on the local computer, cannot be automatically migrated. For example, Team Foundation administrators must be members of the local Administrators group on the application-tier server to open the administration console, so you must add manually them to that group.
Log on to the server and make sure that users, groups, and service accounts are configured with the permissions required for operation. Manually spot-check membership in project groups and teams, and verify that those groups and teams have the permissions you expect.
Browse to a team project collection and make sure that all projects in that collection appear as expected, and that users in those projects can appropriately access their work items.
Open Team Web Access and verify that team sites and teams appear as expected.
Not sure what groups and permissions to expect? For more information, see Add Users to Team Projects, Set Administrator Permissions for Team Project Collections, Set Administrator Permissions for Team Foundation Server, and Service Accounts and Dependencies in Team Foundation Server.
You can skip this procedure if the deployment that you are moving is not integrated with Microsoft Project Server. For more information, see Enable Data Flow Between Team Foundation Server and Microsoft Project Server.
If you intend to continue integration between the projects and collections and Project Server, you must register the instance of Project Web Access or Project Web App (PWA) with the application-tier server for your moved deployment.
To integrate the moved deployment with Project Server
Register an instance of Project Web Access or Project Web App with the moved deployment of Team Foundation Server by using the TFSAdmin ProjectServer /RegisterPWA command with the /tfs, /force, and /pwa options.
After you have registered the instance, you must wait for the data to synchronize. This process happens automatically on a predetermined schedule. For more information, see Overview of the Synchronization Process for Team Foundation Server and Project Server Integration, Change the Configuration of Your Deployment, Register an Instance of PWA to Team Foundation Server, and Remove a Component from Participating in Data Synchronization.
To refresh the data cache on client computers
Log on to the server, and use the ClientService Web service to force clients to update the cache for tracking work items and for version control.
For more information, see Refresh the Data Caches on Client Computers.
If you restored your databases to a different point in time, you will also need to refresh the version control cache.
Now that you've moved TFS, you'll need to tell your users how to connect to the moved deployment. Specifically, you'll need to give them the following information:
The name of the new server and the URL for Team Web Access, so that they can reconnect to their projects
The new database names for reporting, if reporting is part of your deployment
The new URL for SharePoint, if SharePoint is part of your deployment