How to solve the problem of virtual organization machine for license expiration in the experimental environment of delivery

The recent discovery of a Windows Server 2008 R2 Lab environment in our running test system has caused a major problem in the experimental environment because the license has expired and the delivery test system is in a separate network segment, so it cannot be activated through the company's built-in KMS server. This expired virtual server, will be shut down once every 1 hours, simply let my head is very large; in the face of this problem, the students generally expressed understanding and discomfort, of course, the design of the experimental environment, I naturally feel the fire big!

Is there a good way to keep my environment for experimental purposes never expiring? Considering that our lab's mechanism is for the experimental environment to be refreshed every time to the snapshot state, however, the time of the virtual machine is not locked, so the time of each virtual machine will shift with the system time, so expiration is unavoidable, unless we deliberately modify the physical machine time of the hosted virtual machine, but this is not a long-term solution If you can extend the system for 10 days by Slmgr/rearm, note that the snapshot is refreshed while the system time changes, but the number of rearm that are logged in the registry (3 times by default) will not change. This gives us the possibility of an unlimited number of rearm per refresh and delivery of the test system! And our experimental environment is basically refreshed every two days, so there will be no more problems than rearm time. Well, with the train of thought, the rest is better solved.

First, the way I think of it is to use CMD to create a batch of commands, simple as follows:

REM---Judge whether rearm has been done, and if not, enter the rearm process, if there is a end

If not exist c:\Scripts\rearm.tmp call:create

Goto END

: Create

REM---Create a flag bit (the first rearm process creates a file) that guarantees that rearm will not fall into a reboot after the test (because it has been rearm)

echo rearm >> c:\Scripts\rearm.tmp

REM---Invokes the background rearm action through start because the rearm process is interactive and cannot be interacted while running in the background so set to background startup

Start Slmgr/rearm

REM---is very important to test this step, first rearm need to restart in order to take effect, if you do not set background startup, shutdown will wait for rearm after the end of the interaction, but background-initiated rearm is not interactive process, So what we're setting here is that shutdown and rearm are running in parallel in the background, and by tweaking the 50 virtual machines in our environment, setting a delay of 180 seconds can ensure that all rearm actions are completed and the delay is restarted. After the test found that if the time is too short, and the physical machine load is heavy, there may be rearm did not complete the restart of the virtual machine caused the system does not extend the problem, so please ensure that rearm enough time;

Start SHUTDOWN/R/f/t 180

Goto:eof

: End

The above script completes the rearm work to the system, then also need to configure in the system's scheduled task each boot to carry on the rearm judgment the cmd script logic, the approximate process is as follows:

Enable scheduled Task management