Cloning a Windows VM that is part of a domain using Sysprep.exe

Introduction note

In the writing below, the term "SID" most of the time refers to the "Computer's Domain SID" (the SID of the computer accounts in the Domain). Windows OS also uses local SID(s) but those are meant to be harmless. For more information please read this excellent article from Mark Russinovich (cofunder of Sysinternals and writer of the NewSID tool) : http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx.

1. Using sysprep to change the SID

Cloning a VM that is part of a domain in order to use it simultaneously along with the original one is hard: on top of changing 1/ the MAC address, 2/ the computer name and 3/ the IP, we always run into mysterious problems when faced with the domain controller.

And there is even worst: the same goes for (some) backups. For instance, I recently backed-up (ie. copied) a VM and upgraded it to Service Pack 3. After the system was upgraded, I switched the VM off and turned the backup on: the domain rejected the old version of the VM. I assume that the controller stored the upgraded system type and refused to grant access to the domain when running an older XP SP2 system. Needless to say, this backup is quite useless :(

So, cloning a VM creates conflicts difficult to solve. Even if it has been taken off the domain prior to duplication! My network administrator pointed out that this is caused by the SID of the machines, but we never really knew what the solution was in order to work around this problem (from a user point of view, not from the network admin point of view). Now, I just found a possible solution in the Xen documents. The tool mentionned below (sysprep) is not specific to Xen, but to Microsoft. (Source: http://xen.org/files/XenCloud/guest.pdf, Chapter "Preparing to clone a Windows VM".)

Computers running Windows operating systems are uniquely identified by a Security ID
(SID). When cloning a Windows VM, it is important to take steps to ensure the uniqueness
of the SID. Cloning an installation without taking the recommended system preparation
steps can lead to duplicate SIDs and other problems. Because the SID identifies the computer
or domain as well as the user, it is critical that it is unique. Refer to the Microsoft
KnowledgeBase article 162001, "Do not disk duplicate installed versions of Windows," for
more information.
sysprep modifies the local computer SID to make it unique to each computer. The sysprep
binaries are on the Windows product CDs in the \support\tools\deploy.cab file.

And, more specifically, the process being:

5. Copy the contents of \support\tools\deploy.cab from the Windows product CD
to a new \sysprep folder in the VM.
6. Run sysprep. This will shut down the VM when it completes.

7. Convert the VM into a template.
8. Clone the newly created template into new VMs as required.
9. When the cloned VM starts, it will get a new SID and name, run a mini-setup to prompt
for configuration values as necessary, and finally restart, before being available for use.

And this important remark:

The original, sysprepped VM (the "source" VM) should not be restarted again after the
sysprep stage, and should be converted to a template immediately afterwards to prevent
this. If the source VM is restarted, sysprep must be run on it again before it can be safely
used to make additional clones.
For more information on using sysprep, refer to the Microsoft TechNet page "Windows System Preparation Tool".

So, in short, two points to be remembered:

1/ running sysprep destroys the SID and shuts the VM down

2/ a new SID is created when the VM is turned back on and added to the domain.

2. Operating systems supported

2.a) XP and Server 2003

sysprep.exe has to be installed separately.

There is a great article that explains how to create a template machine that will also prompt for a new name on next start: http://capitalhead.com/articles/force-sysprep-to-prompt-for-a-computer-name-during-mini-setup-in-windows-xp.aspx

I strongly recommend duplicating the VM before deleting the SID (for backup purpose of course!).

2.b) Windows 7 Professional and Server 2008 R2

I can confirm that sysprep is already present in the C:\Windows\System32\sysprep directory. Note that you have to run Explorer with Administrator privileges in order to see those files (press Win+R and type "sysprep").

3. Template instantiation

Computer makers such as Dell or HP use sysprep.exe to configure the computers: this tool allows you to install and configure programs (or drivers) on a computer, to create local accounts, etc. and then delete the SID and therefore make the computer ready for first use. The template can be copied as many time as you want, but each copy will have to be activated separately, an IP will have to be set for each computer and the Name and Domain configured. And that is it. Every program installed before the SID deletion will remain on the computer. All the user accounts created will remain as well and so does the application data.

An other interesting thing with this process, is that if you had two accounts ( say MYCOMPUTER\Administrator and MYDOMAIN\UserLambda ), then those users will find their desktop just as it used to be before the machine became a template and was re-instantiated again.

But this may have drawbacks and here is an exemple of what NOT to do (yeah I did it, no big deal really, but it creates an overhead of work upon each instantiation): so for instance, 1/ installing LogMeIn Hamachi and creating an account and then 2/ deleting the SID and re-instantiating the VM multiple times is... well, stupid. Hamachi settings are not reset by sysprep.exe because this tool is not part of the system and it does not use the SID either. Therefore every new VM will attempt to use the same Hamachi account and this will cause conflicts. The only solution then is to uninstall and reinstall the Hamachi client on every new computer.

A good practice here would have been to install the Hamachi client before templatisation, but never switch it on (or at least not configure it). The user of each instantiated VM would then already have the program at hand and just would have to run it and create his account himself.

3. Conclusion

I've successfully used the sysprep tool on an server2008 r2 system and it worked great but I did not have such luck with my old XP SP2 system and I will leave it there.

At the end of the day, sysprepping your OS is not very straightforward, but this an irreplaceable process when you need to duplicate a virtual machine that is part of a domain.

Thank you for reading,