How Microsoft licences work with MDT and WDS deployment

deploymentmdtwdswindows

The problem is the following:

My company has bought several laptops (Acer, Lenovo), those come with Windows 10 professional edition already installed, so when you start the PC for the first time you end up in a classic OOBE environment (choose country, keyboard, cortana…)

More laptops (the same as I previously described) are coming. So, I would like to have a custom Windows in order to avoid repeating and wasting time to configure each and each PC.

To do so, I already have a WDS + MDT server ready to use. My idea is to create a master image and deploy it. The thing is: my master image will not have a license key but, since I know that my laptops already have Windows activated with an OEM license, I think that after the installation of the master the OEM license key (which is stored in the BIOS) will reactivate by itself.

But after some research it seems that it is not the "Microsoft way" to do, in fact what I intend to do is very likely illegal.

So I would like to have an answer: Do you need a special license for deploying custom Windows image with WDS ?

Thanks for reading and for the eventual answer.

Best Answer

It comes down to this. Windows Professional is licensed for use on the laptop. It doesn't matter how you put the operating system on the laptop. It will always be licensed for use on that hardware. There is nothing illegal about what you are trying to do and is, in fact, an extremely common scenario.

We run a fully zero touch experience to deploy all of our new systems.

We embed the generic Windows 10 Pro product key in the unattend.xml in the specialize pass under the shell-setup section (VK7JG-NPHTM-C97JM-9MPGT-3V66T) this is sufficient for bypassing product key issues during dpeloyment.

We create an additional step in the deployment task in the "State Restore" section which runs the following powershell script to activate the system using the embedded product key:

#This script performs automatic activation during windows deployments.
#It will check if Windows is activated, if not it will try to activate with the BIOS key.

#Activation function, installs the specified product key and returns true or false if activated successfully.
function Activate
{
    #If $key doesn't exist we can't activate
    if (-not $key) { return }
    
    try
    {
    $instance = (Get-WmiObject -query 'select * from SoftwareLicensingService')
    $instance.InstallProductKey($key)
    $instance.RefreshLicenseStatus()
    } catch { return }
}

#First check and see if windows is already activated.
if (Get-WmiObject SoftwareLicensingProduct | where {$_.PartialProductKey -and $_.Name -like "*Windows*" -and ($_.LicenseStatus -eq 1 -or $_.LicenseStatus -eq 2)})
{
    #Host is already activated.
    exit
}

#Check for a BIOS key - if it exists, this is what we are going to use first.
$key = (Get-WmiObject -query 'select * from SoftwareLicensingService').OA3xOriginalProductKey

if ($key) 
{
    #BIOS Key exists - use it
    if (Activate $key) { exit }
}

You can see evidence in this script that checks if a BIOS key exists and if activation was successful:

if ($key) 
{
    #BIOS Key exists - use it
    if (Activate $key) { exit }
}

At one time we also had Windows 7 laptops which we were redeploying with Windows 10. So, we also had a volume license key for Windows 10 and the code was modified so that if no BIOS key existed, we would call the Activate function with the volume license key:

if ($key) 
{
    #BIOS Key exists - use it
    if (Activate $key) { exit }
}
else
{
    #BIOS Key does not exist - Use VLK
    if (Activate 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx') { exit }
}

You could add additional logic if activation fails as seen in the if statement:

if (Activate 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx') { exit }

And, you can go one step further to make this step in your deployment task require a certain exit code, and if it fails, the deployment task can issue a warning or failure at the end of the process alerting you to activation issues.

BIOS activation after using the generic product key has always been a little wonky. It's possible this script is not necessary at all anymore, and Windows will automatically activate itself afterwards. I think it is unlikely, because Windows has already accepted the (invalid) generic key and will not try to replace it, hence the need for the script to do so.

Related Topic