Great news! The July Preview KB5040527 update has finally fixed the Windows subscription activation issue that plagued the upgrade from Windows 11 Pro to Enterprise. While we’re all thrilled about this fix, you need more details to understand the complete picture.
1. Introduction
In a recent journey through the world of Windows updates, we encountered a significant roadblock with the April Windows update KB5036980, which disrupted the automatic upgrade from Windows 11 Pro to Enterprise.
Besides disrupting the automatic upgrade from Pro to Enterprise, it also impacted existing devices, causing them to drop back to Pro. When they dropped back to Pro, all the enterprise-based security features stopped working!
This issue was caused by a permissions problem with the registry key MFARequiredInCLIPRenew, which I explained in a previous blog post on Call4Cloud.
https://call4cloud.nl/2024/05/kb5036980-breaks-upgrade-windows11-enterprise
2. Initial MFARequiredInClipRenew Fix
The initial problem was identified when the LicenseAcquisition scheduled task responsible for the subscription activation failed due to permission issues with the registry key MFARequiredInCLIPRenew.
In the blog I mentioned, I shared a temporary fix that involved manually adding this MFARequriedInClipRenew registry key and the proper permissions.
This adjustment allowed the upgrade process to proceed smoothly. For a detailed explanation, refer to our previous blog post.
3. Microsoft’s Partial Solution
In response, Microsoft introduced the handle_access_denied feature in the June update (KB5039212)to address the MFA-required registry key errors. This handle_access_denied feature would handle the access denied error, in a graceful way, as explained in this blog on Patch My PC: KB5040442 | Windows Activation issues | Access Denied (patchmypc.com)
Before we continue on how this handle_access_denied task is doing its job, let me give you a small summary.
Function Workflow
- Feature Check: The function verifies if the handle_access_denied feature is enabled using __private_IsEnabled.
- Registry Key Attempts: It uses functions like CreateOrOpenKey and SetValue to handle the registry key.
- Bypassing Errors: The feature bypasses errors related to creating or accessing the registry key, ensuring the scheduled task proceeds.
- Scheduled Task: Ultimately, the task responsible for upgrading to Enterprise runs successfully, even if the MFA key isn’t created.
Unfortunately, this handle_access_denied cliprenew feature was initially disabled by default, which meant that users continued to experience the same upgrade issues despite the update.
As I mentioned in the Patch my PC blog, we could enable it using the Vivetool with some adjustments. Once the feature was enabled, Windows would uplift back to Enterprise.
4. The July KB5040527 Preview Update
The turning point came with the July KB5040527 preview update.
When we look closer at the improvements Microsoft added to the list in this article below, we will notice that the subscription issue is now resolved!
July 25, 2024—KB5040527 (OS Builds 22621.3958 and 22631.3958) Preview – Microsoft Support
It appears that in this preview update, Microsoft has enabled the handle_access_denied feature by default.
This change allowed the scheduled task responsible for the upgrade to run without hiccups, enabling devices to transition back to Enterprise as intended.
I guess it’s almost time to start celebrating! At least I did!
5. A Temporary Workaround?
However, this solution feels (in my humble opinion, but who am I?) like a temporary workaround. The underlying feature that required creating the MFA key is still present, but it’s now being bypassed with the Handle_access_denied feature within Cliprenew.exe.
Consequently, the MFA key is still not being created, even with the latest preview July update.
This indicates that while the immediate problem is mitigated, a more permanent solution is likely still in development. Microsoft added the mfarequiredfeature in the cliprenew executable for a reason not to bypass it later on.
I can only assume that we are going to spot the “real fix” to deal with the MFA-required registry permission issue in an upcoming Windows release! Hopefully, it will not give us the same issues it did when they first implemented this MFA requirement in the clip-renew function in April.
6. A Temporary Workaround indeed!
The July preview update contained a feature to handle the access denied error, but in my opinion, that wasn’t the real fix. I guess I was right!
Microsoft only implemented this fix for, uhhh, the July preview update? This is a bit weird; why go through all the hassle of creating this workaround only to ditch it the same week?
Luckily, Microsoft also added a new feature at the exact moment
Microsoft implemented the Changepathregistryformfafeature to the cliprenew.exe. This feature will move the required from the HKLM to the HKCU and by doing so fixing the access denied issue! Want to hear more about this fix? please read the additional blog:
Conclusion
Stay tuned for further updates as we monitor these developments and provide insights into the next steps for achieving a lasting resolution. We will keep you informed as Microsoft works towards a comprehensive fix for this persistent issue.
Anyone see the LicenseAquisition flipping the registry to 1 and still failing to move to Enterprise? I ran the script from the original blog here, it created, set, and permissioned the key okay. But then when the task runs it fails, and I go check the registry and the key is set to 1.
Are you using windows hello for business/mfa on the device itself? I assume this happens on your device when you are not a local admin and with the july preview update right?
We are using hello for business and correct, users are not local admins. Entra joined as well. Script to create the missing key was pushed out as system via proactive remediation. These devices are on normal/current channel updates, no previews in play. Strangely it’s about 20-25% of our devices doing this, where the other 75-80% are configured the exact same way.
I am seeing this on some random systems. One has Windows Hello enabled, one does not but the registry key is resetting to 1.
Is there anything that will address this?
Yes we see this or at least a similar issue. I have tested the new Update on a few devices. With the win11 Build 22631.2428 the upgrade to Enterprise works perfectly, as expected. Then with a Build after the Update that Broke the activation, the upgrade to enterprise does not work (also as expected). After the fix we see a new error in the task inside the task scheduler (0x800704ec). That only seems to happen on Devices that got Updated to the new build and had the activation issue. Devices that are freshly installed with the newest Updates can activate without a problem. The Intune configuration is exactly the same.
sounds like another issue seem to be happening as i cant seem to reproduce it
I have tested it by installing the device with an olde build, upgrading it to the may update… in which it got the issue and from there upgrading it to the august build
Thanks for the reply. Yeah it could very well be an issue with a GPO. At least that’s what I was able to find out. But it is still interesting that the same GPOs and Configs work on the old Versions and not on the August update. Well I will keep messing around with our Intune Config until I find the mistake.
I tried a fresh install using the Enterprise ISO from July 22, 2024, and the device completed Subscription Activation without any issues. How could this happen if KB5040527 is supposed to be the fix for it, or did Microsoft modify something in the ISO?
Forgot to mention, I got OS version 22631.3880 using the July 22, 2024, Enterprise ISO