Don’t Sysprep Me, Bro!

The top virtualization platforms allow for rapid deployment of virtual machines via templates.  This capability alone is enough to make virtual environments far more efficient than physical.

With template deployment comes VM (or “image”) customization — each instance of an OS needs to have a unique hostname and, in the case of Windows, a unique SID (security identifier).

Not surprisingly, each vendor has taken a different approach to image customization.  Let’s take a closer look.

VMware vCenter Server Image Customization

With VMware vSphere and vCenter Server, VM templates are simply virtual machines with a special flag that essentially prevents users from accidentally powering them on.  In fact, you can clone and customize a new VM from a standard VM if you prefer — converting to template first is not even required.  Sysprep is only run on the new VM after it is cloned — the original template/VM is never generalized by Sysprep.

Convert VMware ESX template back to VM.

The great thing about this design is that it gives you the ability to instantly convert a template back to a standard VM.  That makes it very easy to update templates and, for example, minimize the exposure of deploying virtual machines in dire need of numerous security patches.

Of course, vCenter also supports Linux guest customization, unlike competitors.

Virtual Machine Manager (SCVMM) Image Customization

Microsoft System Center Virtual Machine Manger also has VM templates, but the workflow is quite different from vCenter.

When you create a template in SCVMM, the guest OS is generalized with Sysprep before it is copied into the library.  That effectively destroys the original VM and, in fact, this is what the warning message states when you create a template.

Creating a template destroys the original VM

Maintaining a clone of every VM template obviously introduces some management overhead.  Another option you might consider: when it is time to update a VM template, simply deploy a fresh VM from the previous template, make changes, and then re-create a new template from the VM.  That sounds like it will work, but there is actually a problem that prevents it from being a viable solution. For technical reasons, Sysprep can only be run on a particular OS image a total of three times.  You can read all about the details in this TechNet article. UPDATE: Activated systems in a KMS environment are not affected by this limit.

Here is what happens when you exceed the Sysprep limit when attempting to create a template in SCVMM:

Sysprep Failed!

Looks like SCVMM administrators will either be maintaining master clones of all templates, or reinstalling VMs from scratch when updated templates are needed.  Kind of makes you think about the whole “managing physical plus virtual” thing, doesn’t it?

Citrix XenCenter Image Customization

Curious to know how Citrix handles Windows VM cloning and customization?  They just don’t bother — the documentation simply explains how to manually run Sysprep on a Windows VM before converting to a template.  All the disadvantages of the SCVMM model — without the automation.  Nice.


VMware vCenter Server is the only virtualization management platform that offers fully functional, non-destructive VM templates for both Windows and Linux guest operating systems.

What interesting VM/template strategies have you adopted?

With apologies to the “Don’t Taze Me, Bro!” guy.

(Visited 2,368 times, 1 visits today)
This entry was posted in Virtualizationism and tagged , , , , , , , . Bookmark the permalink.

15 Responses to Don’t Sysprep Me, Bro!

  1. Eric,

    Great write up on the way the different ‘vizors’ handle cloning. Especially useful information in VDI implementations where machines are coming and going in rapid fashion.

    I always wondered whether sysprep was *truly TECHNICALLY* necessary though. I wrote a quick post about it a while back :

    In a nutshell, the Technet article implies that there are not any serious issues with duplicate SIDs in a DOMAIN environment since once joined to the domain, the machines will have and use the unique domain SID.

    Interesting food for thought though.

  2. Some problem we see if machines have duplicate SIDs is that Microsoft WSUS get’s very confused and is unable to update the duplicate. Also monitoring with System center can get out of sync which can cause the duplicate to go unmonitored. It seems that some of Microsoft’s products rely on the SID and having duplicates can cause issues with those products.

  3. rickymh says:

    “In fact, you can clone and customize a new VM from a standard VM if you prefer — converting to template first is not even required. ”

    So I can just clone a XP VM’s and they will have unique SID’s?

    I don’t need to Convert my XP Image to a template and then “Deploy VM”

  4. Eric Gray says:

    Carlo, you make a good point. My concern would be running into unknown issues or potentially unrelated issues that are blamed on duplicate SIDs — requiring a time-consuming reproduction to verify. I say, “just sysprep it.”

    David, thanks for that insight.

    Ricky, cloning and customizing are two separate things. You can clone a VM and you will end up with an exact duplicate. However, during the cloning process you are given the option to customize the VM. That will give you a copy with a unique SID.

  5. RobSF says:

    Nice post, Eric. VMware is still miles ahead of the competition. Just don’t get complacent!

    I spotted one small error in your post. Sysprep can be run more than three times against a given OS. In fact, the TechNet article to which you linked clearly states that:
    “There is no limit to the number of times Sysprep can run on a computer.”

    The three-times limit is only a factor for Windows Activation:
    “However, the clock for Windows Product Activation begins its countdown the first time Windows starts. You can use the sysprep /generalize command to reset Windows Product Activation a maximum of three times. After the third time you run the sysprep /generalize command, the clock can no longer be reset.”

    So it’s really only a problem if you have to go through Windows Activation. Volume licenses have their own procedure to follow:
    “Activation can be reset an unlimited number of times for an activated Key Management Service (KMS) clients. For non-activated KMS clients, the activation clock can be reset only up to three times, the same as a single license. Microsoft recommends that KMS clients use the sysprep /generalize command where the value of the SkipRearm setting is equal to 1. After capturing this image, use the sysprep /generalize command where the value of the SkipRearm setting is equal to 0.”

    Smaller shops without volume licenses will have to struggle through the Windows Activation dance. Essentially, their cloned VMs will start in Reduced Functionality Mode. Then they’ll need to activate Windows as the very first step for customizing their new VMs. The other alternative, as you mentioned, would be to keep a “master copy” of each template to circumvent the three-times limit on Sysprep.

  6. Eric, russian version of this post here – 🙂

  7. Eric Gray says:


    As far as I can tell, the esoteric Sysprep options and procedure you point out are theoretical when it comes to SCVMM — the UI provides certain capabilities and it does what it does from there.

    If someone would demonstrate how to repeatedly go from template to VM and back with SCVMM, I will update the article accordingly.

    Thanks for your feedback and readership.


  8. Eric Gray says:

    Anton: Спасибо!

  9. Alex says:

    RobSF is right – I do actually have a client who uses the same procedure – once testing is completed, new VM is deployed from template, new app version is installed, and then new template is created from this VM. Tomorow they will gonna do it for 11th time..

    Disclaimer: I work for Microsoft.

  10. Eric Gray says:

    Alex, what is the guest OS? I suspect it might be Windows 2003 or XP without activation requirements.

  11. Fernando says:

    “All the disadvantages of the SCVMM model — without the automation. Nice.”

    I love your ironic way of writing stuff.

  12. Alex says:

    Server 2008 (now SP2), activated against KMS.

  13. Pingback: Did you know that… « DeinosCloud

  14. Eric Gray says:

    Alex (and Rob),

    Thank you for pointing out that the limitation on generalizing an OS three times by Sysprep does not apply to activated KMS clients. Larger orgs with a Key Management Server installed will therefore not be halted if they prefer to take the (time-consuming) route of deploying VMs from templates and then converting them back.

    The advantage still goes to VMware vCenter — templates can be converted back to VMs instantly.

    I have updated this article indicating that exception.

    Thanks for your feedback.


Comments are closed.