Another reported workaround ineffective...
Late last week, while I was out of the office sick and with my boss covering for me, our team learned of reports of a purported workaround to activation on Windows Vista. I also just noticed a question in the form of a comment posted by a regular reader of this blog about this exact issue (thanks mhornyak) and I'm happy to provide an update on this.
As I mentioned in a previous blog, when we hear reports of this type our team looks begins by examining whether the issue is technically valid and if so how it might impact our customers. A quick analysis of this report determined that this purported workaround doesn't work. What follows below is a more technical explanation of the features discussed in the reports of the workaround and how they behave and why.
If anyone knows of other scenarios they think might be similarly confusing or that could be construed as workarounds feel free to drop me a line. We'll gladly work with you to understand what's going on.
The purported workaround
The reported workaround utilizes the documented feature skiprearm. Skiprearm is used in combination with sysprep by system builders and IT pros who want to design customized builds of Windows in order to add software, drivers, help files, and other useful information for their customers. To understand skiprearm lets first take a sec to understand what how plain ole' rearm is used.
In the process of building a customized build of Windows Vista it is necessary for the builder of the image to actually run the software, when the OS is booted for the first time the timer that starts the 30 day grace period begins. Obviously this could create a problem if after a week or two of installing, booting and testing the image the image is put in the hands of a customer with only a couple of weeks of grace period left. This is where the rearm feature comes in. Rearm is used to reset the activation grace period timer to 30 days as one of the final steps the builder of the image will perform. Doing this enables the builder of the image to ensure the customer has the full 30 day period in which to activate. And if the builder of the image makes a mistake rearm can be performed up to three times. So where does skiprearm come in? Skiprearm is used because during the process of actually testing the image the builder of the image will need to run the sysprep command to reset the image to present the out of box (OOB) experience the next time the OS is started. HOWEVER, running the sysprep command will also run the rearm command by default, this makes sense if sysprep is the last thing done to the image before it is distributed. But wait, can't rearm only be run three times? Yup! Enter skiprearm, skiprearm enables someone to run the sysprep command but WITHOUT actually using one of the three rearms. The fact that skiprearm does this and is meant for this purpose is clear in the documentation of the feature. When the skiprearm bit is flipped the rearm command can be used and will appear to succeed when it fact it is failing to extend the grace period timer. Using the method below will confirm this.
Check the grace period timer by using slmgr -dlv to note the number of grace minutes remaining, change the reg key that turns on skiprearm, rearm (slmgr -rearm), reboot. Again, use slmgr -dlv to see number of minutes remaining. The number will show that the timer has not been reset, showing that when skiprearm is set rearm doesn't work.
For those of you who used the skipread command to get here the summary is that the purported workaround doesn't actually work to extend activation.