Are you experiencing problems with the automatic upgrade from Windows 11 Pro to Windows 11 Enterprise during Autopilot on the latest Windows build? Or are your current Windows 11 Enterprise devices reverting to Windows Pro? If so, this blog is for you!
I will divide this blog into multiple parts
1. The introduction:
While on vacation, a lot happened. Some of the things are way NDA, except maybe this one. I noticed some weird subscription activation issues during my vacation with the latest Windows 11 Update KB5036980 and build (22631.3447 2024-04).
Many people were contacting me, and they all mentioned the same issue.
If you have a Microsoft 365 E3/E5 license, you are entitled to a “free” upgrade to Windows 11 Enterprise. This subscription upgrade should happen automatically when the user signs in to the device. This upgrade flow relies on the subscription activation process.
This process could cause issues and prevent the device from upgrading to enterprise. I posted a blog some time ago explaining how to fix this problem. With an easy one-liner, you can ensure that Windows 11 Pro has been upgraded to Enterprise.
Windows Pro doesn’t upgrade to Enterprise with E5 license (call4cloud.nl)
Unfortunately, that one-liner from the blog above doesn’t work with this issue. Shall we zoom in on the issue and fix it?
2. The Issue
After wiping my notebook, which I use for testing, and ensuring it had the latest Windows 11 KB5036980 Updates installed (22631.3447), I kicked off the Autopilot Enrollment.
Once the device was enrolled and the user logged in, I noticed it was still on Windows 11 Pro, which SHOULD have been upgraded to Enterprise!
While determining what was happening, it became clear that a specific scheduled task responsible for uplifting the license to Windows Enterprise didn’t do its job. This scheduled task has been called: licenseacquisition
This task launches the executable cliprenew.exe but is failing with the error: access denied: (0x80070005)
If that scheduled task fails, the Windows License is NOT upgraded to Enterprise, and with it all off, the security-related features that are only applicable to Enterprise builds are not going to be applied
When looking closer again… it’s becoming more obvious what’s going on
3. Taking a closer look
To find out what was happening, I installed Procmon and just tried to kick off that task. With the proper filtering in place (Cliprenew and access denied), it became evident that the Cliprenew executable was attempting to create/seta new registry key called mfarequiredcliprenew.
Cliprenew fails to create the mfarequiredincliprenew registry key. The License Acquisition is configured to run as the “Interactive” user (logged in user)
When the scheduled task is configured to run as the interactive user account, it will execute ClipRenew in the context of the logged-in user. So, in my case AzureAd\RudyOoms
As shown above, the logged-in user is NOT permitted to create registry keys within the HKLM registry keys. If that registry key is not made, the subscription activation fails. That’s weird? What happens when I manually create that key? The first attempt ended up with the same error: Access denied. To fix this, I added “everyone” with full access to this group
Please Note: In the fix I am adding the interactive user SID!! not everyone
After adding everyone with full access, it now had the power to create an additional dword in that registry node.
As shown above, the licenseacquisition scheduled task created this dword: Verify multifactor authentication in Cliprenew with a value of 0
With this key getting manually created, the scheduled task finishes successfully, and the license is upgraded to Windows 11 Enterprise on the fly
4. Existing Devices
Typically, a 90-day rearm period is in place to manage license checks and renewals on existing devices.
However, a mechanism verifies and attempts to renew the license every 30 days for devices upgraded through subscription activation.
With the installation of KB5036980, existing devices will eventually drop from Windows Enterprise to Windows Pro, depending on their update ring. This update causes the scheduled task responsible for renewing the license to fail due to a permission issue with creating necessary MFA registry keys. As a result, the device cannot maintain its Enterprise status.
With the device dropping from Enterprise to Pro, all the security features, such as credential guard, that work with Enterprise will stop working with Windows Pro!! If this isn’t going to cause a sh.t show, I even talked about the Policies only applicable to Enterprise yet.
5. Why is MFA going to be Required
I guess it’s pretty obvious that Microsoft is going to require MFA when you use the subscription activation to upgrade your license from Windows Pro to Windows Enterprise.
How will this look when MFA is required? As shown below, users will be prompted for authentication with a toast notification when Subscription Activation needs to be reactivated. This toast message would read: Please Sign in to your work or school account to verify your information.
Authentication prompts typically appear when a device has been offline for an extended duration. With Windows 11, version 23H2, and KB5034848 or later, this change removes the necessity for an exclusion in the Conditional Access policy. However, a Conditional Access policy can still be applied if you prefer not to prompt users for authentication via a toast notification.
6. The PowerShell fix option 1
If you want to fix it in the meantime before Microsoft releases the official fix, you could deploy this PowerShell script to your device during Autopilot. This will ensure the license acquisition scheduled task can be launched.
# Define the registry key path and value$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew"$registryValueName = "Verify Multifactor Authentication in ClipRenew"$registryValueData = 0 # DWORD value of 0$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-4") # or SID S-1-5-4 for the interactive group# Check if the registry key already existsif (-not (Test-Path -Path $registryPath)) { # If the key doesn't exist, create it and set the DWORD value New-Item -Path $registryPath -Force | Out-Null Set-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -Type DWORD Write-Output "Registry key created and DWORD value added."} else { Write-Output "Registry key already exists. No changes made."}# Add read permissions for SID (S-1-5-4,interactive users) to the registry key with inheritance$acl = Get-Acl -Path $registryPath$ruleSID = New-Object System.Security.AccessControl.RegistryAccessRule($sid, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")$acl.AddAccessRule($ruleSID)Set-Acl -Path $registryPath -AclObject $aclWrite-Output "Added 'Interactive' group and SID ($sid) with read permissions (with inheritance) to the registry key."#Start the scheduledtaskGet-ScheduledTask -TaskName 'LicenseAcquisition' | start-scheduledtask#starting cliprenew manually shouldnt be necessary with starting the task#Start-Process "$env:SystemRoot\system32\ClipRenew.exe"This PowerShell script will ensure that the corresponding MfaRequiredInClipRenew registry key is created with full access to the interactive user group.
If you are licensed for pro-active remediations, you need to use them. As mentioned before, this bug also impacts existing devices and not only new enrolled devices.
This PowerShell remediation script would detect and remediate when the required MFAin Cliprenew registry key does not exist!
https://call4cloud.nl/wp-content/uploads/2024/07/subscription_remediation.zip
Please note: Make sure you configure the Remediation to run in 64-bits
7. The code behind it
While fixing the issue, my curiosity got the best of me. I opened cliprenew.exe with IDA and started looking into it. The handle access denied feature was added to the cliprenew.exe in the mainhr function.
When getting a better view by using the pseudocode, it looks like it is indeed trying to create or open the mfarequiredkey just at the first steps of the licenceactivation
This part of the licenceactivation will check if a specific feature related to Multi-Factor Authentication (MFA) is enabled. If this MFACheckinClipRenew feature is enabled, it proceeds with additional actions.
The code attempts to create or open a specific registry key related to MFA: SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew.
If the registry operation is successful, it sets a DWORD value (Verify Multifactor Authentication in ClipRenew) under the specified registry key to 0.
This mfacheckincliprenew (38124097) feature was added in the Windows Insider buildand now being activated in the latest Windows April Build
That got me curious if I could come up with a different fix. I downloaded the Vivetool and manually disabled that feature.
After disabling it, Cliprenew could uplift the license to Windows enterprise.
8. Waiting for the Fix From Microsoft
After getting more feedback, it seems that Microsoft has been aware of this issue for some time and is working on a fix.
This message tells us that Microsoft is working on a resolution, and the fix will be released as a security update in the coming weeks. I guess the image below explains it all.
9. The July KB5040442
Microsoft has acknowledged this issue and released a potential fix in the Windows Insider Preview Build 26227.5000, which adds a feature to handle access denied errors during license upgrades. However, my tests showed that the fix is not entirely effective, as the required registry key is still not being created, although the task no longer produces errors.
Subsequent updates in June (KB5039302) and July (KB5040442) incorporated these features but did not fully resolve the problem. My comparisons revealed no significant changes in the July update, indicating that a complete fix is still pending. Until then, a manual workaround involving the creation of the necessary registry keys and permission adjustments remains essential. Hopefully, future updates will address the issue entirely.
Check out the Patch My PC blog below. This blog shows how the June and July updates now contain a new feature to handle the denied access message.
KB5040442 does not fix your Subscription Activation issues (patchmypc.com)
10. July Preview Update KB5040527
As expected, Microsoft has enabled the handle_access_denied feature mentioned, which I explained in the Patch my PC blog above. This handle_access_denied feature was previously disabled by default but is now enabled with the KB5040527 preview July update.
With this feature enabled, it will ignore the results of the mfarequiredkey creation. This bypass allows the scheduled license acquisition task to execute successfully. Once this task is executed successfully, your Windows will upgrade to the Enterprise edition again.
For all the details, read the full blog below.
https://call4cloud.nl/2024/07/kb5040527-fixes-subscription-activation-issues/
Conclusion
With the insider build, a function was added to require MFA for the subscription activation (part of the DMA SSO?), but somehow, it failed to create that registry key.
Can we give the user local admin permissions to fix it (just like the developers who wrote that code?), or will we deploy a PowerShell script that creates the required keys?
