After deploying a clone of our productive TFS 2018 Update 3.2 on a new machine the application tier layer shows two machine names, the production machine and the clone machine. I followed the steps of this Microsoft Developer Support blog post.
In another Stackoverflow it was suggested to use TFSConfig PrepareClone, but this is deprecated for TFS 2018.
What can I do to remove the production application tier?
Related
How to migrate a TFVC project from TFS to AZDO ?
Goal:
Is to migrate host projects on (TFS 2017) using TFVC, to switch them to Azure DevOps Service (AZDO) using TFVC there too.
My context:
TFS 2017 server version 2 hosting current source projects.
AZDO 2019 service wanting to host projects targeted on TFS.
Context wish:
Keep the history of source projects (TFS) on AZDO services.
I Just want to migrated the projects (TFS) in TFVC to (AZDO) in TFVC, without doing any TFVC -> GIT conversion.
I would like to avoid updating the TFS 2017 server for 2018 then to
the AZDO server to switch to AZDO services afterwards.
You understand
that is a lot of step to just want to switch a project in TFVC on
TFS2017 to a TFVC on AZDO
The easiest way to migrate is to upgrade your TFS2017 server to Azure Devops Server 2019 and then using the full fidelity import feature to upload your whole database backup to Azure Devops Service.
At the moment migration tools support TFS2018u3 as well as Azure Devops Server 2019 and 2019u1 as well as 2020 can be imported into the service. We do these kinds of imports regularly and it's a very straightforward process to restore your TFS server backup to a temporary SQL server, install the correct version of TFS/Ads and have it perform the upgrade in-place during the installation. Then use the migration tools to import the collection into Azure Devops Server. Depending on the size of your collection this may take between a couple of minutes to a couple of hours. I've done the upgrade on my laptop on certain occasions as well, installing Azure Devops Server and SQL Server Developer edition directly on Windows 10. Even a trial versions will do.
For all the details on the. Import process, see:
https://learn.microsoft.com/en-us/azure/devops/migrate/migration-import
If you want to import your tfvc project from one TFS servers to another TFS server/Azure Devops Server, you can detach the project collection on you current TFS server and bacmup/restore the database on another server. It will automatically be upgraded
If your project collection has multiple projects, you can delete the projects you don't need after attaching and upgrading your collection.
There are a few tools to perform a history replay from one server to another, those tools can't import everything, your changes id's will change and you'll lose the exact date a commit was made (and possibly the user who made the commit if that account no longer exists). Tools like:
https://www.opshub.com/products/opshub-visual-studio-migration-utility/
Depending on how old and how big your collection is, it may take many hours to migrate the data. If data has previously been deleted/destroyed or branched across projects or edited during branch operations, then the replay may fail or may be forced to perform alternative actions, some of these operations are no longer supported. I've used opshub on a couple of projects and some it completely failed to migrate, others migrated with incomplete or incorrect data. This was 4 years ago, maybe these were bugs and they were fixed, but since the import tools have been released we've used those almost exclusively.
PS: using tfs-git to convert (part of) your TFVC repo to git would be an alternative which I'd recommend you look into further. TFVC has been declared feature complete and has received very little love in the past few years. It's not supported by the new Multi-stage YAML pipelines, the integration for VS Code has been deprecated, the cross platform commandline tool for tfvc has been deprecated and therefore support for eclipse and rider and intellij as well. Team Explorer in VS 2019 is now pushed to the background with the release of the new git features which have escaped the Team Explorer window. It's clear that TFVC is fighting for a lost cause and that Git is winning, you'll need to switch over at some point.
We are looking to carry out the following TFS upgrades in our Production environment:
Upgrade TFS 2010 to TFS 2013.5
Upgrade TFS 2013.5 to TFS 2019
To support both migrations, we have a Windows Server 2019 Standard edition to host the Application Tier. The Data Tier is to be installed on a dedicated SQL box.
The Microsoft website however lists Windows Server 2012 (Essentials, Standard, Datacenter) as the latest server operating system edition required for TFS 2013.
My question therefore is, can we still perform this planned upgrade to TFS 2013 on a newer edition of Windows Server, in our case Windows Server 2019 Standard edition?
I agree with Daniel, please follow the documentation exactly.
Since you can upgrade from TFS 2010 --> TFS 2012.3 --> TFS 2019, or from TFS 2010 --> TFS 2013.5 --> TFS 2019, you could consider trying to upgrade from TFS 2010 to TFS 2012.3 or TFS 2013.5 on the same Windows Server 2008 R2 Enterprise server, and then migrate to Windows Server 2019 Standard edition when upgrade to DevOps Server 2019.1.1(TFS 2019.1.1).
"Supported" means "tested and known to work". Later OS versions haven't been tested and may not work, or TFS may not even install in the first place.
I've done dozens of TFS upgrades in my day. My suggestion is to follow the documentation provided by Microsoft exactly. If an OS isn't listed as a supported OS, then don't use that OS.
So after much to-ing and fro-ing and numerous debates and suggestions from various sources on Stackoverflow, in the end this is how I managed to successfully complete my migration upgrade from TFS 2010 to Azure DevOps Server (TFS) 2019.1
There are however 5 very important points I wish to emphasise:
This was a complete migration upgrade (not an In-place upgrade) and so each move to a later TFS version was done using new/replacement hardware.
Both upgrades were done, based on the excellent YouTube tutorial by Mohamed Radwan which can be found here and relies heavily on the TFSBackup and TFSRestore utilities, both of which have shipped with all versions of TFS, I believe since the 2012 edition.
I only migrated the TfsConfiguration database and our Project database.
There was no migration of SharePoint.
There was no migration of Reporting Services.
We had no scheduled backups set up in the TFS 2010 Admin console.
TFS 2010 to TFS 2013 - Some Useful Points to Note
The backup of my TFS 2010 databases were executed from the Tools directory of the TFS 2013 instance (once installed), on the new dedicated hardware for my app tier.
Following a successful database restore using the TFSRestore utility, there are generally three key tasks required which use the TFSConfig tool to ensure data integrity between the two TFS instances aren't compromised or corrupted. These are the PrepareClone, ChangeServerID and RemapDB tasks executed in this same order.
The PrepareClone task failed when executed and after days of trying to troubleshoot the issue, I gave up in the end due mainly to the fact that the PrepareClone command removes information about scheduled backups, SharePoint, and Reporting resources from an Azure DevOps Server deployment and is used in two circumstances:
When you move a deployment to new hardware but want to keep using the old deployment.
When you clone an Azure DevOps Server deployment.
We didn't have any scheduled backups, SharePoint or Reporting Services included within the scope of our migration and were certainly not planning to keep using the old deployment long-term, except for a few days of validation and testing of the migration upgrade. As such, I ignored the error.
I was also counting on the fact that if the ChangeServerID command run successfully, this would ensure that the two instances were now discrete anyway, having been assigned unique GUIDs. Fortunately, the ChangeServerID task succeeded.
I also then executed the RemapDB command but in truth this wasn't even required as the ChangeServerID command had already completed the remapping task.
From this point on, the migration went like a dream and there was absolutely no issues encountered. Another key point to add, the backup of our TFS 2010 instance was done only after I'd ensured there was no user logged onto the system and following the backup, I took the 2010 instance completely offline.
TFS 2013 to Azure DevOps Server (TFS) 2019.1 - Some Useful Points to Note
Again using the TFSBackup and TFSRestore utilities (this time from the Azure DevOps Server 2019.1 Tools directory) and pretty much repeating the steps for the previous migration upgrade, I managed to get us onto our target 2019 instance without single hitch.
Even better, with Azure DevOps 2019, the TFSConfig PrepareClone, ChangeServerID and RemapDB tasks have been incorporated into the app tier configuration wizard, meaning you're not required to manually run them from the commandline. The tool takes care of it for you in its entirety, which is excellent!!
The new Pre-Production Upgrade option enabled me to simulate and somehow perform a dry-run of the final upgrade, another excellent feature incorporated into the Server Configuration Wizard for Azure DevOps Server 2019.1
My Concluding Remarks
Judging by how easy and simple it was to use, its heavy use of automation and clearly being far less likely to result in any disaster, I am rather surprised the TFSBackup and TFSRestore tools aren't recommended as perhaps the current best migration options, subject of course to the type of migration targeted.
I have done TFS upgrades in the past which were based on the older process of quiescing the project collection, detaching and re-attaching the database(s) to the target instance, etc, etc and must admit there's hardly any chance I'd be going back to that in future if I can help it, as the TFSBackup and TFSRestore tools are a much, much better, safer and reliable option in my view.
Hopefully, this feedback will help the next person who may embark on a similar journey to upgrade TFS from the 2010 edition to a later version.
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.
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 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.