0

I am carrying out a dry-run of an imminent TFS 2010 migration upgrade to TFS 2013.5 on a dedicated Windows Server 2012 R2 Datacenter host, following the steps in [this YouTube tutorial] (https://www.youtube.com/watch?v=nm-WOLc-GQQ) by Mohamed Radwan.

The intention is to keep the newly-implemented TFS 2013 running simultaneously with the TFS 2010 instance for a few days while we validate the migration upgrade. Once satisfied all's gone well, we'll then complete a full switch to the TFS 2013 instance and decommission the TFS 2010 instance which is implemented on a Windows Server 2008 R2 Enterprise.

The tutorial recommends using the TFSConfig Backup and Restore utilities to backup the existing TFS 2010 databases and reporting services key and then restoring them to my SQL Server 2014 instance on the TFS 2013 host.

Following the database and reporting key restore which has also completed successfully, I sought to adhere to the TFS cloning recommendation advised by various sources including Microsoft Support, by running in the following order, these TFSConfig commands:

  1. TFSConfig PrepareClone
  2. TFSConfig ChangeServerID
  3. TFSConfig RemapDB

Problem is, when I attempt running the PrepareClone command, I keep getting the TF30040 error message (as per this thread's subject title). On the few times that I've proceeded regardless and run the ChangeServerID and RemapDB commands however, they complete successfully.

I desperately need some help resolving this TF30040 error, as all attempts to apply some of the resolution steps proposed in other related incidents have failed miserably. It's important I find a resolution due to the fact we're intending to run the two instances for a few days while verifying and validating the TFS 2013 upgrade.

Another key question I have is whether it is mandatory that I successfully execute the TFS PrepareClone command, despite the fact I'm successful executing the ServerID and RemapDB commands? In other words, is it safe to ignore the PrepareClone failure and proceed with the simultaneous running of both TFS 2010 and TFS 2013 instances for those 2-3 days of validation testing?

jarlh
  • 42,561
  • 8
  • 45
  • 63
hitman126
  • 699
  • 1
  • 12
  • 43
  • How extensive are the customizations that y'all have made to your instance? Have you checked the DB's schema? I'm a bit worried that if you haven't upgraded since the 2010 version there may be a pretty insidious reason. – Ryanman Mar 04 '20 at 18:09
  • @Ryanman, so you think there may be a pretty insidious reason for an organisation not to have upgraded its TFS 2010 version to date? Seriously? What an absolutely ludicrous statement to make. Is it unheard of, illegal or against any law or regulation for an organisation to be using an older version of a system or application? I suppose there must also be a pretty insidious reason for people to be driving older cars, rather than affording to buy the latest, flashy models right? I was expecting some positive contribution to the thread......not such outlandish comments which frankly add no value. – hitman126 Mar 05 '20 at 09:17
  • ...There's no need to take this personally at all. Insidious is not the best word (I typed out what I hoped was helpful while triaging), but missing more than a decade of huge improvements may mean that y'all customized what you had quite a bit, making upgrading difficult or perhaps impossible in a traditional way. That's the crux of what I meant. The longer you go without upgrading, the more difficult it will be - as you can see. I also upvoted your question from a negative value to help out. Best of luck. – Ryanman Mar 05 '20 at 16:36

1 Answers1

0

If you don't run PrepareClone command, the original resources will be used by both the original and the new servers. If both the original and the new servers are live and point to the same SharePoint or reporting resources for any amount of time, you could end up with corrupted databases.

You may keep one server live at the same time. Or try to use a new service account that has no access to production environment to run the command:

TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:DatabaseName /notificationURL: ApplicationTierURL
Cece Dong - MSFT
  • 29,631
  • 1
  • 24
  • 39
  • We're not setting up TFS backups, using SharePoint or Reporting Services as part of our implementation anyway, @Cece Dong. Does that mean we can ignore the PrepareClone command entirely or the TF30040 error? – hitman126 Mar 06 '20 at 06:25
  • To be honest, I didn't meet this issue using PrepareClone command before. But if you don't run this command, it may still point to the old tfs connection, and impact your production database. Do you run this command before configuring AT of your cloned TFS? Did you try to use a new service account that has no access to production environment to run the command? – Cece Dong - MSFT Mar 06 '20 at 08:34
  • So just to give you a brief summary of what I've done. [1] Installed TFS 2013.5 on the server. However and this is the critical point, I have not configured the App Tier following the install. [2] Using the TFSBackup and TFSRestore utilities, I have backed up and successfully restored our 4 TFS 2010 databases (Tfs_Configuration, Tfs_DefaultCollection, ReportServer and ReportServer_TempDB) to the new data tier server, configured Reporting Services via the SQL Server 2014 Reporting Services configuration manager, restored the encryption key and then proceeded to run the three TFSConfig commands. – hitman126 Mar 06 '20 at 10:34
  • I can also confirm that I am using my user account (with Admin privileges) to run the command....not a service account. Does the command require only a service account to run by any chance? – hitman126 Mar 06 '20 at 10:38
  • Your process is correct. It doesn't require a service account but I met other community member having this issue solved this issue by creating a new service account that has no access to production environment to run the command, so I want you have a try. Is is possible that when you test new server, just shut down the old server? – Cece Dong - MSFT Mar 09 '20 at 03:43