TFS 2017 RTM upgrade process

It’s might not be surprising that TFS 2017 upgrade has changes at the process like elastic search installation as part of TFS search infrastructure.

But you may be surprised by the NEW ability to prepare a staging environment for the upgrade. Which means: You can restore the production databases to a new environment and the upgrade will fix and adjust the restored tables to the new machine (instead of manual steps of remap DB)

All steps shown below…

Enjoy! 

TFS 2017 Download: https://go.microsoft.com/fwlink/?LinkId=831912

You should typically do a test upgrade in a pre-production environment before upgrading your production TFS deployment. The pre-production upgrade scenario helps perform these test upgrades and protects your production environment from unexpected impacts. For example, the databases you are using for this pre-production upgrade contain pointers to various external resources - other databases, file shares, and so on. The pre-production upgrade scenario protects those production resources from being accessed or modified by the pre-production environment.

The pre-production upgrade scenario performs a number of tasks automatically that you cannot opt out of. Previously you had to manually perform these tasks - such as, tfsconfig remapdbs, tfsconfig changeserverid, and tfsconfig prepareclone. These tasks are enumerated below, and you can expand each of them to see more detail.

·        Automatic remapping database connection strings

When Team Foundation Server databases are moved to a different SQL instance, a set of internal database connection strings needs to be remapped to the new locations. This wizard will perform that step automatically. Manually running 'tfsconfig remapdbs' is no longer required unless the databases for this deployment are spread across multiple SQL instances.

·        Automatic changing of server collection identifiers

When a new Team Foundation Server deployment is created using existing databases and is in use concurrently with the original deployment, the identifiers associated with the deployment and the individual collections need to be updated. This wizard will perform that step automatically. Manually running 'tfsconfig changeserverid' is no longer required.

·        Automatic removal of scheduled backup jobs

When a new Team Foundation Server deployment is created using existing databases and is in use concurrently with the original deployment, scheduled backup jobs need to be removed in order to prevent the two deployments from competing with each other to write backups to the configured file share. This wizard will perform that step automatically. If you wish to set up new scheduled backups jobs, you should ensure that the file share used for this new deployment is different from the one used for the original deployment.

TFS strongly recommends several best practices for the pre-production upgrade scenario, but not all may apply to your situation. Best practices are indicated throughout the wizard by this symbol: V . The wizard applies smart defaults for each setting with an associated best practice. When you ignore one or more best practices, the wizard warns you at the end, and you need to confirm that you understand the risks of proceeding.

New search category at Administration Console