Factory reset Windows Server 2012 R2 Standard Virtual Machines

The reason you can't activate it is because you are not connected to the internet. I learn it the hard way. 2012 R2's error is very generic. When you put the license key, it try active the license right way. Because you dont have internet, it cant verify it.

Here is for anyone who try activate over phone on machine that has no internect connection.

Here is the trick I finally figured out.

You can't activate windows by phone because you have not put in the correct product key number. Here are the steps and I was able to activate over the phone. I have not see any one post these steps yet. I spent 4 days with Microsoft trying to get some helps. With other user's input and I was able to put together the complete steps.

1.To Change Product Key Number in a Command Prompt Open an elevated command prompt. In the elevated command prompt, type in the command below and press enter.

NOTE: Substitute XXXXX-XXXXX-XXXXX-XXXXX-XXXXX in this command below with your actual product key number with dashes instead. slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

2.type slui.exe 4 to access the phone activation screen and follow the steps to activate over the phone.

We escalated the problem up to Microsoft Premier Support and got a kernel debug specialist working on it; he discovered that something uninstalled all Hyper-V drivers from the guest VMs, thus rendering them completely unable to boot; he managed to get one of them to boot by manually injecting the drivers in the file system and Registry of the VM, and we were able to get back some critical data (it was a Certification Authority); however, the VM was now in a completely unsupported state, and thus we decided to rebuild it; we also rebuilt all the other VMs, which had no critical data on them.

As for what actually caused the driver uninstallation, the case is still opened, and the cause has not been found yet; the problem was latent in the template we used, because it sooner of later affected all the VMs which had been deployed using that template; we built another template, and this one didn't show the same issue, so we are running fine now... but we still don't know what caused the problem in the first place.

Update:

After a while, we FINALLY found what happened (I just forgot to update this answer before).

It looks like someone or something forcibly updated the Hyper-V Integration Services in the base template, which already had them, being based on the exact same O.S. release of the hosts; this caused a latent issue in the guest system where those drivers would be marked as duplicate and/or superseded, and thus in need of being removed; but this event would only trigger after a variable time interval, when Windows performs some periodical automated cleanup process. This eventually led to the complete uninstallation of all Hyper-V drivers on each VM instantiated from that template, rendering it completely unable to boot.

As for who or what performed this update (which can't be done by inserting the Integration Services setup disk and running its setup, because the installer correctly detects the drivers are already installed and exits), we still have no clue. Either someone who should have known better did it manually using PowerShell or DISM, or SCVMM was the culprit.