You should always have a realistic test environment where you can test updates and breaking changes. To make it as realistic as possible you need to update it regularly with data from the production environment. So why not use your normal SQL backup?
In this example I use an isolated environment, with its own domain controllers, clients and lab.
Please be aware that if the test environment can see the production environment, you can affect the production environment, if you haven’t changed the server names in your test environment.
In SQL manager restore the configuration and collection(s) databases.
Install TFS application tier, without configuring it.
Add the Service account, you want to use in the test environment.
TfsConfig Accounts /add /AccountType:ApplicationTier /account:tfsservice /SQLInstance:SQL01 /DatabaseName:TFS_Configuration
Start TFS server administrator console and configure the application tier and follow the wizard with changes to URL and server names. As you cannot change Reporting and Lab we skip those for now and change those settings after the initial setup.
When Application tier setup is completed, you can continue configure the other features if used.
Reporting: Just start the console and add reporting, with a new warehouse and analytic DB.
Lab: Remove any in-used settings run the following against the collection database.
set InUseCount = 0
where InUseCount <>'0'
Then you can remove the entire lab:
Tfsconfig.exe lab /delete /collectionName:defaultcollection
Go to the TFS console and add the lab with the new server settings.
To migrate the uses to the new domain it is possible to migrate the users:
tfsconfig identities /change /fromdomain:[proddomain] /todomain:[Testdomain] /account:[old useraccount] /toaccount:[new useraccount]
Wait for TFS to sync for identities sync and then login to your test environment with fresh data…