Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, July 7, 2017 2:52 PM
Are there any commercial SYSPREP packages available, which don't have the 3 SYSPREP limit imposed by Microsoft? What do system builders & OEMs use? Thanks
All replies (7)
Tuesday, October 16, 2018 8:52 PM âś…Answered
Your answer can be found here.
Friday, July 7, 2017 3:24 PM
No there is no option for that.
Most people will use a build and capture TS, when them need to add something they add it to that TS. Therefore they don't run into these issues.
Garth Jones
Blog: http://www.enhansoft.com/blog Old Blog: http://smsug.ca/blogs/garth_jones/default.aspx
Twitter: @GarthMJ Book: System Center Configuration Manager Reporting Unleased
Friday, July 7, 2017 3:27 PM
Hello
There is no limit to the number of times that the Sysprep command can run on a computer.
If you anticipate running the Sysprep command multiple times on a single computer, you must use the SkipRearm setting in the Microsoft-Windows-Security-Licensing-SPP component to postpone resetting the activation clock. Because you can reset the activation clock only three times, if you run the Sysprep command multiple times on a computer, you might run out of activation clock resets. We recommend that you use the SkipRearm setting if you plan on running the Sysprep command multiple times on a computer.
[HKLM\Software\Microsoft\Windows NT\ Current Version\Software Protection Platform]
SkipRearm = dword:000001
This will allow you to do the rearm a few more times.
You need to have the Skip Rearm setup in your unattend.xml under generalize. This is what I did to allow my sysprep to work correctly.
<settings pass="generalize">
<component name="Microsoft-Windows-Security-Licensing-SLC" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
<component name="Microsoft-Windows-Security-SPP" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
Before running the Sysprep command the final time before deploying the computer, rearm the computer by setting the SkipRearm setting to 0. This causes the activation timer to reset.
Regards, Regin Ravi
Friday, July 7, 2017 3:50 PM
To add a few comments here, the limitation isn't with sysprep, it's with Windows. Sysprep is just the command that initiates the generalization. Thus, an alternative to the sysprep command wouldn't help here even if one existed.
As for your core issue, Garth's comments are spot on. Building a reference image from a new, and clean install of Windows is the best path to follow. Reusing the same reference system over and over typically has many negative ramifications. Using an automated method of building clean reference systems and capturing them is the cleanest path and offers the best, repeatable results.
While skiprearm works, its an ugly solution that simply creates ugly images. Note though that if you are using actual volume license media, you shouldn't need to use skiprearm at all as there should be no activation clock with VL media.
Jason | http://blog.configmgrftw.com | @jasonsandys
Friday, July 7, 2017 4:40 PM
That would be building & capturing a VM? Aren't there HAL issues with that? Thanks
Friday, July 7, 2017 4:41 PM
Can anyone else confirm that volume licence media has no activation clock?
Thanks
(if true, that would be a relief)
Friday, July 7, 2017 5:11 PM
HAL issues haven't existed since Windows XP. Since Vista, Windows transparently checks and gracefully swaps out HALs at startup as needed.
A VM is not strictly required for a build and capture ts but it makes the process much easier and adds to the repeatability of the process.
Jason | http://blog.configmgrftw.com | @jasonsandys