We are currently in the process of deploying 9 IBM Blade servers as a Citrix XenApp farm for our employees. After evaluating the options for maintaining the servers, and their images, we settled on using Altiris. The past several weeks has been consumed with coming up with a "Golden" image that we can use across all 9 servers so that each user's experience will be consistent and predictable (well, as much as possible anyway). Coming up with this "Golden" image required going through a few iterations of a Server 2008 build, installing applications, customizing options and updates, etc. We finally came to the point yesterday when we were ready to make one last change and take a final image -- and this is when I ran into a problem. For the life of me, I could not get Altiris to take the image properly from the "Golden" server.
For the record, we've never used Altiris before, so for the most part we kept most of the default settings: we chose a path to save the image to, we chose to sysprep (using the default answer file) the server, and then take the image. I was finally able to narrow down the problem to sysprep not running correctly. So, at that point, I went on to the server to try and manually run sysprep and got a fatal error! (A full description of the problem can be found in this MS knowledgebase article).
Basically, it boils down to these facts: When Altiris syspreps a server it generalizes it (as it should since this strips out all of the uniqueness of the server, so it can be applied to other servers), resetting the licensing information (or rearming it), and whatever else it does to prepare the image. Now, this is all well and good except for the fact that Microsoft limits the number of rearms to 3 for any given Vista/Server2008 image. So, not really being exposed to this world before, I burned up these 3 rearms very quickly :)
At that point I scoured the internet for workarounds for this problem, since I had a golden image, but could not sysprep it. I tried the answer file solution proposed in the knowledgebase article above, but could not get it to work for whatever reason. Finally after much searching I came across this article, which describes how to get around this limitation.
So, to solve this problem (if you've read the entire post until this point, well done -- but if you just skipped down here to the solution, I don't blame you), I just went into the registry on the "Golden" server and set the following key to a value of "1":
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurentVersion\SL\SkipRearm (For Windows 7: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm, thanks Mike!)
Without a restart, I was able to run the Altiris imaging job again successfully. It cost me a day of work, so I hope someone finds this helpful. If you have any questions, feel free to leave a comment below.
Note: I also noticed that I had to do this registry change EVERY time before taking an image. The image does not retain this value, it gets reset after doing the sysprep.
35 comments:
Nice, Have run into this issue with my Windows 7 Deployment, will give it a shot tomorrow! Thanks for the info :)
Hi Shawn, thanks for stopping by! Just to let you know, I updated the registry key path specified in this article this morning -- for some reason I forgot to include the "SkipRearm" at the end the first time around. Let me know how it works out!
Matt:
Thanks for the tip, it worked great for the Windows 7 laptop image I am working on.
The location in the registry was slightly dfferent, but it worked which is the important part!
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform\SkipRearm
Hi Mike,
Thanks for the head's up on the Windows 7 Registry Key -- I updated the post to include that.
Thanks for stopping by!
This is a default Sysprep setting, and is described at http://support.microsoft.com/kb/929828.
For the Generalize phase you can set it up like this:
1
I'm having a similar issue with XP Tablet Edition 2005. Do you know the registry location for this OS?
Thanks for any help.
Hi Paul,
If the first registry key above doesn't resolve it, then I'm not really sure where it might be.
If you haven't done it already, you could try searching your registry for SkipRearm and see if you get any hits.
If you figure it out, be sure to let me know, and I'll update the post!
I've read that forcing skiprearm=1 can cause problems if you use a KMS (Key Management Server). Our organization doesn't and this registry hack was a great workaround for us. Thanks!
More than two years later and this post is still saving people hours of time.
Thanks Matt !
Thanks Darren! I'm glad that others have found this useful -- and I'm happy it saved you some time! Have a great day.
Modify your XML Unattend file to include SkipRearm in the Generalize Pass (comp. Microsoft-Windows-Security-SPP) - And you won't have to continually make the reg change each time.
...that being said...
One thing I find that doesn't get hashed out, and took me a few moments (weeks) to grasp when I should use skiprearm. What it did, and why. Faced with a similar problem where we were supplied with a corporate image with only 1 rearm remaining. What a joke. Meant that we had only one sysprep remaining. What about next year when we update the systems with updates and newer software. SOL brotha, because we're going to have to re-use the plain corporate image, instead of installing our more attuned version to modify, and then taking another snapshot.
What is means to the dismay of many is that you MUST (in order to stay compliant) is to use an image that can be re-armed. So annoying.
The SkipRearm process was intended only for config.
Many folk think that Microsoft has a limit of 7 of these skiprearms. This is only true for non-volume licensing. With volume licensing you can skiprearm unlimited.
Microsoft licensing requires you to rearm your systems (so that you authenticate again) for installation onto other hardware. The last sysprep (after testing) should have the skiprearm entry removed. This if for several reasons.
If you have KMS licensing and you don't rearm, then KMS Server will not count the new workstations you install as a 1+. I'm not sure the impact specfically to Token based or Volume Net Authenticated.
The other reasons apply to resellers or mfcts.
If you haven't authenticated, and don't rearm, your deployment is going to be a still-birth after 30~120 days (depending on your grace perdiod). MS doesn't allow you to authenticate/upgrade/pay for/beg/whatever after grace expiration.
On the not rearming topic.
It wouldn't be a good thing to get audited, and your systems have identical authentications.
Microsoft does try to counter this in their own way, by forcing a reauth based on hardware config changes. However with KMS, the licensing methods gives much greater latitude in hardware changes. Still means you have to rearm per the EULA.
What I don't understand is: why do I care about re-arm if I am using MAK activation?
Hi Emily,
MAK activiation is actually separate from this problem. You only care about this problem if you use something like Altiris to sysprep and take an accumulating image (i.e. each image builds off of the previous one). If each time you build an image from scratch (a clean Windows install) then this doesn't apply either.
So, regardless of whether you use MAK or KMS, you could run into this problem when you're trying to taking an image with Altiris.
Hopefully that clarifies the issue, if not, let me know!
I have changed the registry, modified the unattended.xml, and i still can't run my sysprep/generalize!
I don't get it.
Also it seems like the system has entered into the 30-day grace period when i do the slmgr command.
If someone can help!!
I don't know how to thank you :)
This post saved me at least a week of work.
You just did :)
I'm glad that you saved you some time -- I was hoping this would help many so my suffering was not in vain!
Hey Matt,
Your blog, has saved me a few times now, from having to rebuild an image from scratch after spending countless hours builing it.
Thanks.
Ben.
Hey Ben,
I'm really glad to hear that this stuff has helped you out -- I figured I couldn't be the only one out there with these issues :)
Have a great day!
Doh! Read this too late...
Bookmarked!
My short list of tips for getting Sysprep to generalize:
Always run a chkdsk /f on the system drive before sysprep
Make sure you don't have windows updates pending, and a reboot necessary.
Be sure you are running sysprep from an administrative prompt
STOP all services like antivirus, Windows media network sharing, and anything else like anti-malware.
As mentioned here, set the Skiprearm regkey to 1
If you are updating a PC image from earlier generations, you may have to re-activate windows using an OEM or MAK key to get sysprep to generalize, even with the skiprearm. We aren't using a KMS, too much overhead, so I haven't tried that, but shouldn't make a difference.
jkarov, thanks for the additional info! Great stuff!
Hi,
I deploy windows 7 without sysprep.
I need also change "skipRearm" registry key or execute sgml -rearm only before image ?.
Thank, best regards
Thanks for your comment! If you're not using sysprep, I'm not entirely sure if you'll need this regkey change, or the command you were referring too. So, you'll probably need to do some trial and error with that one!
Hi Matt. Nice info, i have ever use Altiris before and many of my friends told its awesome.
Anyway, regards on skipream technique, why dont use WAT remover?
Hi Matt,
Do you know if you end up with duplicate PC SID's when you disable this reg key or will the sysprep still generalise this key?
Hi,
In a quick check (using psgetsid), two of the servers I imaged do in fact have unique SIDs, so I think the Sysprep takes care of it for you.
Happy imaging!
Skiprearm=1 is Evil if you have KMS. Even after its sysprepped the machine will keep the SAME CMID. It doesn't regenerate new ones..
Hi Chris,
I believe you are correct. Do you have any suggestions for KMS users?
Thanks,
Matt
For KMS users (at least with w7 Enterprise) you should not need to worry about rearm etc. I found this page after getting the dreaded "A fatal error occurred while trying to sysprep the machine" but after some investigation it was just because after deployment (to make some changes) it had not activated to our KMS.
I activated and all is well. Also, you may just be able to run slmgr.vbs /rearm instead of the registry hack, I don't know.
http://social.technet.microsoft.com/Forums/en/w7itproinstall/thread/c3113122-3339-4cec-a649-c0690c12e514
You guys need to READ the error.log file in Panther folder.
I noticed after all this flub dubbing around I still got a "Failure" message pop-up.
So why not read the error log files and see what's up. Low and behold it was looking for MSESysprep.dll in the C:\program files\Microsoft Security Essentials\
folder. So, I torrented the dll and put it in the proper place WHAMMO!!!! the system sysprepped the OS successfully. REMEMBER!!! Now matter how professional the assistance may be everybody's situation can be different. Mine certainly was. READ THE ERROR LOGS!!! Lesson learned. We used to use MSE-Security Essentials and removed it, HA!!! What a joke Sysprep is being told we still have it from left over binary bile in the registry files.
This work around still works. Thanks!
Hi Brian,
Glad I was able to save you some time -- and that it worked!
Have fun :)
Thanks a lot!!!
Thank you!!!!!!!
this video help me to fix slmgr rearm exceeded error.
https://www.youtube.com/watch?v=nwaQc7cb5_M
Post a Comment