index > Team Foundation Server - General > Moving a dual server instance to new hardware

Moving a dual server instance to new hardware

I'm in the middle of moving a dual server instance of tfs to a couple of test machines. We've successfully installed the tfs dual server setup to the app and data tiers, and restored the databases from the live instance to the test setup.

I'm just in the final stages of the move and am hesitant to run the tfsadminutil activateat command because of the prompt i receive.

It asks me to make sure the old app tier has stopped the tfs service before running the command.

My question is this.

By running the command on the new server, will it in any way affect the old instance.

The reasons; I have a live instance running on 2 machines, and I want to do some testing in a staging environment, so I need to live instance to be available after I do the move.

In essence I'm not moving an instance of tfs, I'm cloning it.

paul langan

pflangan

Sorry for the delayed response. You are correct to be nervous!

Please make sure to follow the instructions on how to move a TFS instance to new hardware in the following help doc: http://msdn2.microsoft.com/en-us/library/ms404869.aspx

Make sure that you run TfsAdminUtil RenameDT (as described in the help docs) BEFORE running ActivateAT, so that your AT is correctly pointing at the cloned DT machine (after having restored the DBs). This *should* prevent any damage occuring on your old instance.

There may be another issue with this, that I need to check. Can you hold off for another day please?

Thanks,

Dan Kershaw [msft]

Dan Kershaw

Sorry for the delayed response.

I have one important question. Are the client machines that are connecting to the cloned server, ONLY connecting to the cloned server, and never to the production server, for the lifetime of the client machine? If so, then this is safe. If not, then it *could* be possible for the client to appear to be connected to the cloned machine, when in fact it's connected to the production machine under the covers. This is because the client cache uses a machine instance ID from the server. Because you've "cloned" the production machine, there will now be 2 server machines with the same machine instance ID. Unfortunately our move instructions are for moving, rather than cloning, and we have no easy way to "restamp" the machine instance ID (stamping the ID happens at installation time only). However I will double check.

Thanks,

Dan Kershaw [msft]

Dan Kershaw

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).

Rem Clear the instance info

Dan Kershaw

Thanks for the answer. We've successfully created our staging instance, with some hiccups, but nothing major.

Although we were pretty confident that the procedure would work, we actually disconnected the live machines from the network while we performed the steps.

just to comment on the above script, the second command should refere to the %NEWDATATIER% shouldn't it?

paul langan

pflangan

Correct - Dan's steps are to be run on the "new" AT and pointing at the "new" DT - it will change the identifying info on the new (cloned from original) server so it will be different than the original server.

The original server's identifying information should be left as-is - there's no reason to change it.

Team Foundation Server - http://blogs.msdn.com/jmanning/

James Manning - MSFT

reply 6