Sunday, 19 June 2022

We can't activate Windows on this device

I encountered this problem recently while carrying out Windows 10 Autopilot testing on a customer site. My test device would step up from Windows 10 Professional to Enterprise but would not activate.


I could see the error: We can't activate Windows on this device as we can't connect to your organization's activation server. Error code 0x8007232B.


Running slmgr /dli on the device showed me that the currently installed operating system was expecting to be activated using volume licensing (MAK key). This isn't expected when provisioning devices directly from the vendor through Autopilot. However this was a test device so I figured it was re-imaged in the past.


Running wmic path SoftwareLicensingService get OA3xOriginalProductKey from a command prompt gave me what I needed. This displays the Windows product key embedded in the computer’s firmware. This is the original Windows key that shipped with the device.

I selected Change Product Key at the Activation window.


I entered the original product key and clicked Next.


I clicked Activate.


Windows was activated with a digital license. We wouldn't normally expect to see this problem with devices shipped directly from a vendor. However it could come in handy during customer testing in order to validate the process.

Until next time....

Wednesday, 1 June 2022

BitLocker waiting for activation

This is a quick blog post describing an annoying issue I encountered while developing a Windows 10 Autopilot process for a customer. My BitLocker policy (MEM > Endpoint Security > Disk encryption) reported as Succeeded and the recovery key was escrowed to Azure Active Directory. 


However, all was not well in the BitLocker Drive Encryption applet in Control Panel. I had the yellow exclamation warning icon with the message "Windows (C:) BitLocker waiting for activation".


The event log gave me an idea where to look. "Failed to enable Silent Encryption. Group Policy settings require the creation of a recovery key". This was Azure AD only so the Group Policy reference didn't make much sense. However it made me look for anything related to creating a recovery key in my BitLocker policy.


I found it here. I had set Recovery key file creation to Required.

What does this do? According to the tooltip "Setting this to Allow will allow an admin user to create a 256-bit recovery key file manually. Setting this to Require will require an admin user to create a 256-bit recovery key file manually. Setting this to Deny will disallow any admin user from creating a 256-bit recovery key file manually. BitLocker silent enablement requires this setting configured as Deny or Allow". I didn't want this to be required.


Changing this setting to Allowed did the trick and the device was encrypted successfully.

I hope this helps.

Until next time.......