2 days ago I did the following test upgrade from TFS 2005 to 2010 then to 2012 (I am not configuring Reporting or Sharepoint)
Backed up the 6 TFs 2005 databases
Restored them on the Sql 2008 server used by TFS 2010
Ran TFSconfig setup uninstall:ALL on the TFS 2010 application server (as I had a test site setup)
Opened the TFS 2010 admin window and did an upgrade
Detached my TFS2010 collection and did an import process to TFS2012
Yesterday, I wanted to try the process again to make sure that I had all the steps down.
So I did some initial cleanup
Deleted all the databases on the TFS 2010 Sql server
Detached the test collection on TFS 2012 and then delete the associated database
and then I restarted the steps but it gets stuck at step #4
Backed up the 6 TFs 2005 databases
Restored them on the Sql 2008 server used by TFS 2010
Ran TFSconfig setup uninstall:ALL on the TFS 2010 application server
Opened the TFS 2010 admin window and did an upgrade
The error I get on step #4 is
TF254024: No database for Team Foundation Serer that can be upgraded were found on the following instance... Verify that you specified the correct name of the server and the instance.
I've double checked the name of the server & instance.
Made sure that the account that is running the upgrade has full permissions.
I'm not sure what else to do. My searching hasn't proved that fruitful.
I figured out the issue.
When I was testing out the deploy the first time, we were trying to do a migration instead of an upgrade. We had added 2 extended properties to the master table from the TFSIntegration database (based on another error).
I removed both those extended properties and I was able to start the upgrade.
edit 1-
I tried the process again (restore database and try to do the upgrade). The extented properties were back again.
so running this script fixed the process.
USE TfsIntegration;
GO
EXEC sp_dropextendedproperty
#name = N'TFS_DATABASE_CATEGORIES';
GO
EXEC sp_dropextendedproperty
#name = N'TFS_INSTANCE';
GO
Related
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.
We are trying to upgrade our TFS 2013 Update 5 to TFS 2018 Update 2. I have checked this thread to make sure we meet the prerequisites.
From the list, it looks like we met the prerequisites, but when i run the TFS2018 installer it gives me an error saying there is no direct upgrade path from 2013 to 2018. Im not sure why we are getting this error when i looked at the Microsoft site, there is a direct upgrade from TFS2013 update 5 to TFS2018. What am i missing?
Here are our specs on our TFS 2013:
SQL: SQL Server 2016 SP2
OS: Windows Server 2012 R2
TFS: TFS 2013 Update5
P.S. we moved the databases to a SQL server 2016 from a 2014 SQL just to comply with the prerequisites.
Ahh yes, the added error message makes sense. What the TFS installer is telling you is that it can't perform the upgrade while TFS 2013 is installed and running on that server.
You first have to uninstall the Application Tier and Build Services on the machine. This doesn't impact your databases in any way.
Then you can install TFS 2018.2 or 3 directly into that server, point it to the existing SQL databases and it will ask you whether you want to upgrade those.
You'll need to verify a few server settings, plus decide whether you want to enable SSH and Search on this machine.
After the integrity check the installer will install the TFS Application tier and start the database upgrade process.
Only of you're on TFS 2005 or 20008 do you need to perform this step multiple times. first with the 2010 installer before you can take it to 2018. This is what's meant by 'not possible to do a direct upgrade' in some parts of the docs and which confused me at first.
I have TFS 2013 update 5 installed in a virtual environment (VMWare ESXi 5.5) and I wanted to test upgrading to TFS 2015. I cloned the VM and changed the TFS ID. After a long battle with sharepoint (everything is running on the same VM at this point, App-Tier, Data-Tier, and Sharepoint Foundation 2013) I got everything working again on the clone at TFS 2013 version. I then performed an in-place upgrade on this clone to upgrade it to 2015 and it worked perfectly.
Now what I want to do is take the most recent backup of the TFS2013 original server databases and move that to the already upgraded TFS2015 server. I have not been able to do this and successfully trigger "re-upgrading" of the database.
What databases should I restore to the clone "TFS2015" server (should I overwrite Tfs_configuration at this point, for example)?
What steps should I perform after restoring the latest backup from the TFS2013 data-tier to the TFS2015 data-tier to trigger an upgrade of the database?
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.
I have installed TFS 2010 on a new server (vmware running windows server 2008 r2) and restored from backup my old TFS 2005 Database onto the new server. The installation seems to have succeeded - I can create a NEW TFS 2010 team project and I can do checkin/checkout for it.
I made a mistake, however, with the TFS 2010 configuration manager - I ran the advanced configration wizard and NOT the upgrade wizard.
Now I don't see my old TFS 2005 team project and the upgrade wizard is now disabled.
In order to fix my mistake I tried this:
TFSServiceControl quiesce
tfsconfig import /sqlInstance:MyServer\DBinstanceName /collectionName:MyImported /confirmed
This is the output of this commands:
TF255152: Service is not running: TFSJobAgent
The upgrade of the project collection MyImported has been queued.
Waiting on the upgrade operation to complete.
...and now I am waiting for too much time for this operation to complete (my version control DB is 15 GB).
How can I import my old TFS 2005 team project to the new TFS 2010 server?
Here you go it supports inplace upgrades...
If you have to do a migration and it is currently jacked up then I would simply start from scratch. You'll spend far less time doing this than trying to fix the issues.
If you choose an install (advance configuration wizard in your case) instead of an upgrade, what happens is that new configuration and default collection databases are created for you, and your restored 2005 databases are not touched.
The safest way to deal with this issue is, like Chris suggested, to start from scratch. You wouldn't need to restore your 2005 databases again though, all you need to do is to uninstall TFS, make sure the new Tfs_Configuration and Tfs_DefaultCollection databases got deleted, and reinstall TFS and configure again with the Upgrade wizard. Installing TFS 2010 should be fast.