Guide to ChangeServerId says mostly harmless

If you are cloning your TFS collection then you have to run ChangeServerId. It is reasonably well documented for this senario but what other reasons might you have to run it.

Well if you are upgrading your TFS server you may want to create a duplicate of your environment, run the upgrade and have a few folks connect and try things out. This is where we need to talk about GUIDs. GUIDs are used everywhere in side TFS. Your server has a GUID, your collections have GUIDs and even your Team Projects have GUIDs.

So if you take a backup of your production environment and restore it to another for upgrade it will have the same GUIDs. But why is this important. Well, when you connect to another server with the same GUIDs your client applications that connect to TFS will automatically transfer all of your cache and workspaces to the new server. This gives your users continuity of use as they can easily transition to the new environment even if it has a new name.

However if any users connect to your test / trial upgrade environment the same thing will happen and they could start to see some pretty strange results… you know… weird things like getting the wrong files when you do a get from source control, SharePoint sites created on the wrong servers and even errors when editing or querying work items.

The way that you solve this is the same as for cloning your collection. You need to make a call to ChangeServerId.

Figure: ChangeServerID command

Now usually I would do this as soon as I stood up the new instance, but this instance was stood up by a customer that did not know about the GUID issues. They had just sent out an email to many of their users to try out and validate the new environment so unfortunately I recommended that they immediately change the server ID so that they don’t have problems later.

Why do I say unfortunately… its all in the messages and there is one when you try to run ChangeServerID that my customer, as everyone does, breezed over this morning:

The command ChangeServerId should only be run against a set of Team Foundation Server databases that have no application tiers configured. Do you want to continue with this operation? (Yes/No)

While this is absolutely explicit you and I likely did what they also did which was focus on the last sentence and the questions that it contains…

Now if you do go ahead and say ‘yes’ then you will end up with a few problems.

image
Figure: TF31001: Cannot connect to Team Foundation Server

woops, lets hope this is just a client issue and check the web access…

TF50620
Figure: TF50620: The  Team Foundation identity scope does not exist

Oh… well a reboot will likely solve that…

image
Figure: TF30046: The instance information does not match

Dam..

Checking the event log on the server reveals lost of errors of the TF30046 variety but logs on the server reveal nothing. Even checking the ChangeServerId log reveals nothing but success.

To the rescue is Vladimir Khvostov from the product team who pointed me at the RegisterDB and the cause.

Figure: Setting the server strait

In the bowless of the web.config for the TFS web services there lies an “applicationid” key that should be the new GUID but has not been updated. Hence the warning when running the command.

Running RegisterDB command will update setting in the “C:Program FilesMicrosoft Team Foundation Server 11.0Application TierWeb Servicesweb.config” and allow the server to work again.

To save time I went ahead and updated it manually and WOW everything worked again.

