Udostępnij za pośrednictwem

Sysprep, SkipRearm, and Image Build Best Practices

  • Artykuł

Running sysprep

Today's blog will cover a common question we get with deploying Windows. The question usually starts as "How many times can I run sysprep"? While the answer is simple it requires a more detailed explanation.

When sysprep executes, one of the sysprep providers is responsible for resetting the grace period for activation. This ensures that when the image boots up for the first time you have 30 days grace period to activate.

With Windows Vista and later you can only run sysprep 3 times on an image. This comes from a limitation with how many times you can reset activation on Windows. This includes running sysprep or slmgr.vbs /rearm. The reason is that if we allowed sysprep or slmgr.vbs to be able to reset activation with no limits you could run Windows forever without activating it. Windows XP and Windows Server 2003 did not have this limitation.

When you first install Windows your rearm count is set at 3. You can see the current rearm count by running slgmgr.vbs /dlv and looking at the following:

Remaining Windows rearm count: 3

Note: If you install a service pack the count will increase by 1

When you exceed the rearm count you should get error similar to this KB

929828 An error message occurs when you run "Sysprep /generalize" in Windows Vista: "A fatal error occurred while trying to Sysprep the machine"

There is a unattend parameter you can use in unattend.xml you pass to sysprep.exe called Microsoft-Windows-Security-SPP\SkipRearm. If you set this to 1 you can run sysprep as many times as you want but you MUST remove this setting or set to 0 on the final running of sysprep otherwise the grace period is not reset(additionally the CMID is not reset which can cause problem with KMS activation). Many times we see deployments where the SkipRearm setting is left in the answer file and set to 1. Due to this and other best practices we do NOT recommend this.

Issues with Sysprep and SkipRearm

The use of SkipRearm leads into a discussion around best practices for building images. In the past with Windows XP/2003 most administrators followed a process similar to this

  1. Install Windows
  2. Install applications/drivers/updates
  3. Run sysprep
  4. Capture Image Version #1
  5. Deploy image Version #1

When it came time to update the image the process continues as follows

  1. Deploy Image Version #1 to a machine
  2. Make changes to image
  3. Run sysprep
  4. Capture Image Version #2
  5. Deploy image Version #2

This process may go on and on. The issue with this type of image build process is that over time it becomes very difficult to troubleshoot any issues with this image because the process for building the image has been a manual process. An example of an issue that can be attributed to this process

818171 "An Error Has Been Encountered That Prevents Setup from Continuing" Error Message When Sysprep Mini Wizard Runs

There could be many other issues that could arise out of this type of image build practice.

Some of the disadvantages of this type of process include

  • Requires interaction by the user or deployment technician.
  • Increases the risk of introducing configuration errors.
  • Difficult if not impossible to reproduce steps on how an image was created

Microsoft Deployment Toolkit

With the release of Microsoft Deployment Toolkit we now have a tool that allows you create a fully automated consistent method for building a reference image and it supports all operating systems including Windows XP and Windows Server 2003. With MDT the general process looks like this:

  1. Setup your MDT server
  2. Add the operating system source files(not a custom install.wim), applications, drivers, and updates
  3. Create task sequence called "Build reference image"
  4. As part of this task sequence choose the option to prepare and capture the image
  5. On your reference system (physical or virtual) boot into the Lite Touch image and choose the "Build reference image" task sequence.
  6. MDT installs Windows and all your other components and also runs sysprep and captures the image for you
  7. Import this image into MDT
  8. Create a task sequence to deploy it such as "Deploy Custom Image version #1"
  9. Deploy the image to your hardware using the "Deploy Custom Image Version #1" task sequence

When it comes time to update your image you do the following

  1. Make your changes in the MDT workbench for the image. For example
    1. add some new drivers
    2. add new updates
    3. add new applications
  2. On your reference image boot into the lite touch image and choose the "Build Reference image" task sequence. Note that through the use of customsettings.ini or custom database you can fully automate the prompts so it requires no interaction
  3. MDT installs Windows and all your other components and also runs sysprep and captures the image for you
  4. Import this new image into MDT
  5. Create a new task sequence to deploy it, for example "Deploy Custom Image Version #2"
  6. Deploy the image to your hardware using the "Deploy Custom Image Version #2" task sequence

The difference is that you rebuild your reference image from scratch each time and sysprep is only run one time. The advantages of this type of process include:

  • Consistent process for building the reference image
  • Requires no modification of the default install.wim
  • Uses built in mechanisms of setup to add drivers and updates to the install
  • Easy to add/remove components for testing
  • No interaction required by the user or deployment technician.
  • Decreases the risk of introducing configuration errors.

With MDT automating the process of installing the operating system, drivers, updates, applications, and the capture of the image you ensure that each time you want to update an image the image is rebuilt in a consistent automated fashion. This image is also prepared with sysprep only once which helps prevent the random issues with images that have had sysprep run on them many times.

Hope this helps with your deployments.

