Sysprep, SkipRearm, and Image Build Best Practices

Sysprep, SkipRearm, and Image Build Best Practices

  • Comments 18
  • Likes

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 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.

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

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

  • Skolvikings, that's even better. :-)

    I'll start doing that with WDS and SCVMM.

  • UPDATE Aug 2011: Windows 7 SP1 / Server 2008 R2 SP1

    If 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:

    (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?)

  • @DaleMahalko

    Thanks 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! :)

  • I agree with Nori, the new method is absolute trash.

  • 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: sysprep\generalize\oobe\shutdown\unattend: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?


  • Microsoft really *** the bed on the back end of Windows 7.  You can't skip rearm because it will eventually create duplicate machine IDs on the KMS server.  Then the software won't activate.  But if you don't skip rearm, you can't update your images more than a couple of times.  It's clear Microsoft was more concerned with, and spent the most resources on, making sure nobody could pirate Windows 7 instead of making a good OS that could be deployed in an enterprise environment.  But what else would you expect when the failure rate for the Xbox 360 was over 61%, and all they did was extend peoples' warranties an extra year, then provide them with the same faulty hardware?

  • Umhmm.  Now, go work for a high security environment, say DOD.  There, a new image must undergo testing for security purposes, and pass Information Assurance inspections.  This takes about three months.  Now your "new" image is totally out of date.  And you recommend not to build on the old image.  Do we perhaps see a problem here for your biggest single customer?

  • 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?



  • you made a typo:  slgmgr.vbs /dlv   the correct switch is slmgr.vbs /dlv

  • TYPO slmgr.vbs /dlv (not slGmgr.vbs /dlv)

  • How about this (Windows 7): Go to regedit: HLM\Software\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform and change "SkipRearm" value from 0 to 1 After that try to run Sysprep with "Generalized" option check. For me it run no problem.

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