Sysprep, SkipRearm, and Image Build Best Practices

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