Scott McArthur

Senior Support Escalation Engineer

Microsoft Enterprise Platforms Support

Comments

  • Anonymous
    January 01, 2003
    TYPOslmgr.vbs /dlv (not slGmgr.vbs /dlv)
  • Anonymous
    January 01, 2003
    I actually use a form of the third option with SCVMM templates. When I make a new VM that will be converted into a new template, I clone that VM first and store the copy in the library. (Basically SCVMM's version of grabbing a reference image.) That way if I need to make changes to a template, I redeploy the cloned VM copy back down to a Hyper-V host, make the changes, and repeat.
  • Anonymous
    January 01, 2003
    There is a third option, which is a variation of the first option listed in this post. That is you install Windows and applications on the reference machine, but then you grab an image before running sysprep. This is your reference image. Afterwards, you can then sysprep the machine and grab the image that will be deployed.When you need to make changes to the image, you deploy the reference image back down to the reference machine, make the changes, and grab a new reference image. Afterwards, sysprep the reference machine and grab the new deployment image.The only downside is the storage needed for the reference image, which nowadays, is no big deal.
  • Anonymous
    January 01, 2003
    How about this (Windows 7):Go to regedit: HLMSoftwareMicrosoftWindows NTCurrentVersionSoftwareProtectionPlatform and change "SkipRearm" value from 0 to 1After that try to run Sysprep with "Generalized" option check. For me it run no problem.
  • Anonymous
    January 01, 2003
    UPDATE Aug 2011: Windows 7 SP1 / Server 2008 R2 SP1If you use KMS license activation, the KMS server will drop the client activation count from 4 to 1 when a client machine is first activated with it.If you then sysprep this machine, and generalize and re-arm it, the activation count drops to 0 (ZERO) when it is uploaded to Windows Deployment Services.But on the next KMS activation, the KMS server will give back the one  activation so that you can re-generalize and sysprep the KMS machine, again and without limit.So it's only the people who don't or can't use KMS licensing that have to suffer through figuring out the Deployment Toolkit, to deal with the 5 activations limit.This is discussed here:social.technet.microsoft.com/Forums/en/w7itproinstall/thread/6634dbbc-cb54-41aa-a01a-23199e42c91b(Isn't it fun how Microsoft's official product documentation is a disjointed mess and none of this is described in the volume activation documentation?)
  • Anonymous
    May 12, 2011
    To me, the old method is much simpler. And simpler is better. The MDT method is ridicously complicated and I've abandoned it many times to return to the old method. I just rebuild the images when it hits the rearm limit, it takes less time.
  • Anonymous
    May 12, 2011
    Skolvikings, that's even better. :-)I'll start doing that with WDS and SCVMM.
  • Anonymous
    September 19, 2011
    @DaleMahalkoThanks for pointing that out.  I had a feeling that KMS environments would be an exception but I never saw that highlighted in any documentation.I can update my image without worry now.  Yay! :)
  • Anonymous
    May 09, 2012
    I agree with Nori, the new method is absolute trash.
  • Anonymous
    June 10, 2012
    Can someone let me know why, in MDT, I can 'sysprep only' my machine and it boots right up to the admin desktop; when I 'sysprep and capture' using the exact same unattend, it stops and asks me to create a user name. I can't choose Administrator because its already used. It shouldn't ask me for anything. The old method: sysprepgeneralizeoobeshutdownunattend:unattend.xml worked just fine also.Ideally I need to sysprep and capture my modified image (within a virtual envirnment) and have it boot back up to the same desktop w/o asking to log on. What is the capture step doing that is changing from just the sysprep step itself?Thanks!
  • Anonymous
    October 23, 2012
    The comment has been removed
  • Anonymous
    November 30, 2012
    The comment has been removed
  • Anonymous
    December 19, 2012
    I am confused on this a bit.  It seems that with KMS then you can rearm Windows7/2008 R2 more than three times but with MAK you are limited to just the three times.  Can someone confirm or deny this?thanks,Larry
  • Anonymous
    September 27, 2013
    you made a typo:  slgmgr.vbs /dlv   the correct switch is slmgr.vbs /dlv
  • Anonymous
    February 13, 2014
    As part of this task sequence choose the option to "prepare and capture" the image I dont see this option . I have an option to" sysprep and capture" . if your going to write intructions then , you should make sure the wording is correct .
  • Anonymous
    July 02, 2014
    Microsoft's Mission Statement:

    Let's see how complicated and convoluted we can make the simplest of processes..... and then charge customers through the nose for support to help them figure it out.
  • Anonymous
    March 13, 2015
    Any body tell me how to convert my standalone windows license to volume license, Please let me know where can get PPT for WDS, MDT & AIK step by step configuration on 2008 R2
  • Anonymous
    June 02, 2015
    I followed this process on MDT to create a reference image in Virtual environment.
    the issue is windows activation time period is counting down the days that will cause issue once it runs out of days for activation on the reference image.
    how do you fix that?