Team Foundation Server Move Types
There are three supported move types for Team Foundation Server. The most common type is the restoration-based move, where a new installation of Team Foundation Server is configured on new hardware, and the data from your original Team Foundation Server deployment is restored to the new environment. A more simple type is the environment-based move, where an existing Team Foundation Server deployment is moved to a domain or to a workgroup. Finally, there is the single-server to more than one server move, where Team Foundation Server is moved from an installation on a single server to an installation across two or more servers. This is a specific type of restore-based move.
There are many reasons why you might consider moving your existing Team Foundation Server deployment. The most common reasons are as follows:
To increase the capacity of your Team Foundation Server deployment by moving Team Foundation Server from a single server to more than one server.
To incorporate new hardware, either with the same server names or with different server names.
To move Team Foundation Server from a workgroup to an Active Directory domain.
To move Team Foundation Server from one domain to another domain.
Team Foundation Server supports three different move types. All three move types require many steps. You should read through the procedures for each move type carefully before you try to move your Team Foundation Server deployment.
Restore-based move A new Team Foundation Server deployment is installed in the new environment. Backups of the original Team Foundation Server databases are restored to the new Team Foundation Server in the new environment. This move type is used to move to new hardware. Examples of hardware-based moves include:
Moving from one single-server deployment to another in the same domain.
Moving from one dual-server deployment to another in the same domain.
Restoring data from one data-tier server to another (dual-server deployments only).
Environment-based move An existing Team Foundation Server deployment is moved to a new environment by joining the server that is running Team Foundation Server to a domain or by changing the domain to which the server belongs. This move type does not involve changing hardware. Examples of environment-based moves include:
Moving a deployment from a workgroup to a domain
Moving a deployment from one domain to another
For specific steps, see How to: Move Your Deployment of Team Foundation Server from One Environment to Another.
Single-server to more than one server move This is a specific type of restore-based move. SQL Server is installed and configured on a new computer and the original single-server Team Foundation Server is converted into the server hosting the logical Team Foundation application-tier. Backups of the databases taken from the original single-server environment are restored to the new Team Foundation data-tier server. For specific steps, see How to: Move from a Single-Server to a Dual-Server Deployment.
You must decide which type of move best suits your business needs. Potential server move scenarios include the following:
Move a server from domain A to domain B If you do not change the hardware, this is an environment-based move type. You might do this if you evaluated Team Foundation Server in a test domain and you want to move the server to a production domain. Moving servers might also involve moving or recreating user accounts, group accounts, and permissions from the original server.
Move a single server from a workgroup to a domain This is an environment-based move type. You might do this if you deployed Team Foundation Server in a workgroup and then decided to implement an Active Directory domain. You can move local users from a workgroup to a domain if the same user account is in the domain, or if the user account exists as a local account on Team Foundation Server.
Replace the hardware in a Team Foundation Server deployment This is a restore-based move type. You might do this if you had to replace the hardware on which you installed Team Foundation Server.
Expand the capacity of your single-server Team Foundation Server deployment The move type for this is determined by whether you want to move your deployment to a faster server that has more capacity, or you want to move from a single-server deployment to more than one server. The former is a restore-based move, where the latter is a single-server to more than one server move. You might do this if you experienced poor performance on your current Team Foundation Server deployment and needed more capacity for users, projects, and data.
Moving your Team Foundation Server deployment requires careful planning and execution. For instance, combining a move from a Team Foundation Server single-server deployment to more than one server with a domain migration requires particular care. Also, keep in mind that Team Foundation Server stores configuration information in multiple locations. Be sure to follow the move steps carefully. For more information, see Team Foundation Server Security Architecture.
Considerations for Moving Your Team Foundation Server
If it is possible, keep the Team Foundation application-tier server name the same For environment-based moves and single-server to more than one server moves, keep the same name for the Team Foundation application-tier server if it is possible. Changing the Team Foundation application-tier server name adds the following complications:
Changing the Team Foundation application-tier server name requires that all Team Foundation clients must connect to a new server name.
All query-bound Microsoft Office documents will no longer work if the server name is changed. The documents are bound to the server for which they were created. This includes all the query bound Microsoft Office documents that are created automatically at project creation time in the project Documents node.
Any embedded links to documents will point to an unknown server name if the server name is changed.
For restore-based move types, the Team Foundation application-tier server name must be changed.
Moving users and service accounts As part of the security model, Team Foundation Server stores Windows identities (local and domain groups and users) by their security identifiers (SIDs). The Team Foundation Group Security Service regularly synchronizes the information stored in the TFSIntegration database based on SIDs as the unique identifier for each user. Therefore, depending on your move type, the SIDs in the TFSIntegration database might not be valid after the move. This is true if:
Local accounts existed on the original Team Foundation Server. You must decide whether these accounts will be recreated as local accounts on the moved Team Foundation Server, or as domain accounts in the moved Team Foundation Server's new domain.
Domain accounts existed on the original Team Foundation Server, but you are moving Team Foundation Server to a domain that does not trust the original domain. You must decide whether these accounts will be re-created as local accounts on the moved Team Foundation Server, or as domain accounts in the moved Team Foundation Server's new domain.
To maintain the existing set of Team Foundation Server users and groups and their assigned permissions, Team Foundation Server ships a command-line tool (TfsAdminUtil). One of the TFSAdminUtil commands updates each entry in the TFSIntegration database that uses a SID for the user account to an entry present in the new domain if it finds one. For more information, see TFSAdminUtil Command-Line Commands.
In order to successfully move Windows users and groups and their permissions with the TfsAdminUtil SID command, the users and groups must have the same account name in both the original Team Foundation Server environment and in the new domain. The tool does not let you define a mapping between account names for user moving purposes. It is also possible that as part of a move, the service accounts used by the original Team Foundation Server deployment will not be found in the moved Team Foundation Server deployment. To move the service account, you should use the TfsAdminUtil ChangeAccount command.
Prepare with a test run It is a good idea to test moving to a new environment with a test run exercise to help determine and troubleshoot any unforeseen issues. Your move scenarios and deployment environments might differ from those tested by Microsoft. Performing a test run will help you identify possible differences in the move steps that are particular to your deployment.