4

I have a Windows 2008 R2 domain joined server, which should be cloned as test server in the same domain! There is an MSSQL 2012 instance and Team Foundation Server 2013 installed, but this shouldn't have any impact on this plan.

My plan is the following.

  1. Clone the VMware machine.
  2. Boot without network connection (unplug the cable)
  3. Disjoin the domain with local admin, reboot
  4. Rename the servername and change the ip address, reboot
  5. Connect the network connection
  6. Join the domain (and change the @@servername in MSSQL).

My questions: Does this procedure affect the original server (domain computer account) in any way? What would you be your advice to do this?

Thank you in advance for your help!

StefanK
  • 125
  • 1
  • 2
  • 8
  • Make sure to run `SELECT @@SERVERNAME` after you deploy the cloned image to check the SQl Server name. If the old name is still reflected you'll need to run `sp_dropserver` and `sp_addserver` to change the name. – joeqwerty Dec 18 '14 at 16:59

2 Answers2

7

With all servers that are domain-joined, you need to sysprep them first. Revise your steps to the following:

1) Clone the machine using VMWare tools.
2) Boot without network connection.
3) Run C:\windows\System32\sysprep\sysprep.exe and tick "Generalize". Allow it to reboot.
4) Name the machine and connect it to the network and join as normal.

The sysprep is absolutely required to ensure the servers don't have conflicting SIDs. Be sure to regenerate the MAC address of the network adapter when you do the clone as well (I believe ESXi does this for you anyway).

Nathan C
  • 15,059
  • 4
  • 43
  • 62
  • Note that sysprepping a system may break some software. Or course, so may changing the computer name. – Grant Dec 18 '14 at 13:10
  • Yes ESXI changes the MAC address. I can confirm that from cloning a bunch of machines. However I'm not entirely convinced sysprep is as important, see my answer. – Reaces Dec 18 '14 at 13:11
  • @Grant True, I see that as a given though. In particular I'm not sure how well team foundation server will behave with a changed name...but hey, it's testing, right? – Nathan C Dec 18 '14 at 13:11
  • @Reaces While your reasoning is right, using sysprep is the recommended way to do a clone. Granted, the *best* way to clone is to use a freshly patched install and syspreping that. – Nathan C Dec 18 '14 at 13:12
  • @NathanC True, and I don't deny the proper way of doing it. However when it comes to trying to get a test server up and running with as little damage as possible, I think sysprep does more harm to the software than the duplicate SID does to the AD environment. Mark Russinovich' article (below) convinced me a few years ago, and I've deployed a lot of test servers without sysprep since and have had no real issues. (other than the time we tried it on an ADFS proxy, but that was... not smart :) ) – Reaces Dec 18 '14 at 13:44
  • 1
    It's possibly worth noting that, if this is to be repeated multiple times, then the above steps could be marginally altered to include selecting 'shutdown' from the options in sysprep.exe, then taking a snapshot of the resultant machine whilst shut down - creating a 'ready to configure' VM image which can then be cloned and named in the future to mitigate repetition of some of the above steps. – BE77Y Dec 18 '14 at 15:27
  • In my case, the clone with the same SID affected my IIS with Windows Autentication. – user15897086 Jun 23 '21 at 14:07
2

Adding to Nathan C's answer.

The proper supported way of cloning an AD joined computer is by using sysprep.
While normally you can safely say that your new machine will get a new RID, microsoft recommends using sysprep. So unless you can be absolutely sure you won't cause any unforeseen issues it's generally better to follow the recommendations.

However it has since been established and tested quite a few times and the SID is not as important as all that so your procedure will work, and if you utilize it only for testing then you should be fine.

Affected services are:

  1. WSUS
  2. System Center
  3. KMS

If you use any of these 3 utilities, you will get problems from your current approach that you would not get when sysprepping.
These problems normally only affect the newly added machine though, so the answer to:

Does this procedure affect the original server

Is: generally no, it shouldn't.

Keep in mind though, you're avoiding microsoft best practices for an easy fix.
Which generally does not end well, and definitely isn't long-term sustainable.

Community
  • 1
Reaces
  • 5,597
  • 4
  • 38
  • 46