Creating a new server from an old one: Beware of the InstanceId

[UPDATE 8/23/14] The MSDN topic Move Team Foundation Server has the information about cloning TFS 2013. Today, that info is in the Q&A section at the bottom of that page.

[This post contains instructions for TFS 2005/2008 and TFS 2010, which is in a separate section below]

Grant Holliday wrote a post called, TFS InstanceId, ServerMap.xml and havoc.  In it he describes his experience with backing up a production server and restoring it to a test environment.  The problem he ran into is that every server has a unique ID called an InstanceId, which is just a GUID.  That GUID is the real name of a server, as all other names can change for any number of reasons, from renaming a server to internet vs. intranet access.

Grant references the MSDN forum post where Keith Hill ran into the same issue.  By far, the common case is restoring the same server, perhaps after a hardware failure.  In that case, you absolutely don't want to change the InstanceId.

However, if you want a copy of your server to experiment with or you're trying to split a server by cloning it and deleting what you don't want (Keith's scenario), the situation is a little different.  We've done this a number of times internally where we take a backup the dogfood server and restore it to a pre-production test machine.  In such a case, we'd change the InstanceId in the pre-production test machine so that there's no confusion with the real server (it's important that the ID in the test server be changed -- not the other way around :-).

Unfortunately, I don't believe that we have released a tool that will change the InstanceId.  I've sent email to a few folks to make sure I'm not simply forgetting something.  I'll post a follow up if there's anything available to change it, as that's what's needed when "splitting" a server.

For now, the best approach for creating a test server is to make sure that the machines that access the test server aren't also used to access the real server.  If in testing you need to switch between the two, you'll need to delete the cache directory, as Grant noted.  To do that, delete the directory %userprofile%Local SettingsApplication DataMicrosoftTeam Foundation1.0Cache (%userprofile% is typically c:Documents and Settings<your login>).  That will delete the ServerMap.xml file, which caches server name and InstanceId pairs, the work item tracking cache that's partitioned by InstanceId, and the version control cache file VersionControl.config that contains a list of workspaces per server InstanceId.

TFS 2005 and TFS 2008 instructions

The forum thread that James Manning references below shows how to change the InstanceId using the instanceinfo.exe tool.  Here are Dan Kershaw's instructions from that thread.

It's really important to make sure that you change the InstanceId in the correct data tier, such as the test server or the new separate server created by restoring the databases mentioned above.  You do not want to change the InstanceId when just restoring a production server that folks are using (if you do, you'll have to go clear every user's local cache directory).

I double checked with one of our devs and there is a way to "restamp" the cloned machine using a shipping command-line tool called InstanceInfo.exe (which can be found under the TFS install directory in the Tools folder on the Application Tier machine - along with the other server command line tools, like TFsAdminUtil).  You should restamp the server after following the other "move" steps.

After making this change it should be safe to connect a client to both the original server and the cloned server.  Here are the instructions (please replace the variables with your own settings).

If you are doing this with TFS 2005, you'll need to remove TfsWarehouse from the list.

Rem Clear the instance info

“%TFSInstallDir%ToolsInstanceInfo.exe" stamp /setup /install /rollback /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration,TfsWarehouse /s <<your new data tier>>

Rem Re-stamp it with a new instance id

"% TFSInstallDir %ToolsInstanceInfo.exe" stamp /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration,TfsWarehouse /s <<your new data tier>>

TFS 2010 instructions

In TFS 2010 the concept is the same, only more of it.  The IDs in the configuration database and each of the collection databases must be changed.  Fortunately, a single command will handle all of that: changeServerID.  Here are the steps that you need to follow.

  1. Open a cmd window as admin on the AT
  2. Change to the directory: “%programfiles%Microsoft Team Foundation Server 2010Tools” and run the following commands.
  3. iisreset /stop
  4. tfsconfig changeserverid /sqlinstance:<dataTierName> /databasename:Tfs_Configuration
  5. tfsconfig registerdb /sqlinstance:<dataTierName> /databaseName:Tfs_Configuration
  6. iisreset /start
  7. net start tfsjobagent

SharePoint and Reporting Services configuration data remains in tact, so you will need to go into the administration console and disable them.  Once you open the Team Foundation Server Administration Console, you'll see a node for each in the tree.

TFS 2013 instructions

Follow the commands that are shown in Q&A on the MSDN page for moving a server:

[UPDATE 1/21/09]  I've added the warehouse DB to the list.  Thanks for the comment, Wendell!

[UPDATE 2/8/2009]  If you have used build prior to creating a clone of the server, watch out for the TF214007: No build was found with the URI problem Mac Noland ran into.

[UPDATE 7/17/2009]  I've added a note about dealing with TFS 2005 (remove TfsWarehouse from the command line).  Thanks for the comment, Lim!

[UPDATE 1/22/2010]  I've now added instructions for TFS 2010.

tags: ,

Comments (27)

  1. Thys says:

    If InstanceID of the server is the same as the called SID, then you can use Sysinternal’s tool NewSID. Also very useful for making copies of a virtual server.

  2. There should already be tool to change the guid called InstanceInfo.exe – Dan Kershaw already mentioned it in a forum thread.

    Here’s the relevant bit:

    I double checked with one of our devs and there is a way to "restamp" the cloned machine using a shipping command-line tool called InstanceInfo.exe (which can be found under the TFS install directory in the Tools folder on the Application Tier machine – along with the other server command line tools, like TFsAdminUtil).  You should restamp the server after following the other "move" steps.

  3. buckh says:

    Thys, the InstanceId is a GUID stored in the database, so it’s independent of the Windows SID.


  4. buckh says:

    James, thanks for pointing that out.  I couldn’t find anything last night.


  5. Etienne Tremblay on Team Build the ins and outs and TFS Install Scripts V2. Sanjeev Garg on So I am…

  6. Aunque en MSDN hay un artículo que explica el proceso de restauración de un TFS, un punto en tomar en…

  7. DavidKean_MS (Moderator): The Visual Studio Team System chat will begin in 15 minutes. DavidKean_MS…

  8. SRLTeam says:

    I&#39;ve been trying to figure out some issue: I choose TFS server (connect TFS server from VSTS), I

  9. Wendell with MSFT TFS Support says:

    The TFS_Instance GUID is also an extended property of the TfsWarehouse database in TFS 2008.  Make sure this value is also updated when you "clone" your server.  You can add TfsWarehouse to the comma delimited list of databases you are running the utility against.

  10. buckh says:

    Wendell, I’ve updated the post.  Thanks!


  11. randy kibbe says:

    I was hoping someone could help. We had our TFS AT on a virtual server that got deleted! I recreated another virtual server with the same name and IP. When trying to re-install the AT I get this message:An existing Team Foundation database was found, but it cannot be upgraded. Installation cannot continue.

    It seems to think I am trying to perform an upgrade even though I am just re-installing the same TFS2008 again.

    Any ideas ?

  12. buckh says:

    Randy, I would suggest using the integrated installation of TFS 2008 SP1.  If you had applied SP1 before, you would need to do this to install it and use the existing databases.


  13. H'ng Lim Shen says:


    I think adding TfsWarehouse as suggested by Wendell is only valid for TFS 2008.

    I tried running the same command line with TFS 2005 and got the following error:

    Exception clearing instance id on database TfsWarehouse: System.Data.SqlClient.SqlException: Could not find stored procedure ‘ClearInstanceInfo’.

    I looked into the TfsWarehouse database in TFS 2005 and could not find the ClearInstanceInfo stored procedure either.

    The utility ran fine after I removed TfsWarehouse from the list and after updating the InstanceID, it appears my Team Explorer is no longer confused between the old and new server!

    Thanks for posting this bit of info. It helped me a lot.

    ~Lim Shen

  14. buckh says:

    Lim, glad to hear it.  I’ve updated the post to mention the difference with 2005.  Thanks for the comment.


  15. Joseph-w says:

    Please help

    It looks like you have a lot of experience with the scenario, we are looking to do the same creating a test env from our prod. We have a 2 tier deployment – app tier (2008 OS, RS, MOS 2007, TFS) data tier (2008 OS, SQL 2008 st).

    On the data tier we installed the os, sql and restored the db from production, on the app tier we just cloned and renamed the server, I’m lost in what do I have to do first to make this work, do I first fix the MOS on the app so SharePoint will function then reconfigure RS and then use the TFSconfig to redirect everything? I couldn’t find a post that describes step by step what to do after you clone the app tier giving the app tier also hosts the SharePoint and Reporting Services.

  16. buckh says:

    Joseph, for SharePoint and MOSS, you'd want to follow the instructions for those to clone them.  In most cases, folks don't clone those.


  17. Very useful information.

    However, for TFS 2010 but still having problems with Reporting Services.

    Had to rebuild the Warehouse on the production server to restore service.

  18. rahul sen says:

    Unfortunately,I am getting the following error on changeserverid:

    Unable to clone collection 'DefaultCollection' because of the following error.

    Error occurred while executing servicing step Prepare TestIntegration for a snap

    shot operation for component Snapshot.TfsLabExecution during Snapshot: TF246017:

    Team Foundation Server could not connect to the database. Verify that the serve

    r that is hosting the database is operational, and that network problems are not

    blocking communication with the server.

    Successfully cloned 0 Team Project Collections.

    Please help!

  19. buckh says:

    Rahul, the error indicates that the application tier is unable to communicate with the SQL server. That sounds like you have an intermittent connectivity issue between you app tier and SQL Server that needs to be fixed. You can tell it to retry, but you may continue to hit this problem until the underlying connectivity issue is addressed.

  20. rahul sen says:


    Thanks for the reply. In our case, we are restoring the defaultcollection database only from production to dev.We are not provided with tfs_config db of prod.

    Is restamping required in this case? Will the steps as mentioned above work? Please help.

  21. buckh says:

    Rahul, are you detaching the collection from one server and attaching to another? Simply taking a backup and connecting it to another server is not going to work (groups and permissions stored in the configDB are copied into the collection DB during the detach process).

  22. buckh says:

    Oh, and to answer the question on changing the server ID…yes, you will need to do that if you are attaching the collection to a new server and not removing the collection from the original server (you do not want to have two collections with the same GUID, regardless of which server they are hosted on).

    You can add /clone to the tfsconfig /attach command line to force the GUID to be changed (rather than running another command to do it).

  23. rahul sen says:

    Thanks Buck! So, what I gather is that we are not supposed to cut the limbs and parts from production and join them in dev environment right?

    The concern here is that if we  even restore tfs_config db and collection db from production to dev, and even if we change the server id using the steps as mentioned in above blog, we might end up using the production database. Is there any remotest chance of this?  I am asking this as I need to make sure that even if we replicate the steps above on production back up restoration in dev, then in no way we are accessing the production db.

    If not, then only we will try to restore production config db in dev along with the collection db. I need your expert advice on this. Thanks in advance.

  24. buckh says:

    No, you will be fine so long as you get the GUID changed. You can detach a collection, take a backup, re-attach it the original server, and then attach /clone it to the test server with no problem. Or you can backup the whole system and create test system and run changeServerID on each collection change all their GUIDs. What's left at that point is the links to the SharePoint and Reporting sites. You would probably want to unconfigure those. If you intend to test Build you would need to delete the build agents and controllers in the test server (so the test server doesn't connect with them) and set up one or more build agents and controllers for the new test server.

  25. Reboots DaMachina says:

    Hi Buck, I have TFS 2013 single server install (SQL,SP,TFS) dev server (01D) cloned to (02D) and am wondering where to start first to get 02D. The clone worked well enough but the TFS references and URL's reference the 01D machine obviously. Where and how should I start to make this usable?

  26. buckh says:

    Reboots, I have updated this post to point to the 2013 MSDN documentation that has the instructions. It's very similar to move but with the added commands to update the new server to be different than the old one.

  27. Reboots DaMachina says:

    Thanks Buck!

Skip to main content