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.
- 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.
- On the Hyper-V host and the virtual machine, do the following.
- Open an administrative command prompt
- 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:
- slmgr /upk
- 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.
- Server Manager would not populate any of the local server information fields. All fields showed Unknown.
- 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.
- First download the tool here.
- Run procmon.exe from the zip file.
- Accept the EULA.
- Stop capturing (Ctrl+E) and Clear the display (Ctrl+X)
- 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
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SoftwareProtectionPlatform\PayloadOverride
I ran across a great blog article on setting up a split DNS (Domain Name System) zone this morning. It got me to thinking though, can I do this in PowerShell? The answer is yes. And it is quicker than using the DNS management console. Change the zone name and IP address to match the name and server IP respectively.
- Add-DnsServerPrimaryZone <test.mydomain.com> -ReplicationScope “Forest”
- Add-DnsServerResourceRecord -A -Name “.” -ZoneName <test.mydomain.com> -IPv4Address <188.8.131.52>
If you have a way of doing this command in one line I want to hear about it. Post it in the comments below.
Here is a scenario that I have run into a few times. An Active Directory environment where the PDC (Primary Domain Controller) Emulator role is hosted on a virtualized domain controller that is running on Hyper-V. It is perfectly acceptable to do this, however it is very likely that the environment will suffer from time drift. In some cases this it can be a big problem. Here is a solution I have tested and found to work well.
- Remove time synchronization for the PDC Emulator in Hyper-V:
- In the Hyper-V management console, go to the settings for the PDC Emulator domain controller.
- Select Integration Services and uncheck Time synchronization.
- Set the PDC Emulator to synchronize with an external source.
- Connect to the PDC emulator
- Download and run the following Microsoft fix it.* Set the NtpServer to us.pool.ntp.org,0x1
- Run the following commands in an administrative command window:
- net start w32time
- w32tm /config /manualpeerlist:“us.pool.ntp.org,0x1” /syncfromflags:MANUAL /reliable:yes
- w32tm /config /update
- w32tm /resync
- w32tm /resync /rediscover
- In the same command window run w32tm /query /status. At this point the source should be us.pool.ntp.org.
- Set the peer domain controllers to sync with the PDC Emulator.
- Connect to each peer domain controller and run the following commands in an administrative command window:
- w32tm /config /syncfromflags:DOMHIER /update
- net stop w32time && net start w32time
- w32tm /resync /force
* If the link no longer works, then go here and choose the fix it for me under “Configuring the Windows Time service to use an external time source.”
I ran across this issue today with a customer and it took quite a bit of digging to find a solution. Here is a screenshot of the error:
In digging around I found there is a utility to address this issue, but I am cheap and don’t want to pay for something if I can find an alternate solution. Without further ado, here is how you fix it.
To delete a file:
- Open an administrative command prompt.
- Run the following command: del “\\?\X:My Directory\Bad File.ext” (Replace everything after \\?\ with the actual path to the problem file.)
To delete a folder/directory:
- Open an administrative command prompt.
- Run the following command: rd /s “\\?\X:My Directory\Bad Directory” (Replace everything after \\?\ with the actual path to the problem directory.)
Where is that easy button?
Thanks to Rayza73 who posted this on the Microsoft forums.