I'm doing both a hardware and a domain migration, as well as upgrading my TFS instance from 2015.3 to 2017.1. I first discussed this project (and received some VERY helpful suggestions) here.
Here’s the infrastructure I’ve got right now:
Hostname Operating System SERVER1 Hyper-V Host 2012 r2 SERVER2 Server Essentials 2012 R2 SERVER3 Server 2012 R2 (TFS 2015.3) DB Windows 10 (SQL 2014)
...and here’s what’s planned:
Hostname Operating System SERVER1 Hyper-V Host 2016 SERVER2 Server Essentials 2016 SERVER3 Server 2016 (TFS 2017.1 & SQL 2016)
The old and new domains carry the same descriptive name (e.g. DOMAIN). For the purposes of this Q&A, henceforth I'll refer to any VM on the old domain with a leading underbar (e.g. _SERVER3).
My problem is that the guidance for the hardware migration doesn't indicate whether the TFS Restore action can be run on a machine with a different NETBIOS name than the name of the machine on which the backup was taken.
I've set up a temporary _SERVER4 for this project, which I will join to the new domain as SERVER4 as part of the domain migration, but I don't know whether this will work. _SERVER3 has a different machine/domain SID, of course, which may confuse TFS if I restore to _SERVER4.
I'll then build up a new, clean SERVER3 on the new domain and restore from the backup taken on SERVER4. Same issue.
Is this really a problem—restoring a backup to a different machine name, same domain—or am I being too cautious and simply imagining a problem where one doesn't exist?
OK, this can work.
I'm now running a restored TFS instance error-free on _SERVER4, from a backup that was taken on _DB. It didn't come without a few hitches, though:
RS configuration by default requires a secure connection, a requirement which must be disabled:
When the database server name changes as well, we must perform a bit of a hack:
None of these requires an OS or service restart. Just apply the changes and try again.
As @jessehouwing indicates, there are some stops along the way in the Configuration Wizard where we have to update the server name. But all in all, other than the few little bumps listed above, the process went pretty smoothly. (And frequent checkpoints were absolutely vital to this success.)
Now for the domain migration... extra thanks to Jesse for all of his help with this.