↓Skip to main content
  1. Writing/

Solving The Funky 0x8007007B Windows Activation Error

·565 words
windows microsoft activation windows-11

I was recently setting up a new Windows machine for work - a desktop machine that actually has enough storage for me to run local SQL experimentation. I diligently followed the steps to create a bootable Windows 11 Enterprise USB, got the disks properly formatted, installed the OS, and tried to start customizing everything to my liking only to hit a brick wall.

I could not change things until I activated Windows. The good news, or at least so I thought, was that because I work at Microsoft, the OS should activate automatically through the internal Key Management Service (KMS). What did I do next? Why domain join the machine, of course! One reboot later, and still - Windows is not activated. Worse than that, I started getting an error when I tried to activate the OS:

Windows activation error shown in the native Windows Settings app

OK - what gives? I thought that things should just automagically work once I get my corporate credentials in? Looking online for 0x8007007B turns out to point to an error that indicates that the DNS name does not exist for the KMS server. Hm. All other computers I’ve ever joined to the corporate network after a fresh install just worked, but not this one. And for the record, I could see all the internal apps make their way on the box, so I knew that the provisioning was working. Maybe I needed to give it time?

The morning after the same story unfolded. No matter what I did, I could not activate Windows. The support person was stumped - “This should activate automatically, I am not sure why you’d see this if you’re connected to corpnet.” As I thought about it some more, one thing occurred - what if the KMS service works just fine, but there is something off with the product key? Since the dawn of Windows 8.1, OEMs could “inject” product keys for Windows machines into the motherboard. That is, the product key is stored in an Advanced Configuration and Power Interface (ACPI) table named Microsoft Data Management (MSDM). You can read more about it in the official docs (it’s a Word file download, for some reason.) The table contains some basic metadata along with the software licensing data structure that, in this case, is the Windows product key.

Anyway, so my thinking was that maybe whatever key is used for the default Windows installation is wrong and I need to extract the key that the OEM pre-provisioned with the box. The desktop itself was OEM-built, so that seemed like a safe bet. How do I get the key from the ACPI table, though? As it turns out, with a built-in Windows command:

wmic path softwarelicensingservice get OA3xOriginalProductKey

Let’s dissect this:

  • wmic - the command used to access the Windows Management Instrumentation layer.
  • path - specifies that we will be using a custom path to access WMI data.
  • softwarelicensingservice - we’re reading the software licensing data.
  • get - retrieves a specific property value.
  • OA3xOriginalProductKey - the property that stores the machine-embedded product key.

Once I ran the command, sure enough the OEM key popped up:

GIF showing the use of the wmic command to get the original product key

If you are adventurous and want to get the same command on Linux, you can do that too since ACPI tables can be read across platforms:

sudo strings /sys/firmware/acpi/tables/MSDM | tail -1

I then promptly changed the OS key to the one bundled with the box and Windows magically activated.

↑