Freigeben über


Test TFS Upgrades: Pre-Production and Production Upgrade to Team Foundation Server (TFS) 2017.2

We received a lot of queries asking to clarify Pre-Production and Production upgrade to TFS 2017 Update 2.
This article explains step by step process to upgrade your current TFS (Minimum TFS 2012 RTM) to TFS 2017 update 2 in two stages, Pre-Production Test and use the same machine for a Production Upgrade.

Let’s first understand the types of upgrade,

Pre-Production Upgrade (Use this to test your upgrade. This process test upgrades the databases. You can use this to simultaneously test your TFS 2017 on another hardware while continue to use your existing older TFS up)
Note: This must be done on a copy of TFS databases on a separate server. It upgrades the databases to 2017 version. The intent is to test upgrade on a different server.  Also, this upgrade takes care of tfsconfig remapdbstfsconfig changeserverid and tfsconfig prepareclone which changes the GUIDs of the databases and avoid cross talk because there can’t be 2 instances of TFS/Collection with the same GUID. More information here.

Pre-production upgrade is mainly recommended because if we discover any glitches we can work through them so that we don’t encounter them in production upgrade. Once we have completed pre-production upgrade we can test the features and if everything looks good we can proceed for production upgrade. 
Production Upgrade (Once you are ready for upgrade, restore the databases again and use this mode) We have a new step-by-step article for in-place upgrade here

 

Note: Here are the system requirements to ensure you have the supported hardware/software configurations.

Permission Requirements:
The Account running the upgrade needs the following permissions.

  • Local Administrator on the Application Tier.
  • SysAdmin on SQL Data Tier.
  • For Reporting,
    • Ensure you have Report Manager and Local Admin on the report server permissions.
    • Ensure you have ServerAdmin Privilege on the Analysis Instance.
  • For SharePoint,
    • Ensure the account used for the upgrade is a Farm Admin

In this blog, I am upgrading my TFS 2015 RTM to TFS 2017 Update 2. Please note this article doesn’t include reporting and SharePoint. For reporting and SharePoint steps are very similar to previous versions for which you can refer to our previous blog.

Stage 1:
You must have *all* Tfs_Databases (Tfs_Configuration, Tfs_Collections, Tfs_Warehouse (if you have reporting) restored to the Database Engine.

Install TFS 2017
Download and Install TFS 2017. On existing TFS 2013/2015 installation, this installer will uninstall the older TFS version and install the 2017 binaries.

After successful installation, you will get TFS administration console

Click on “Configure installed features”

 

Since we already have databases backed up we are choosing second option “I have existing databases to use for this Team Foundation Server deployment”

Once the database server with TFS databases is specified, let’s select “Pre-production upgrade”

Note: When you create a test server/test your upgrade using Production databases, it’s recommended to change the GUIDs of the databases to avoid cross talk. More information here.
The Pre-Production Upgrade option takes care of the steps recommended to change the IDs and do a test upgrade, so we can have Production and Test running at the same time (IDs are changed in the Test upgrade)

You can specify the site settings and bindings directly from the wizard as per your requirement.

This is how the review of our configuration looks. If everything is as expected please proceed with ‘Verify’

Now we’re ready to “Configure”.

Note: The wizard will now update you if the Current Prod and Test URLs are the same. Be sure to change them for test upgrade.

Note: The warning here occurs when you upgrade from 2015.3 and before to TFS2017. In case you encounter this, users will need to manually migrate these Query Bases Suites (change query to use new Area Path naming convention which does not include ProjectName).

This completes our pre-production upgrade. You can use this setup to test TFS for new features/compatibility etc.,

Once you're ready to go live...

Stage 2:
In this phase we will use the same Application Tier/Data Tier to do the production upgrade.
First, we need to unconfigure TFS on the AT. A detailed explanation here.
Now you will see application tier is ready to be configured again.

But before that, delete the upgraded databases in test (Tfs_Configuration, Tfs_Collections, Tfs_Warehouse (if you have reporting) and restore them all again from production.

Go back to administration console and click “Configure installed features” and follow similar steps. Since in Stage 1 we have successfully tested the upgrade we can proceed with production upgrade and follow the familiar upgrade steps from before.

Production Upgrade option keeps the IDs intact. This means you cannot use the same set of databases to host another TFS server.

I am also configuring search feature here. This option is not available in pre-production upgrade. For more details on search feature refer to link

This completes our production upgrade!

Content: Shruti Sharanappa
Review: Manigandan Balachandran

Comments

  • Anonymous
    October 19, 2017
    What is confusing about the pre-production/production options is in many situations, production upgrades are done on new hardware. Many people wonder what option should be chosen. Since it is a production upgrade, the Production option should be chosen. The old instance will not be used anymore, but this post implies that none of the re-mapping happens when the Production option is selected. However, choosing the Production option on new hardware does work and the mappings are correct after the upgrade completes.
    • Anonymous
      October 20, 2017
      Hi Brian, Help us understand where the article "implies" Production upgrade does not remap. We clearly say, 'Production Upgrade option keeps the IDs intact. This means you cannot use the same set of databases to host another TFS server.'Production upgrade does re-map if the SQL Server is different/in a migration upgrade scenario. What it does not do is change IDs.
      • Anonymous
        October 24, 2017
        It is more around the wording of the pre-production and the production option in the wizard. I have been asked on a number of occasions if the production option should only be used on the same hardware as the original hardware. Of course, the production option can be used on new hardware. It is not so much the article as the wizard description. The confusion can be avoided by adding to the description that it can also be used for new hardware upgrades when the old server is being retired.