Scheduling Software Licensing

Delaying Activation Legitimately

Overview

This process (of delaying activation legitimately) is entirely by Microsoft's design, utilizing the primary purpose of tools (slmgr.vbs and portions of the Operating System setup) that were intentionally designed to provide these sorts of options. Therefore, this is not considered to be cracking, piracy, or any other sort of unauthorized ways to completely bypass Microsoft's Activation requirements.

Microsoft KB 948472: How to extend the Windows Server 2008 evaluation period is believed to fully apply to at least Windows 7 as well, and might also apply to other versions of Microsoft Windows.

When interactively installing Windows 7 or Windows Server 2008, an option is provided to delay providing any sort of Product/Activation “CD”/“DVD” “key”/“code”. Simply check or uncheck the appropriate box, and then carefully choose the correct option.

After installation, there is a program provided which can extend a period of full functionality. Also, the program can be run multiple times (although the number of times may be limited). So, instead of simply allowing a trial of up to a full year, the actual limit may be something like 30 days plus up to twelve 30 day renewals. There doesn't seem to be any real point in breaking up the usage period into multiple segments, except to be requiring a process which can serve as a regular reminder of the eventual activation requirement. However, as MS KB 948472 was written to clearly point out, even that can be automated.

Overview/info

Note that this is a VBS file, which means that it is probably copiable. And, as the source code is clearly visible for anyone with the program, the copy could be studied/modified. The slmgr.vbs is said to use WMI (although it would not be incredibly surprising if that might change with some version of Microsoft Windows). With WMI, one could use:

WMIC Class SoftwareLicensingService
WMIC Class SoftwareLicensingService Call reArmWindows

Although, that isn't anywhere close to tested.

WARNINGS/DISCLAIMERS

This is a technical guide. This is not meant to provide any depth to the questions of what rights are permissable with any specific license. This is simply showing how to extend any available time to be able to use the product.

The directions here may be a bit sub-optimal. It seems likely that the slmgr.vbs obtains a number of seconds, and that completing the execution of a ReArm needs to be done before that number of seconds. However, some of the details, especially precise details related to timing, have not been fully verified by the author of this text. The number of days may be shortened by some overly-conservative directions. Some speculation may be included in these directions. (To whatever degree testing may be insufficient, simply perform your own testing rather than entirely relying on these directions.)

Perhaps a WMI command can be initiated from a remote computer to re-arm a computer that has had its time expire, but this is not verified.

Accessing a remote machine

There appear to be various approaches, none of which are fully discussed here. However, here are some strong pointers: slmgr.vbs seems to use WMI, which seems to typically allow some remote access. The slmgr.vbs command syntax shows that the slmgr.vbs command can accept a machine name. Modern versions of Windows are implementing Task Scheduler as an MSC file which typically permits remote access, and “ SchTasks /Create /? ” shows some command line parameters to related to working on a remote machine.

Determining code to execute

First, figure out what file will be used that contain's the code of the software license manager. This first step isn't about figuring out the options to pass to the command. This is simply determining what code to run.

On some systems, it is:

slmgr.vbs The command should display a few (probably four) screens of help.

On other systems, it has apparently been documented to be:

cscript slmgr.vbs

which displays output to easily redirectable standard output. However, on at least some systems, that seems to not work if the file cannot be found. You can also try:

cscript "%windir%\System32\slmgr.vbs"

which will probably work, but if it doesn't (perhaps in a later version of Microsoft Windows), the following also looks like it would work just as well:

cscript "%windir%\SysWOW64\slmgr.vbs"

Determine the amount of time left

cscript "%windir%\System32\slmgr.vbs" -dlv

(This may go slower the first time. May need to wait a while, perhaps 10 seconds.) (Alternatively, you could use -dli instead of -dlv and it will show less information. Using -dli allows you to see the time left, but not the amount of rearms available. Running -xpr may be another way to show less information.)

cscript "%windir%\System32\slmgr.vbs" -dlv | find /i "License Status: "
cscript "%windir%\System32\slmgr.vbs" -dlv | find /i "Time remaining: "
Side note: How to see how many Rearms are available

WMIC PATH SoftwareLicensingService Get RemainingWindowsReArmCount

or, more verbosely:

WMIC /namespace:\\root\cimv2 PATH SoftwareLicensingService Get RemainingWindowsReArmCount

The previous method may be more familiar to people who extensively use WMI, providing some capability for remote access. Alternatively:

cscript "%windir%\System32\slmgr.vbs" -dlv | find /i "Remaining Windows rearm count: "

