Microsoft Enterprise Platforms Support: Windows Server Core Team
EPS Team Blogs
Product Team Blogs
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.
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
When it came time to update the image the process continues as follows
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
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:
When it comes time to update your image you do the following
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:
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.
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support
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?)
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