Windows 10 (and Windows 7) License key – retrieve and report

Recently I got a question about Embedded License keys for Windows client OS systems.

These are systems with a Windows license key embedded in the BIOS.
If you install Windows on a system with an embedded key, it will automatically install this key and activate it.

There are several ways to get the Original License Key from a Windows machine.
  • Powershell (PS);
  • Command Prompt (CMD);
  • Windows Scripting Host (VBS).

But there is a little problem here. The key is stored as an encrypted registry key. With the first three tools this is not a problem, but with Windows 7 only the last tool, vbs scripting, is possible.
And then we have to do a little conversion
I will show how!

  • Powershell (PS)Open an administrative Powershell windows and type:
    (Get-WmiObject -query ‘select * from SoftwareLicensingService’).OA3xOriginalProductKey

  • Command Prompt (CMD)Open an administrative Powershell windows and type:
    wmic path softwarelicensingservice get OA3xOriginalProductKey

  • Windows Scripting Host (VBS)

    If you run these commands in a pre-Windows 10 environment then you get a blank result!
    But the key will still be there, if you have a activated device.
    This can come in very handy with CMDB or other inventarisation purposes.

    So where is it and how to handle this?

    This script reads the Registry key and converts this to the correct format.
    You will get the product Key which is installed on that system! GOOD

    Set oShell = CreateObject(“WScript.Shell”)
    Set oFSO=CreateObject(“Scripting.FileSystemObject”)

    outFile=”C:\Temp\Key.txt”
    Set oFile = oFSO.CreateTextFile(outFile, True)
    oFile.Write ConvertToKey(oShell.RegRead(“HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId”)) & vbCrLf
    oFile.Close

    Function ConvertToKey(Key)

    Const KeyOffset = 52
    i = 28
    Chars = “BCDFGHJKMPQRTVWXY2346789”

    Do
    Cur = 0
    x = 14

    Do
    Cur = Cur * 256
    Cur = Key(x + KeyOffset) + Cur
    Key(x + KeyOffset) = (Cur \ 24) And 255
    Cur = Cur Mod 24
    x = x -1

    Loop While x >= 0
    i = i -1
    KeyOutput = Mid(Chars, Cur + 1, 1) & KeyOutput

    If (((29 – i) Mod 6) = 0) And (i <> -1) Then
    i = i -1
    KeyOutput = “-” & KeyOutput
    End If

    Loop While i >= 0
    ConvertToKey = KeyOutput
    End Function

Happy Reading keys.

Deploy the Windows 7 Kernel Mode Driver Framework (KMDF) with ConfigMgr 2012

So you got your brand new Dell or other manufacturer’s hardware, deploy an OS with ConfigMgr 2012 and he, no go – chrash – missing drivers etc.

Well you might need the new Kernel Mode Driver Framework 1.11 (here) or the User Mode Driver Framework 1.11 (here).

But wait, this is an Windows Update! And I am doing OSD.

To successfully add the Driver Framework use good old dism
during OSD. Of course you will build a new reference image but in the meantime you have some deployment to do.

Okay let’s start.

First extract the files out of the .msu (I am using the x64 version for this). Use WinRar or 7zip for this.

In this folder create a batch file – install.cmd – containing following code:

Dism.exe /Image:%1\ /Add-Package /PackagePath:"%~dp0Windows6.1-KB2685811-x64.cab" /NoRestart

So the content of folder will now look like this (b.t.w. we do not need the .msu in the package ;-))

Create a ConfigMgr package from these files. No program needed! Distribute the content.

Now we can apply this in our Task Sequence. It has to be done AFTER the ‘Apply Operating System’, but BEFORE the installation of the ConfigMgr client.

Add a ‘Run Command Line’ and enter following as command:

Cmd.exe /c install.cmd %OSDTargetSystemDrive%

Reference the package.

Now the KMDF will be installed during the deployment!

You can do the same steps for the UMDF.

UEFI, Generation 2 VM, Windows 7 SP1 and Hyper-V Server 2012 R2 (or Windows 8.1)

With the new features of Hyper-V in Server 2012 R2 one of those is the Generation 2 VM. There is a lot to be said on this topic but here is a caveat when using Gen2 VM’s for systems older then Windows 8 or Server 2012.

Let’s start with a spoiler:

It doesn’t work for Windows 7 SP1!

If you create a VM the first question will be: a Generation 1 or Generation 2 VM

As you can see it cannot be changed…well it can 😉 (see http://blogs.technet.com/b/jhoward/archive/2013/11/06/hyper-v-generation-2-virtual-machines-part-8.aspx and http://blogs.technet.com/b/jhoward/archive/2013/11/14/hyper-v-generation-2-virtual-machines-part-10.aspx)

So you create a Gen2 VM and want to install Windows 7. Well oké, the installation is going fine. UEFI gets recognized. Everything is good. Then comes the restart

Hmm not so good. But this is to be expected. Windows 7 does not support Secure Boot! This will be turned off:

Now we try again and see this:

And here is stays, forever.

In the Hyper-V management console we see a lot of CPU Usage so it is doing something 😉

So WHY is this? Windows 7 DOES support UEFI boot. After a search I found this:

Q: Why doesn’t Microsoft support 64-bit Windows 7 or Windows Server 2008 R2 as a guest operating system in generation 2 virtual machines?


A: Certainly it is true that Windows 7 support UEFI, the first requirement for generation 2 virtual machines. However, Windows 7 has a hardware dependency on a Programmable Interrupt Controller (PIC) which is not present in generation 2 virtual machines. Even if Secure Boot is disabled, an attempt to install Windows 7 will result in an apparent hang at “Starting Windows” shortly after boot, consuming high CPU utilization. A similar effect to this will be seen if attempting a network install from a WDS server which has a Windows 7 era boot PE image – network boot will appear to hang as well. For that reason (along with the keyboard issue in Windows 8 PE) I strongly recommend any WDS server are upgraded to the Windows 8.1 PE boot image.

That is pretty clear, NO Windows 7 Generation 2 VM in Hyper-V!

P.S. DO try this with Windows 8.1 – it is incredibly FAST J

User Certificates

Note to self:

When you choose to redirect the Application Data folder the certificate store folders are NOT redirected. They will reside in the default folder.

Personal Certificates are stored under following locations:

%userprofile%\AppData\Roaming\Microsoft\SystemCertificates
%userprofile%\AppData\Roaming\Microsoft\Protect
%userprofile%\AppData\Roaming\Microsoft\Credentials
%userprofile%\AppData\Roaming\Microsoft\Crypto
%userprofile%\AppData\Roaming\Microsoft\CLR Security Config
%userprofile%\AppData\Roaming\Microsoft\CryptNetUrlCache

HKEY_CURRENT_USER\Software\Microsoft\Cryptography
HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider
HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates