Complicated TFS 2017 Upgrade

Question

I wish to upgrade my current TFS 2015.3 instance to 2017. It's not going to be quite as easy as advertised, however, due to some complicating factors. My scenario appears to be undocumented.

1. I'll be installing a new domain controller (moving from Server Essentials 2012 R2 to Server Essentials 2016).
2. The current OS is Server 2012 R2; I will be upgrading this as well, to Server 2016 (a clean install to a new VM).
3. Both of these new VMs must retain the same NETBIOS names as before.
4. The current SQL Server instance is 2014; I will be upgrading this as well, to SQL Server 2016.
5. The SQL Server instance for the current TFS instance is on a separate VM. I would like to consolidate this and put everything on a single VM. (I'm a solo developer putting a very light load on my server and I want to shed the extra complexity and overhead.)

Is it merely a matter of installing TFS 2017 and restoring from a 2015.3-generated backup? Will 2017 automatically apply any schema changes etc. during the restore process? Could it be that simple?

The closest question I could find to this is here, but unfortunately it doesn't quite address my situation.

Gleda

Answer 1

Instead of doing a detach/attach upgrade there is another option available to you. detach/attach upgrades have had issues in the past and though most of these issues have been fixed, it's considered a suboptimal solution.

Instead, perform an Upgrade Installation.

Take a full backup of all your TFS 2015u3 databases and restore them to the new SQL server instance. You can create the full backup using the Team Foundation Server Admin Console, or use SQL Server Management Studio after stopping all TFS services on each Application Tier (in your case there is probably only one) using

TFSServiceControl quiesce

Now install TFS 2017 and perform the "upgrade" installation and point it to your existing databases. It will ask you if you want to upgrade them and whether you have a valid backup.

And after some time (upgrades can take a while, as data is moved around the databases), your TFS server will come back online. The installation wizard usually does all the mapping work required.

There is one big caveat, and that has to do with domain changes. If you are installing in the same Windows Active Directory domain, you're good. But if your server is running in Workgroup mode you may want to remap all the identities in your TFS database prior to running the upgrade step. So install TFS, but do not configure yet. Run the following command

TFSConfig Identities /change /fromdomain:Domain1 /todomain:Domain2

Then use the upgrade option to have TFS use your database backups. The full explanation on doing a cross domain server migration is documented on MSDN. Be sure to safeguard your pre-upgrade backup until you've verified a successful upgrade.

Mesolithic

This is also helpful, thank you. But I'm still not sure what folks are getting at when they say "take a backup." Does this mean a DB-level backup, using T-SQL, or instead does it mean the backup/restore feature at the TFS admin console? – Gleda

FYI I'll also be installing a new DC (I'm on Essentials 2012 R2 right now, and will be moving to Essentials 2016). I presume your warning still applies, even though the actual name of the domain (and DC name and TFS member server name) will remain the same. Correct? – Gleda

If the domain name and user names stay the same and if the domain server is added to the existing domain and then promoted to be the main AD controller before taking the old domain controller offline, you'll have no issues. If you install a new domain controller and manually recreate the users, the SID's of these users will be different and you will need to "fix them" or else they run the risk of being duplicated during upgrade (which can't be undone). – Mesolithic

"...the SIDs of these users will be different..." Rats. That's the way I'll be doing it. You can't do a DC promo that way with Essentials. How does one "fix them?" – Gleda

"A full backup created by the TFS Admin Console is a standard SQL backup." Gotcha. Thanks for the clarification. – Gleda

Let us continue this discussion in chat. – Mesolithic

I finally finished this. It went pretty smoothly, but even the Microsoft tech wasn't sure whether the user migrations to the new domain would go smoothly since the name of the old and new domains were the same. I did it like this: (1) Hardware move from _SERVER3 to _SERVER4, to get everything on the same VM; (2) TFS upgrade from 2015.3 to 2017.2; (3) Domain move from _SERVER4 to SERVER4; (4) Hardware move from SERVER4 to SERVER3. During the final move, on the advice of the Microsoft tech, I went from SQL 2014 to SQL 2016; the guidance is apparently incorrect about SQL versions. – Gleda

Answer 2

We face almost the same thing, as our server was created for TFS 2013 and therefore has SQL 2012 installed.

Yes, it actually is as easy as your question states. When you attach the collection that you restored form the backup all the schema changes will be applied. Before then you configure the app tier of TFS and skip

An important thing though is to detach the collection before doing the backup. This copies various configuration into the collection database so that it is self-contained and can be moved to another server. You then only move the collection database to the new server.

Here is how in list form:

1. Detach collection using TFS Admin Console
2. Backup collection database using SSMS, e.g. Tfs_YourCollection
3. Restore collection database on new server using SSMS
4. Install TFS
5. Configure app tier, skip creation of new DefaultCollection
6. Attach collection in the TFS Admin Console, might take some time depending on your collection size.

You can do 4+5 before 3.

Note: Changing domain can add complexity. SharePoint and Reporting sites are not migrated!

Foy

This is encouraging, thank you. I'll likely mark this as the answer, but I'm taking my time putting all of this together. Give me a couple of weeks, OK? I won't forget about you. – Gleda

It sounds like you're indicating a native DB-level backup/restore, instead of the TFS version of the same (which also manages the RS encryption key). Could you clarify? – Gleda

Do the domain user accounts used during the original SQL 2014 installation matter? Must I use the same ones for the SQL 2016 configuration or will any account do? – Gleda

@InteXX: Yes, I am talking about SQL Backup - will clarify the answer. I didn't know about the RS encryption key, but will investigate. The user doesn't matter as long as it has the right permissions on the SQL server instance. – Interactive

OK, thanks. Jesse (in this thread) is advising that I'll end up with user problems if I restore to a new AD domain (which I plan to do), unless I perform a set of complex domain move steps. But his suggestion involves not taking the detach/restore/attach route. Would you anticipate such problems if I choose the detach/restore/attach approach? – Gleda

Domain considerations are the same in both approaches. – Interactive

Tore, I decided to go with the Upgrade Installation as suggested by Jesse. I appreciate your suggestion, though. Thanks again. – Gleda