Problems
[#slmgrrbt]: Reboot needed

After the system has been re-armed, this may fail to work properly until the system is rebooted. Instead, a “Windows Script Host” window may appear, referencing an Error Code of 0xC004D302. (That was the “Error”. The script's source “Code” showed the same hexadecimal number but without the “0x” prefix.) Taiwan CSS Platform Team has been known to document this cryptic and user-unfriendly error which indicates there is a need for the system to reboot.

Trying to use slmgr.vbs to get information on licensing may even cause Windows 2008 KMS client to lose activation status, as described further in this “Similar errors” section:

Similar errors

On a side note about this error message: Apparently the same hexadecimal error code number might also be used by some other software related to Windows Licensing/Activation. In at least some cases, there may even be some other causes for that error code. The troubleshooting may be resolved by Taiwan CSS Platform Team info on 0xC004D302 cites a potential causes:

  1. Default permissions of %ProgramData%\Microsoft\Crypto\RSA\MachineKeys have been changed
  2. A tokens.dat licensing file has some corruption
  3. After re-arming with slmgr.vbs, and then trying to use a command related to activation (such as slmgr.vbs/dlv or the less detailed slmgr.vbs/dli) before a reboot.
Resolution

The recommended process is:

  1. [#msrbdtkn]: Rebuild the tokens.dat file (following Microsoft's instructions), as described here.

    Rename the relevant tokens.dat. MS KB 978305 might show how? Or, Taiwan CSS Platform Team info on 0xC004D302 shows:

    cd "%windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\"

    Then:

    in Windows Server 2008 R2 or Windows 7
    cd SoftwareProtectionPlatform
    In Windows Server 2008 (not Windows Server 2008 R2) or Vista
    cd SoftwareLicensing

    Then, rename the tokens.dat file (e.g. from the Taiwan team's article: tokens.old). Applying information from the section on moving/renaming files, an example command would be:

    ren tokens.dat tokens.bad
  2. Then, re-activate. Taiwan CSS Platform Team info on 0xC004D302 provided the following options:

    Re-activating over the Internet
    slmgr -ato

    Speculation: If the slmgr command is not found, try a variation such as:

    cscript "%windir%\System32\slmgr.vbs" -ato
    Re-activating using a process involving calling Microsoft over the phone
    slui.exe -4
  3. If that doesn't work, rebooting is probably a good idea.

These steps involve a simplification of the process for rebuilding the tokens.dat file.

Scheduling initial re-arms
Required steps
Identify the start date

In this example, the operating system was installed on January first, in the year 2010. As a demonstration, we're simply pretending like this action (setting up the scheduled task) is being done in the middle of January in 2010. Of course, that is in the past, so some adjustments will need to be made for actual usage (if the computer's clock is set accurately).

The dates are being shown in the American style of MM/DD/YYYY.

The re-arm needs to happen before 30 days later. So, in theory, we could do this on January 29th. However, just to be on the safe side, this will be done a few days earlier.

Note that this may require that the machine is turned on? If the computer is only turned on when a weekdays that are not part of a 3-day weekend, then subtracting 5 days (so, 25 days instead of 30) might be a good idea. (The reason for 5 days is just to use a fairly conservative estimate, in case there is another loss of a day due to some other reasons, like if the software might round up, time zone changes when traveling, etc.)

To be safer, perhaps subtract a couple of days from the re-arm time (which reduces the number of days the OS can run, but might help to compensate for terrible rounding errors).

Pick the end date

Have this be more than 90 days away, but less than 100.

The reason: 90 represents 3 rearms x 30 days between re-arms. 100 represents the 4th time that the script would want to run a re-arm, if re-arms are being done 25 days apart (using a 5 day grace period like mentioned before). The actual goal is to pick something between the 3rd and 4th times that this script would run.

Know what command is needed to run the script file

This is covered above. This sample assumes that the command's name will be:

cscript "%windir%\System32\slmgr.vbs"

If there's question about that, try running the script with -dlv as a safe way to test running the script.

cscript "%windir%\System32\slmgr.vbs" -dlv

The quotation marks need to be escaped, so the value that we're going to use is:

cscript \"%windir%\System32\slmgr.vbs\"
Elevated command prompt

Since, presumably, the results of “ERROR: Access is denied.” (followed by one completely blank line) would be undesirable, if UAC is enabled then use an elevated command prompt.

To run this every 29 days:

SchTasks /Create /SC DAILY /MO 29 /RU "SYSTEM" /SD 01/26/2010 /ED 04/05/2010 /TN Rearm /TR "cscript \"%windir%\System32\slmgr.vbs\" -rearm" /ST 03:45 /F /RL HIGHEST

This does not try to stop after a dozen tries, but currently there is little to no harm expected from retrying. (This may be based on some speculation, and hasn't yet been fully tested/challenged at the time of this writing.)

Making the task more resilient

There is a “Allow task to be run on demand” checkbox on the Settings tab.

For those who wish to rely less on using the GUI regularly, there is another process. The simple way to start is to use the GUI once, to create an XML file.

Nick's SuperUser.com question notes that the “Run task as soon as possible after a scheduled start is missed” does not have a corresponding command line option, but that option can be used by making and using an XML file.

The checkboxes's effect is to add the following lilnes under “<IdleSettings>”:

<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>

Realize that the XML file contains a UserId value. (That value might need to be customized if using multiple computers.)

Once you have the desired XML file, you can create a new task by having schtasks use that file. (See the SuperUser.com hyperlink, mentioned earlier, for an example syntax.)

Required reboot

After the re-arm is performed, a reboot may be needed to get the operating system to really function properly. This probably should be done rather interactively if a user is logged in, such as displaying a dialog box that notes the need to reboot. Perhaps a message could be displayed with the same retry period, but with a start date that is one day later (or with an identical start date, but a start time that is a bit later). The potentially tricky part is how to avoid the message if a reboot is performed before the message is scheduled to occur.

If the reboot is not performed, then the Windows licensing software starts to have some problems. One is that checking the status of the Windows licensing may not work: running slmgr.vbs/dlv or slmgr.vbs/dli may show an error message (like “0xC004F009 (grace time expired).” Also, the system may pop up notices (small and temporary “system tray”/“message notification” notices, as well as pop-up windows) referencing the non-activated state. For instance, an “Optional update delivery is not working” dialog box may show (in a larger-than-normal font) “You may be a victim of software counterfeiting.” Those pop-ups may occur on a frequent basis, possibly stealing focus (eating keystrokes, and backgrounding any full-screen application that may be running). Comptuers running Microsoft Security Essentials may complain, stating, “Windows did not pass genuine validation.” and “Security Essentials will become disabled in” (some number of) “days if you do not resolve this issue.” If the re-arm has already been performed, a simple reboot may resolve all of those problems.

Allowing more re-arms

Note: Following are some techniques that have been documented. There are varying reports on whether these work. Techniques involving SkipRearm may be intended for use with the software called Sysprep.

Eventually, the results of “ %windir%\system32\slmgr.vbs -dli ” results in showing “License status: Notification” and “Notification Reason: 0xC004F009 (grace time expired).” Trying “ %windir%\system32\slmgr.vbs -rearm ” as a standard user may cause interference by UAC, resulting in “Error: 0xC004F025 Access denied: the requested action requires elevated privileges”. Handling user account control can get past that problem, but still results in “Error: 0xC004D307 The maximum allowed number of re-arms has been exceeded. You must re-install the OS before trying to re-arm again”. (In that case, the “error level”/“return code” is -1073425657.)

You could re-install the OS, but there may be another way to delay such an action.

Using SkipRearm

Simply run:

Reg ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform" /v SkipRearm /t REG_DWORD /d 1 /f

For users of Windows Vista, the appropriate registry key may be “SL”, not “SoftwareProtectionPlatform”. The name of the value in that key is still SkipRearm.

This could even be scheduled ahead of time. Note that the example date is intentionally about 86 days after the previous example. (That is roughly 3 months ahead, but also backing the day of the month by a day or two... or a few.)

SchTasks /Create /SC DAILY /MO 29 /RU "SYSTEM" /SD 05/19/2010 /ED 05/20/2010 /TN Rearm /TR "REG DELETE \"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\" /v SkipRearm" /ST 01:23 /F /RL HIGHEST
SchTasks /Create /SC DAILY /MO 29 /RU "SYSTEM" /SD 05/21/2010 /ED 05/22/2010 /TN Rearm /TR "REG ADD \"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\" /v SkipRearm /t REG_DWORD /d 1 /f" /ST 02:34 /F /RL HIGHEST

After the registry gets modified, then “cscript "%windir%\System32\slmgr.vbs" -dlv” may still result in saying “Remaining Windows rearm count: 0”. However, just ignore that fact. (This is simply commentary. There is no need to run that command at this time.) Instead, proceed with running this:

cscript "%windir%\System32\slmgr.vbs" -rearm

needs to be run. (Note that if scheduled tasks are being used, as desribed elsewhere in this section, then this might be already scheduled to occur automatically. If scheduled tasks are not being used to run the command before the expiration, then this may need to be run manually.) If running the command from an interactive command prompt, the output may be easy to see. The following is some output seen on a Windows 7 machine:

Command completed successfully.
Please restart the system for the changes to take effect.

Another approach, instead of deleting the registry key first, would be to just try adding the registry key. However, if an older value exists, then the REG command becomes interactive. That can be worked around by piping the results of an ECHO command. However, using the SCHTASKS command to insert a pipe (into a new task) seemed unnecessarily complicated (and might not be realistically easily feasible). If the scheduled task ran a file, such as a batch file (or a VBScript file), then that might be far less problematic of an alternate approach. (Another approach may be to use REG's /F parameter, if that is supported. Run REG ADD /? to check.)

It does seem that the registry key should not be modified until after the third re-arm, or else some potential re-arms become unavailable. This, and many of the other crucial details to adding more re-arms, was based on some information that was found thanks to: TechTipsGeek.com article on extending a Windows 7 trial period up to one year.

After running the command to re-arm, make sure that the required system reboot is performed. Also, know that re-arming will revert that registry value back to zero.

More task handling details

schtasks: /Z to delete afterwards (may be undesirable for a recurring event. Also, if this process is being rather tested, then leaving off /Z may ease the ability to check results of an attempt to run a task.)

Note: If the system still appears to be de-activated after the reboot, there might not be a recommendable workaround. There have been other techniques involving deleting data or denying permissions, but these did not seem to be methods that Microsoft ever intended as an authorized way of handling activation/licensing. In contrast, the Re-arm processes (which were just described) were, clearly, intentionally created by Microsoft.

Misc info

misc info: Software Licensing Classes (part of a section on WMI classes)

SS64 page on slmgr notes that /xpr will show information about an expiration date. e.g.:

Windows(R) 7, HomePremium edition:
    The machine is permanently activated.

WinVer can also provide info about whether a system is activated.

[#rbdtkndt]: Rebuilding tokens.dat

MS KB 2736303 shows commands to stop a licensing service, locate a tokens.dat file, rename it, and restart the licensing service.

Stop service
Win 7/2008R2/8/2012
net stop sppsvc
Win Vista and Win Server 2008
net stop slsvc
Change directories
cd %windir%\ServiceProfiles

Then...

Win Server 2012 and Windows 8
cd LocalService\AppData\Local\Microsoft\WSLicense
Win 7/Vista/2008(R2)
cd NetworkService\AppData\Roaming\Microsoft

Then...

Win 7
cd SoftwareProtectionPlatform
Win Vista and Win Server 2008
cd SoftwareLicensing
Remove tokens.dat
move tokens.dat tokens.bak
Start software licensing service

Use “net start ”, followed by the service name, similar to how the service was stopped earlier.

Rebuild tokens.dat file
cscript "%windir%\System32\SLMgr.vbs" /rilc

Microsoft's instructions regarding the re-creation of the tokens.dat file.

Some results
0xC004D307
C:\> cscript //Nologo "%windir%\System32\slmgr.vbs" -rearm
Error: 0xC004D307 The maximum allowed number of re-arms has been exceeded. You m
ust re-install the OS before trying to re-arm again


C:\>

(Return value: -1073425657)

Rearms have been run too many times. This is based on information stored in the HKLM\MY_SYSTEM key's value called “wpa”, which stands for “Windows Product Activation”. That value cannot be deleted while booted from the main operating system that uses that value. Various approaches that Microsoft does seem to endorse may include: follow Microsoft's instructions about re-building the licensing data, or re-install the operating system, or contact Microsoft about activating the software.

0xC004F025
C:\> cscript //Nologo "%windir%\System32\slmgr.vbs" -rearm
Error: 0xC004F025 Access denied: the requested action requires elevated privileg
es


C:\>

(Return value: -1073418203)

The software cannot rearm while being restricted by UAC. (See the section about user account control.)

Available keys

Perhaps these may be helpful? Microsoft has publicly released keys for some operating systems (including Win7 Pro/Enterprise, but not Win7 Home, and at least some variations of Vista, Server 2008, 8, Server 2012, and 10) that are compatible with Microsoft's “Key Management Service” (“KMS”), at: Volume Activation Appendix A: KMS Client Setup Keys