Table of Contents:
TFS2018 to AzureDevops 2019 Upgrade Part 1: Approach
TFS2018 to AzureDevops 2019 Upgrade Part 2: Create TFS Sandbox (this article)
TFS2018 to AzureDevops 2019 Upgrade Part 3: Upgrade sandbox instance to Azure Devops 2019
TFS2018 to AzureDevops 2019 Upgrade Part 4 Upgrade production instance to Azure Devops 2019
As stated in the previous note (Part 1: Approach), the objective here is to create a parallel TFS instance (sandbox) that is identical to (but separate from) production TFS instance.
Our production TFS instance (application and database tiers) are hosted on:
TFS application on Windows 2012 Standard Edition
TFS database on Windows 2012R2 on SQL 2016 SP1
In order to create a sandbox TFS instance, both the application and database virtual machines were provisioned to be identical to production TFS instances –same hardware configuration, same version of Windows OS and SQL database were installed.
The idea was to – (i) install a fresh instance of TFS2018.Update2; stop and detach the collection
(ii) detach the two databases that got created as part of installation and restore them from production backups and
(iii) execute a series of commands to align the newly attached databases to work with the installed instance of TFS2018.Update2.
Here is an image of the sequence of steps that were followed… I’ve provided details on these steps below.
Step1: Install TFS2018.Update2 on sandbox TFS instance
I proceeded with a fresh installation of TFS2018.Update2 on the application tier server. I won’t be listing down the steps here (there are enough guides available that provide a walk-through of how to install TFS2018.Update2)
I named the collection DefaultCollection, because that is the name of my production TFS collection. Below is an image of Administration Console after installation.
(although this is sandbox and the details are short-lived, I’m going to wipe out company specific details)
Step2: TFSServiceControl quiesce to stop all services
This command took about 4-5 minutes since a lot of related services were stopped.
Note: I navigated to the location where TfsServiceControl utility was located. In this case “C:\Program Files\Microsoft Team Foundation Server 2018\Tools” since the path was not added to environment variable.
Step3: Stop Collection
On the Administration Console I stopped the Collection as shown in below image.
…and provided a reason for the same.
Step4: Detach Collection
After stopping, I Detach-ed the Collection.
This opened a Detach Team Project Collection utility. The console prompted me to have a backup of the database being detached, followed by a verify.
And then Detach which took less than 15 seconds.
After detaching the collection this is how the Administration Console looked:
All the steps on TFS application server were completed and the next 2 steps were performed on the database server.
Step 5 and 6: Detach Tfs_Configuration and Tfs_DefaultCollection databases from DB Server and restore from production backup
On the database server, we noticed two newly created databases as part of fresh TFS2018.Update2 installation. These were Tfs_Configuration and Tfs_DefaultCollection. Since we were setting up a parallel instance (identical to production TFS), we had no use of these two databases and detached them from SQL server.
At this point the SQL server had no databases attached to it with the name Tfs_Configuration and Tfs_DefaultCollection. We then restored the production backup versions of the same two databases. This is an important step.
After both databases were restored, I moved back to the application server and tried to launch TFS Administration console wherein I was presented with the below error.
This error was expected and quite descriptive. The Tfs_Configuration database still had values from the production DB server and we needed to update them to align with the sandbox TFS DB server.
Note: Below series of commands had company specific details and hence I am providing some replacement variables for the sake of understanding.
${TFSApplicationInstance} = TFS application tier server
${TFSDatabaseInstance} = TFS database tier server
${TFSUserAccount} = service account under which TFS service run
Step 7: Remap database
TFSConfig RemapDBs /DatabaseName:${TFSDatabaseInstance}\TFSDB;Tfs_Configuration /SQLInstances:${TFSDatabaseInstance}\TFSDB /preview
Note: the command is being triggered with a “/preview” option.
This error was caused because the production backup of Tfs_DefaultCollection was not restored (instead the same Tfs_DefaultCollection that came with the fresh installation was re-attached) while the Tfs_Configuration DB was from the backup. This was an error on my part. The same command was triggered after (detaching wrong collection and) restoring the correct backup for Tfs_DefaultCollection which displayed a non error response.
This looked good and I executed the remap command without /preview option.
Step 8: Reset Owner
TFSConfig Accounts /ResetOwner /SQLInstance:${TFSDatabaseInstance}\TFSDB /DatabaseName:Tfs_Configuration
Step 9: Add accounts
It is always a good idea to run the sandbox TFS instance under a separate account than production TFS instance and we addressed that via the command below
TfsConfig Accounts /add /AccountType:ApplicationTier /account:${TFSUserAccount} /SQLInstance:${TFSDatabaseInstance}\TFSDB /DatabaseName:Tfs_Configuration
Step 10: Register Database
TfsConfig RegisterDB /SQLInstance:${TFSDatabaseInstance}\TFSDB /DatabaseName:Tfs_Configuration
I had the Administration Console (error message with code TF246083; image# 11 above) opened due to which the error in red below was thrown. I closed the console and re-ran the command -without any errors.
That was the end of re-configuration and I was ready to start services to see if everything was well consumed.
Step 11: TfsServiceControl unquiesce
…and everything went ok till there. After that I opened TFS Administration console once again to check.
AND THE CONSOLE CAME UP!!!
On further review I noticed the URL was pointed to Production TFS instance -I updated that to ${TFSApplicationInstance}. Inorder to do so I navigated to Application Tier and clicked on Change Public URL. After updating that, I Test-ed to make sure it responded -green tick.
Also, scheduled backups appeared to be configured. This was a setting that carried forward from production TFS instance. Since this was a sandbox instance, I felt there was no need for backups and disabled them.
TFS Administration Console -> Scheduled Backups -> Disable Scheduled Backups
The below page confirmed that no backups were scheduled.
I also checked the rest of the configuration values on the same page… (scrolled down) to make sure there were no values that referenced TFS production instance (application and database tiers), including the email sender.
On the database server, I checked the value in dbo.tbl_Database table in Tfs_Configuration database. It matched the one in the TFS Administration Console for sandbox instance and not TFS production instance.
After conducting all these checks, I was able to confirm that the sandbox TFS instance was as good as production TFS instance and that we were ready to move to the next step of upgrading sandbox TFS instance to AzureDevops 2019. Woohoo!!
My Devops Journal 