Windows 2012

Here is a situation I run into on a frequent basis.

• We have a new server from a OEM (Original Equipment Manufacturer) like Dell, HP or Lenovo.
• The server has a factory installed OEM operating system.
• The server is setup as a Hyper-V host with virtual machines
• The user setting up the virtual machines does not have physical access to the server.
• The user extracts the product key from the host with a tool like Belarc advisor or Magical jellybean keyfinder.
• The user attempts to use the extracted product key on the virtual machines and activation is not successful.

So where did the user go wrong in the above situation?  And if the product key works on the Hyper-V host, why will it not work on the virtual machines?

Before we can answer the above questions we need to understand a little about the type of product key used by large OEMs.  Typically when a Windows operating system is installed by an OEM, an OEM_SLP (System Locked Pre-installation) key is used.  This type of key is used to save time when building servers, as the server does not have to be activated with Microsoft.  When this type of key is entered into a Windows installation, Windows will query the SLIC (System Licensed Internal Code) table located in the BIOS (Basic Input Output System) of the machine.  If the table matches what is expected, then Windows will activate.  With this in mind, a Dell OEM SLP product key can only be used on a Dell server.  And an HP OEM SLP product key can only be used on a HP server.

To answer both questions.  As explained above the product key in the Hyper-V host is an OEM_SLP key.  This key requires that Windows query the bios of the system and verify the SLIC table matches.  A virtual machine has an emulated bios from Hyper-V.  The SLIC table does not match and Windows will not activate.

Now that we understand the problem, how can we identify it.

1. A couple of questions to start with.  Did the server come pre-installed with Windows.  If so, has the product key been changed?  If the server came pre-installed with Windows and the product key has not been changed, then we likely have an OEM_SLP product key.
2. On the Hyper-V host and the virtual machine, do the following.
   1. Open an administrative command prompt
   2. run the following command: slmgr /dlv  If the Product Key Channel is OEM:SLP, then you have confirmed we have an OEM:SLP product key

The solution is quite simple.  The user needs to locate the product key sticker on the server and use the product key from it to activate the virtual machines.  Here are the commands to run, from an administrative command prompt, on the virtual machine to do this quickly:

1. slmgr /upk
2. slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx  (replace the x’s with the actual key)

Windows should then activate within a minute.

I ran across an interesting issue on Windows 2012 the other day, that I figured I would share.  I had a customer that had 4 virtual machines on the same host that were all indicating they were not genuine.  Aside from this we had 2 other strange behaviors.

1. Server Manager would not populate any of the local server information fields.  All fields showed Unknown.
2. Slmgr commands were failing with “Error:0x80070422 On a computer running Microsoft Windows non-core edition, run ‘slui.exe 0x2a 0x80070422’ to display the error text.”

When running the command slui.exe 0x2a 0x80070422 we get the following description.  The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.So which service is it talking about?

The Software Protection service. This service runs in the background and checks every minute or so whether the OS is licensed properly.  In this particular case someone had disabled the sppsvc (Software Protection service).  The fix was easy, re-enable the service and start it.

This brings me to another issue I have seen with sppsvc on several occasions.  What if the service cannot be started due to an Access Denied error.  This can typically be fixed, but we need to know where the Access Denied is coming from.  The best tool, I have found, to do the job is Process Monitor.  With this tool it is possible to see every time the filesystem or registry is touched and which process did it.

Here is how you setup Process Monitor.

1. First download the tool here.
2. Run procmon.exe from the zip file.
3. Accept the EULA.
4. Stop capturing (Ctrl+E) and Clear the display (Ctrl+X)
5. Create a filter (Ctrl+L) with the following attributes.  Result is ACCESS DENIED then Include.  Add the filter and click OK.  See the picture below.

6. Start capturing events in Process Monitor (Ctrl+E) and immediately start the Software Protection service.
7. As soon as the Access Denied error pops up, stop capturing events in Process Monitor.

At this point there should be one or more ACCESS DENIED events.  When I have seen this issue, it has always been 2 registry keys that are missing permissions; HKLM\SYSTEM\WPA and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform.

To correct the access denied issue the registry permissions will need to be restored.  Normally that would mean restoring the permission for the account starting the service, in this case Network Service.  The Software Protection service is a little different though.  There is a special account that needs to be added, “NT Service\sppsvc”.  Below are the special permissions that need to be granted on the registry keys.

• HKEY_LOCAL_MACHINE\SYSTEM\WPA.  All subkeys need to inherit these permissions.
  • Query Value
  • Set Value
  • Create Subkey
  • Enumerate Subkeys
  • Read Control
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform
  • Set Value
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\PayloadOverride
  • Full Control