I have been doing a number of upgrades over the last couple of months and have found that doing a migration to a test/dev environment is a good way to gauge the downtime needed to perform an upgrade on the TFS Collection databases.
This works well if you have a spare set of servers / VM’s lying around and you are able to do a full migration. I have been in a situation where a new application tier was not much of a problem, but they had an enterprise SQL server setup that we “had to” use.
Even though the “duplicating” of the collection databases is no problem at all, the tfs_configuration database is a different story.
The options are:
- Install a temporary SQL server on the application tier and simply use that for the tfs_config database or
- Duplicate the tfs_config and then either “point” tfs to the instance in question or select the correct database during (re)configuration
To perform option 2, simply create a backup of the tfs_configuration database and restore under a different name (on the same server). When you perform an upgrade or (re)configure the TFS application tier you have the option to select the “correct” config database:
If TFS is already configured and you want to change the database after the fact you can follow these steps:
- Open up command prompt (run-as admin)
- Go to the TFS tools directory (for 2015 the default is C:Program FilesMicrosoft Team Foundation Server 14.0Tools )
- Put TFS to “sleep” : TfsServiceControl.exe quiesce
- Backup and restore the config database to the new name
- Re-register the database : tfsconfig.exe registerdb /sqlInstance:<<sql-server>> /databaseName:<<new config db name>>
- Finally, wake TFS up : TfsServiceControl.exe unquiesce
That should have TFS pointing to the new config database, meaning you can have multiple TFS instances using different configuration database hosted on the same SQL server.
Need help upgrading ? : give us a shout