I plan on replacing my existing app tier (TFS 2010) when upgrading to TFS 2013. I'll quiesce the services and rename the old machine from MYTFS to MYTFS_OLD. The new app tier will have a fresh, un-configured installation of TFS 2013 and will be renamed from MYTFS_NEW to MYTFS.
My question is, will it be necessary to run the ChangeServerID or RemapDB commands if the new app tier is named the same as the old one?
If I understand your scenario correctly you will end up with:
A new server that's completely clean
The 'old' database server that contains all the TFS databases.
If that's the case, you should install TFS and select 'Upgrade'. You then point your TFS Application Tier to your database server and let TFS upgrade your databases.
You cannot have both version running on the same set of databases.
Study the ALM Ranger's Upgrade guide before doing anything.
I don't think you need to run remapdbs or changeserverid commands:
you typically need remapdbs when the server name changes which is not the case
you should use changeserverid if you plan to clone a TFS server meaning that you have restored TFS databases to a different machine and set up another TFS instance on that machine without killing the original server. Again it's not the case from what you have described here.
Related
I need to migrate a TFS 2013 instance to Azure DevOps Server 2019. I want to setup a new instance of Azure DevOps server with all the data migrated over from TFS 2013 and both the instances up and running at the same time. The plan is to decommission the TFS 2013 instance after a few weeks.
For testing purposes, I followed the steps below:
1. Setup a server in a completly isolated network.
2. Backed up the TFS 2013 databases using the scheduled backups from TFS admin console.
3. Restored the databases to a new instance of SQL Server 2017.
4. Started installation of Azure DevOps Server 2019 on the new server, I pointed it to the restored databases and it detected the schema and gave me two options: Production Upgrade and Pre-production upgrade testing. I chose the latter option.
The installation wizard took care of remapping the db connection strings(tfsconfig remapdbs), changing server and collection ids(tfsconfig changeserverid) and removed the scheduled backup jobs to avoid conflicts with the existing TFS 2013 instance.
The test migration completed successfully. Now, I want to setup the production instance on new servers that are within the same network as the existing TFS 2013 instance.
Shall I select "pre-production upgrade testing" again as I need to have both TFS 2013 and 2019 running at the same time?
Or Shall I select "Production Upgrade" this time? Is there anything I need to take care of during the upgrade so that the two instance don't conflict with each other?
PS: there are no backup jobs running on the TFS 2013 instance.
I tried the "Production upgrade" and understood that it will perform an in-place upgrade. In my scenario, I wanted to setup a separate new instance and the "Pre-Production Upgrade Testing" is the appropriate choice in this case as it automatically takes care of the remapping of database connection string and change server and collection identifiers.
We have a TFS 2013 instance that requires upgrading. I plan to use Azure DevOps 2019 on prem. I'd like to have the two environments running at the same time so I can verify. What I'd like to do is:
Do full install of Azure DevOps server, creating new DBs on a new SQL server. I do NOT want to upgrade our existing TFS at this point.
Copy the data from the original TFS SQL instance to the new SQL instance, performing an upgrade along the way.
Test and verify all data successfully migrated to 2019
Schedule a blackout window and repeat the import process once again
Can anybody advise if this is do-able or refer me to a guide?
Tks
Easier than I thought. Just needed to run the pre-production upgrade wizard.
Our TFS 2017 is hosted on a virtual machine (Windows Server 2012). We are planning to upgrade the TFS to 2018. I am planning to create a clone from the VM and running the clone as a second instance with own IP, server name, etc.
I am sure that this will create a nice clone, but I am not sure if this solution is a good way to create a clone of the TFS for upgrade testing. I believe that app- and data-tier still point to the source installation.
Has anyone tried that already and can give me a hand?
You should not clone the VM. Instead clone the TFS instance. There is a procedure to follow when you clone an instance of TFS 2017.
You should make backups of TFS DBs and restore them in a different machine or VM
You should restore and prepare the DBs by changing server IDs and mapping DBs (This step is utmost important to prevent corrupting your current production TFS instance). With TFS 2018 the clone creation is made easy as the configuration wizard will take care of change server IDs and mapping DB Steps.
Configure the cloned instance of TFS.
Do not try to make a copy of the VM and get it up and running which will corrupt both instances of TFS.
I found migration guide which uses command line. However, since there is no TFS server, I can't use the TFS migration tool.
A few workaround ideas I have ...
Can I export data from SQL Server directly and then import that into VSTS?
Can I install TFS (fresh new install on new VM) and connect to the existing SQL Server somehow?
I have no idea if above idea would work. If not, what possible options do I have?
Just reinstall the TFS application tier. When the wizard opens, you can choose "Application Tier Only" which will walk you through connecting it to the databases.
Make sure you reinstall the same version of TFS you were using before (including Update) -- if you were using TFS 2015 Update 3 before, reinstall TFS 2015 Update 3. Don't try to install Update 4 or Update 2.
We have created a VM clone of our TFS server (but haven't turned on networking yet for the clone).
We have created a test SQL server that we plan on using for the test upgrade.
I'm not sure what we should do first (after populating the tfs databases on the test SQL server).
Since our test TFS server is a VM clone, TFS is installed and configured already. The Cloned TFS server is pointing to our production SQL server. Are the following steps correct:
Turn on networking for the Cloned TFS server
Remote into the Cloned TFS server
Run command TFSServiceControl quiesce
Run the command TFSConfig PrepareClone
Run the command TFSConfig ChangeServer ID
Run the command TFSConfig RemapDBS
Update the TFS URLS in the admin console
Edit Reporting to point to the new test Reporting instance
Update all service accounts
Are the steps correct? I am not sure which order to carry out the steps out after the TFS databases have been put on the test SQL server. Any help would be greatly appreciated.
I would suggest doing the following:
Unconfigure your test server. I assume you don't want to upgrade your production server yet, you just want to test the upgrade, correct? If that's the case run 'TfsConfig.exe setup /Uninstall:All' to unconfigure the new server.
(if you haven't done it already) Backup all TFS databases from production server. You'll need all DBs with the names starting with 'Tfs_' including Tfs_Configuration, Tfs_Warehouse and all collection databases.
Restore TFS backups from production on VM or some other test SQL server (using SQL server management studio)
Run tfsconfig changeserverid command (on the new server) to change the TFS server id. It's required because you want to have both TFS instances live for some time. If you don't do it, VS clients will think that it's the same server (even though the name is different) and this can cause some issues.
Run tfsconfig remapdbs command (on the new server) which will fix the old Tfs_Configuration database. This is only required because you are moving TFS to a different machine (with a different name)
Now you can start TFS management console and perform the actual upgrade which is pretty straightforward. Upgrade wizard will ask you for the new service account names and new test reporting instance location.