This should really be “SKUs, Glorious (Windows) SKUs, part 3” after the previous part 1 and part 2 posts, but for whatever reason multi-part posts don’t get as many views. The joys of being able to see statistics, and the weirdness of blog readers. But on to the real topic: Virtual SKUs.

As the previous posts discussed, there are a plethora of Windows 10 SKUs, driven primarily by “segmentation of the market” (i.e. maximizing revenue). But these aren’t like the original Windows SKUs that had a rather cumbersome process to go through to upgrade them, requiring either a full in-place upgrade (going back to the Windows 7 days) or a “transmog” process that could transform to a higher SKU via a process that potentially pulls in additional Windows components (for new features) as part of a relatively-lengthy process that requires a reboot.

Instead of this process, the “virtual SKU” process uses effectively one OS image containing all the possible features from all the derived editions that it can become, and depending on the product key that is injected, it “becomes” a different SKU. Behind the scenes, there is a software licensing API (SLAPI) that tells Windows what features are currently enabled via a SKU matrix manifest that could be modified at any time. All of these Windows features then query that API to determine if they are currently enabled; if they aren’t, they just quietly “shut down” (more on that later).

So what do you need to do to change the active virtual SKU? Simple, just inject a new product key, or activate a new subscription using Azure AD-based Activation. Either way works. This process is instantaneous and doesn’t require a reboot. But what SKUs support this? The simplest starting point is with DISM, querying the list of available targeted editions:

Let’s cross-reference that with the list of available “setup keys” from this web page:

You might have noticed that I removed some rows from that table, all having N or G suffixes. I really don’t care about those as they aren’t widely used anywhere (as discussed in the previous posts), and you can’t change from an N or a G SKU to a non-N or non-G SKU (if you installed one accidentally, give up and reinstall). But that’s still a shorter list than what is displayed by DISM. So let’s dig around a little more to see if we can find any other keys. This used to be a fairly easy process, since you could look at the PRODUCT.INI file on the Windows 10 media, but that seems to be missing now on most of the ISOs I’ve checked. But a little random web searching can come up with at least one other value:

But I can’t find a product key for IoT Enterprise SAC (the listed value wouldn’t be an LTSC release as LTSC releases use different product keys with each release) or the “other” lesser-used Pro SKUs. But that’s OK, we’ve got a good enough list. And these product keys can’t be activated anyway, so if you want to continue using them after they are changed to a different SKU, you have to activate them using some available method (e.g. KMS, Azure AD Subscription Activation, etc.).

So if I take my device that is running Windows 10 Enterprise, I should be able to feed it a new product key and immediately see the new SKU. The easiest way to see that is with WINVER:

The “Windows 10 Enterprise” text above will dynamically change as the SKU changes. Wrap all of that into a simple PowerShell script and we can quickly cycle through all of the available keys (with the final key being Enterprise so that the OS ends up right back where it started):

$keys = @(‘W269N-WFGWX-YVC9B-4J6C9-T83GX’,
‘NRG8B-VKK3Q-CXVCJ-9G2XF-6Q84J’,
‘6TP4R-GNPTD-KYYHQ-7B7DP-J447Y’,
‘NW6C2-QMPVW-D7KKK-3GKT6-VCFB2’,
‘NJCF7-PW8QT-3324D-688JX-2YV66’,
‘NPPR9-FWDCX-D2C8J-H872K-2YT43’)

$keys | % {
& cscript.exe c:\windows\system32\slmgr.vbs /ipk $_ | Out-Host
$p = Start-Process “winver” -PassThru
Start-Sleep -Seconds 2
Stop-Process $p
}

Here’s what that looks like (in a simple animated GIF):

So as you can see, not only can you upgrade to a higher virtual edition, you can also switch to a lower one (which if you think about it makes sense because Windows 10 Subscription Activation works that way — if you remove the subscription, the device goes back to Pro). And if you look carefully at the output, you can see the new “official” name for “Windows 10 Multi-session” which I can never remember…

There is an interesting side effect of these virtual SKUs too: SKU-specific rules become fairly easy to bypass. For example, if you look at the upgrade matrix for Windows 10 Home, you’ll see that you can upgrade from Home to Education directly, but not from Home to Enterprise. But you could upgrade from Home to Education and when that process completes then inject an Enterprise key. (That doesn’t change anything from a licensing requirements perspective as you still need for the device to be properly licensed for Windows 10 Pro as a qualifying OS before you run Windows 10 Enterprise on it.)

What about Windows 10 media?

So if these are all virtual SKUs built off the same base, why are there even different images in the default Windows 10 WIMs (at least for Business SKUs where this is supported — the consumer ones are typically “real” SKUs)? More for convenience for OEMs and IT Pros. Each image is just captured with the appropriate setup key preinstalled — otherwise, the images are identical (with other minor differences captured as a result of the sysprep process). That’s how you can store so many images in a single WIM file without dramatically increasing the size: all the files (except the registry and random log files) are the same.