Lesson: Heed all Team Foundation warnings

  • Zephan Schroeder

    Excellent post. I like seeing this topic from time to time because I know about restamping the database but need it so infrequently I need to search for instructions each time… and I never considered any negative effects to users. Thanks for saving me a headache :-D.

    Consider sending the following feedback to Vladimir (or dev team). Instead of passive caution error “…only be run on on TFS databases with no Application Tiers”… the warning should state what action may be requried: CAUTION: After running this command each configured application tier server (if any) will need to have the following command run: TFSConfig RegisterDB /SQLInstance:.

    Cheers! -Zephan

  • Dave Burnison

    You mention “If you are cloning your TFS collection then you have to run ChangeServerId. It is reasonably well documented for this senario”. I have not been able to find that documentation. Can you provide a link? We want to do this, (clone our envirnment), to run a test upgrade to TFS 2012 before upgrading our production environment.

  • Alain Rodriguez

    Martin, great article, but getting a different issue. I am upgrading from TFS 2010 to 2012 in a different server and wish to clone/duplicate one collection into two. I am able to upgrade, make a backup of the collection, change the name and db of the current one, restore the previous and then attach it to TFS, but I am getting a:

    TF253021:The following team project is duplicated in at least two team project collections…The collection cannot start while the duplication exists. You must delete this project from all but one of the collections before the collection can be started. The project exists in the following collections: LegacyCollection, Collection.

    How were you able to solve this?

    Is there another way to clone?

    I would appreciate any hints on this… thanks!!! 🙂

    • You can use the following process: http://msdn.microsoft.com/en-us/library/vstudio/dd936158.aspx

      Good Luck…

      • Alain Rodriguez

        Unfortunately, the article clearly states the limitation:

        “When this collection is attached, it will remain stopped. You will not be able to start it until all duplicate projects have been removed.”

        “A project cannot exist in more than one collection. Until you delete all duplicated projects between the split collections, you will not be able to start the renamed collection.”

        My requirements are in fact, to keep those duplicate projects.

        Thanks for the quick response.

        • Unfortunately the only way to keep the duplicates is to stand up another TFS instance…

          • Alain Rodriguez

            Thanks!

  • M Khan

    Hi Martin,
    We are just refreshing our TFS2012 Test server first time after upgrade from TFS2010.
    It was much easier in TFS2010 as I had to run simple TFSConfig commands to remapDB, ChangeServerID and registerDB and jobs was done.
    In TFS2012, At what step should I be running ChangeServerID and registerDB commands, I haven’t been able to find any useful article explaining this scenario (creating Test TFS from Live!) in step-by-step.
    Thanks,
    M Khan

    • The 2012 process is identical to the 2010 process except that the remapDB command is no longer necessary. You should run ChangeServerID before the step to ‘install the application tier’ on http://msdn.microsoft.com/en-us/library/ms404869.aspx

      • M Khan

        Thanks Martin, That is very helpful and i’ll give it a go shortly.
        Is there any resource you could share for performing a restore using SQL backups and not the backups created by TFS Admin Console? As we don’t have TFS Backup plan configured and our Tech team are reluctant to create one.
        Thanks 🙂

        • I hope that your tech team are doing ‘marked transaction logs’ otherwise that are using a completely unsupported backup method that can result in an inability to restore in a disaster. That is why the TFS team created the built in tool for backup and restore, it makes doing a proper backup easyr than following the manual backup process (http://msdn.microsoft.com/en-us/library/ms253070.aspx) which is the MINIMUM you need to be doing to have a likely restore. If you are restoring from a simple bak file then you just restore like you would any set of DB’s. There is no direct guidance for this as it is just SQL procedure for restoring… http://technet.microsoft.com/en-us/library/ms177429.aspx

          • M Khan

            Thanks Very Much…. That has worked!

  • Paul Abrams

    Hello! I’m trying to Test an upgrade from TFS 2010 to 2013 using a migrate-and-upgrade strategy. I’ve

    1. had my DBA restore the TFS and ReportServer databases from nightly backups of our Dev TFS 2010 instance to our new test server.

    2. Installed (but not configured) TFS 2013

    3. When I try to run TfsConfig PrepareClone as noted at https://msdn.microsoft.com/en-us/library/ms404869.aspx, it gives TF30040 and it turns out there is a proc missing: “prc_GetServiceVersion”.

    Did I do something wrong? Any advice? Can I just skip prepareClone in my scenario?

    • The documentation does not realy cover that path…. Follow the upgrade path first, then un-configure the app tier and run the changeserver I’d bit…and then reconfigure “apptier only”

      • Paul Abrams

        Okay, I’ve tried that, and PrepareClone now runs properly, and I re-ran ChangeServerIDs, and remapDBs (although that one says there’s nothing to do). But when I run TfsBPA, for some reason it still sees the old server that I cloned from, and runs “Machine Health Check” on that server. I’m guessing that means the migration/upgrade was not clean…? I want to have the target of the migration available for testing, while the source of the migration remains in (pre-production) use…
        Any advice on how to get rid of the references to the old server?

        • The old server referenced drop of after30 or 60 days of inactivity.

          p.s. The remapDB’s was completed as part of the upgrade on the new hardware. The only thing you needed to do was ChangeServerID from that list…

  • Pingback: Set up a Test TFS environment with production databases | The Road to ALM()