I'm preparing for an upgrade from TFS 2010 SP1 to TFS 2015. We've created new test servers and copied the db's to the new servers. I'm trying to run the PrepareClone command and get this error:
"Exception:Could not find stored procedure 'prc_GetServiceVersion'.
Command:EXEC prc_GetServiceVersion #serviceName=DatabaseManagement"
I'm not sure what do to do next, can I skip this step and run the ChangeServerIDs? I'm concerned there is something missing from the database and will run into issues later.
Make sure the PrepareClone command should be run before configuration, whether you move or clone TFS.
If you run it after configuration, you could end up with inconsistencies between content in your databases and content in your web.config file. Since the server of TFS2010 have been updated to TFS2015 during the Tfs_Configuration, there are different versions. However, the command are still pointing to the old TFS connection strings
.
If you have already configured your moved or cloned TFS deployment and realize you need to run the command, follow below steps:
First, quiesce your server.
Next, run PrepareClone command, ChangeServerID command, and then
RemapDBs command.
Finally, unquiesce your server.
If it still not work, you may need to restore the backups to the appropriate server, uninstall TFS 2015, install TFS 2010 on the same machine, and run the commands for PrepareClone, ChangeServerID, and RemapDBs.
Related
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.
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.
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