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!
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/set a 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 exists
if (-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 $acl
Write-Output "Added 'Interactive' group and SID ($sid) with read permissions (with inheritance) to the registry key."
#Start the scheduledtask
Get-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 build and 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/
11. Multiple Work or School Accounts Configured
In environments where users link multiple AAD accounts from different tenants to a device—often due to adding additional accounts to apps like Microsoft Teams—it can cause subscription activation problems. When devices have more than one work or school account, the LicenseAcquisition task fails to uplift the device back to Enterprise, leaving it stuck in Pro mode. This happens because the ClipRenew process, responsible for handling license activation, expects only one AAD tenant per device. With multiple tenants, the system throws a “SingleTenantIDExpectedforAadusers” error.
The solution? Disconnect any extra work or school accounts through Settings > Accounts > Work or School Accounts, ensuring only one account is linked. This allows the LicenseAcquisition task to be completed successfully and the device upgraded to Enterprise. Read the full blog below!
Subscription Activation Issue | Multiple linked AAD Accounts (call4cloud.nl)
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?
Rudy, very insightful as always! Many thanks for sharing!
Makes you wonder if they test this stuff.
I assume the devs tested it while they were being local admin 🙂 ?
Thank youRudy, we were banging our heads on this issue as well.
is there any official statement from MS? Can’t find anything
Hi… So far i have heard … not (yet?)
anyone find the link to Official statement?
this may help if needing to check machines remotely.
Get-WinEvent -FilterHashtable @{LogName=’Microsoft-Windows-TaskScheduler/Operational’} | Where-Object -Property Message -Match ‘ClipRenew.exe’ | FL
Good find, thanks for the detailed write up! Got caught with this one for an hour yesterday thinking it was a license assignment issue. I can confirm the registry permission change works. Although I would rather an official fix. Is there a ticket number or similar I can reference when raising this with Microsoft?
Hi.. Thanks :)… AN official fix would be very nice… but the last thing i heard about the fix was: NO eta… ..
You can nag about it on x and tagging the Windows Team.. as there isnt an ticket number or official case number for this
Here is one from us
2404240040010132
Well done thanks for help 🙂 We’ve had a call logged with Microsoft for over a week with no resolve
I have the first customer who has been told from Microsoft that it is known and should be fixed in a future update release.
Message Microsoft: – May 3, 2024: The Windows product team is fully aware of this issue. A fix already exists for the “access denied” that will be released as soon as possible. As of May 4, 2024, fix release date is unknown.
You are a lifesaver!
Any word if this is fixed in the May Cumulative update?
So far i know and heave heard… its not going to be in it
you nailed it 🙂
I’m not sure if its related, but I suspect it could be based on the timing. We’ve started seeing issues with using Fresh Start when testing Entra Joined Autopilot profiles that Windows detects some kind of hardware change and refused to activate Windows, much less upgrade to Enterprise. I found that using Wipe instead seems to fix it. Have you noticed this or hear it from other admins? I was hoping the Microsoft fix for subscription activation was going to be in the May update, but I didn’t see anything in the release notes.
Hi… mmm i didnt hear that one before.. let me test it to find out what happens.. and yeah .. its nog going to be in the may update 🙂
I’m seeing that issue as well
Is it possible that this is related to the changes to LSA that were released around the 20th or 21st of march?
I’ve been getting a lot of elevation errors, where all kinds of processes are being prevented to elevate their permissions and getting access denied on all kinds of registry settings.
Is there any reason not to uncomment the ClipRenew.exe line also for use during Autopilot?
i uncommented it :).. it could be executed without any issue
From Mexico, Hi Rudy
Thank you for the information, It´s Works in a non-Autopilot scenario, I had the problem with license activation Pro/Enterprise in some devices, I run the Powershell script Fix Option 1 and line in Powershell and works fine.
$(Get-WmiObject SoftwareLicensingService).OA3xOriginalProductKey | foreach{ if ( $null -ne $_ ) { Write-Host “Installing”$_;changepk.exe /Productkey $_ } else { Write-Host “No key present” } }
Hi.. Yep.. that a fix i was mentioning in the older blogs about subscription activation issues… but that wouldnt work with this latest kb installed unfortunately
Thanks so much for saving the day again! MS could not even tell me this with a critical ticket. Any idea when we can expect an official MS patch via Win Update?
Hi Rudy,
Great article – came across the issue yesterday so glad I have found this. Scripts works a treat.
Just a quick question if you have the answer – if a device is on a previous build (22631.2861 for example) and the April KB is installed – will the device be affected by this issue? Or since the relevant reg entry has already been created, will this be fine and keep the Enterprise status?
If the device already was uplifted to enterprise no worries 🙂 only if you reset that device and enroll it with the same windows build again
hi, is it possible to make a remediations script out of this? somehow combine it with this:
detection:
# Check Windows Activation Status
$activation = Get-CimInstance -ClassName SoftwareLicensingProduct | ? { $_.PartialProductKey -ne $null }
if ($activation.LicenseStatus -eq ‘1’) {
# Windows is activated, check PartialProductKey
if ($activation.PartialProductKey -like “3V66T”) {
Write-output “Subscription”
exit 0
}
else {
Write-output “KMS or other method”
exit 1
}
} else {
Write-output “Not activated.”
exit 0
}
remediation:
# Check Windows Activation Status
$activation = Get-CimInstance -ClassName SoftwareLicensingProduct | ? { $_.PartialProductKey -ne $null }
if ($activation.LicenseStatus -eq ‘1’) {
# Windows is activated, check PartialProductKey
if ($activation.PartialProductKey -like “3V66T”) {
Write-output “Subscription”
exit 0
}
else {
Write-output “KMS or other method”
# 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”)
# SID for the Everyone group
# or SID S-1-5-4 for the interactive group
# Check if the registry key already exists
if (-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.”
exit 0
}
# Add read permissions for SID (S-1-1-0, Everyone) 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 $acl
Write-Output “Added ‘Interactive’ group and SID ($sid) with read permissions (with inheritance) to the registry key.”
#Remove the # below to make sure it will kick off the scheduled task on already enrolled devices
Start-Process “$env:SystemRoot\system32\ClipRenew.exe”
exit 0
}
} else {
Write-output “Not activated.”
exit 0
}
Yes. Detection:
# https://call4cloud.nl/2024/05/kb5036980-breaks-upgrade-windows11-enterprise/
# Define the scheduled task path
$taskPath = “\Microsoft\Windows\Subscription\*”
$taskName = “LicenseAcquisition”
# Retrieve the last run result of the scheduled task
$lastRunResult = (Get-ScheduledTask -TaskPath $taskPath -TaskName $taskName | Get-ScheduledTaskInfo).LastTaskResult
# Check the last run result of the task
# 267011 – task never ran
if ($lastRunResult -eq 0) {
# Task ran successfully, exit with code 0
Write-Host “Task ran successfully, exit with code 0”
exit 0
} elseif($lastRunResult -eq 267011) {
# Task never ran, exit with code 0
Write-Host “Task never ran, exit with code 0”
exit 0
}
else {
# Report the error code
Write-Host “Error: Scheduled Task Last Run Result is $lastRunResult”
# Define the registry key path
$registryPath = “HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew”
# Check if the registry key exists
if (Test-Path -Path $registryPath) {
# If the key exists, return zero indicating compliance
exit 0
} else {
# If the key does not exist, return 1
exit 1
}
}
Remediation:
# Define the registry key path, value, and SID
# https://call4cloud.nl/2024/05/kb5036980-breaks-upgrade-windows11-enterprise/
$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-1-0”) # SID for the Everyone group
# Check if the registry key already exists
if (-not (Test-Path -Path $registryPath)) {
# Create the registry key if it doesn’t exist 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-1-0, Everyone) 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 $acl
Write-Output “Added ‘Everyone’ group and SID ($sid) with read permissions (with inheritance) to the registry key.”
I added Start-Process “$env:SystemRoot\system32\ClipRenew.exe” to the end of Remediation, but it wont activate before i run it manually after. can it be included somehow?
Well.. the cliprenew must be executed in user context… and the script itself to change the permissions on that key etc, must be run in system context..
So there are 2 scripts to be deployed :
1.The script itself in system context. and
2. A separate script for just the cliprenew in user context.
Am I correct here? Please clarify as we have truckloads of affected devices and I tried it on few test laptops but its not working. So Im little confused.
Does anyone know when exactly the downgrade will take place? I’m using a Remediation Script to check which ones have already been downgraded, and also checking the last return code of the Scheduled Task. Almost all computers running Windows Enterprise have 0x80070005 (not 0x80004005) as the last return code. I am now wondering if and when they will be downgraded.
$LastTaskResult = (Get-ScheduledTaskInfo -TaskName “\Microsoft\Windows\Subscription\LicenseAcquisition” -verbose | select -exp CimInstanceProperties) | Where {$_.Name -eq “LastTaskResult”}
$LastTaskResult = $LastTaskResult.Value.ToString(‘X’)
Rudy,
Thank you so much. I am able to successfully run the script manually from an Administrative Powershell prompt. I have been unable to deploy the script successfully as a Win32 app via Intune. The install behavior is set to System. Install command: powershell.exe -noprofile -executionpolicy bypass -file RudyFix.ps1. The script does not appear to run at all. I have been unable to isolate the issue. Admittedly my basic powershell knowledge does not help.
Thank you
Hi, after applying the powershell script fix, I then see the following error message for the scheduled task:
“CLiP license device ID does not match the device ID in the bound device license. (0xC0EA000A).:
I then run this from your other post:
net stop clipsvc
rundll32 clipc.dll,ClipCleanUpState
net start clipsvc
And I now see the following error:
CLiP device license not found. (0xC0EA0003)
What could I be dealing with here?
I got the same one on one of my devices, another device works fine. And it’s not a PowerShell script, I believe, it could be the new May path. Interestingly, I don’t see this issue on other devices, only on one. Same AAD account.
I’m seeing the same. LicenseAcquisition keeps failing with 0xC0EA0003 as if there was some hardware change with the device. I’m seeing this on multiple devices. I can confirm from AAD sign-in logs that Store authentication is successful and MFA key is created. I have escalated to Microsoft, but not getting concrete updates from them yet.
Same here, CLiP License device ID does not match…
Hi Rudy, very detailed and helpful. Thank you for creating and sharing this.
However, this command: Start-Process “$env:SystemRoot\system32\ClipRenew.exe”
doesn’t seem to be running the License Acquisition task and I even tried running in user context. But no luck.
So after adding the registry, once the device is getting rebooted, the License Acquisition task scheduler runs and activates the device to Windows 11 Enterprise.
Any idea how we can make this work , that will eliminate the need for reboot.
Start-Process “$env:SystemRoot\system32\ClipRenew.exe”
Hi Rudy,
Is there any news from MS for a proper fix for this. Just installed June updates and that has not resolved 🙁
Was hoping not to have to run this script on all devices, but now they are starting switching back to Windows Pro.
Thanks,
Alex
It should be getting fixed in the june oob update (and the end of june) otherwise its going to be in the july update
Is the fix in the june CU or are we stuck waiting another month?
hopefully at the end of the month and the oob update 🙂
I think it is important to also point out, that this issue is the same for “Microsoft 365 E3” that is also upgrading to Enterprise in the article.
Thanks.
2024.06 (KB5039212) still have the problem, no stepup and Access denied error (DAMN)
I ran the powershell script and I keep getting the error code (0xC03F6504) and the ClipSVC keeps stopping on its own after the license Acquisition is run. Idk if im doing something wrong or if theres something stupid in my GPO from the previous dude that is causing this.
Does KB5039302 fix?
so far i have hear no….
I have followed these instructions and have changed the permissions on the registry key but i am having a failure of the license acquisition scheduled task with error 0x800704EC
We’re already having problems (silently) activating the Pro license in the BIOS (OEM) with current 23H2 ISO downloads.
Starting to see Enterprise licenses come back to life across the company. What a few weeks this has been.
Without having to implement a fix manually?
WI803540, Windows 11, version 23H2
Last updated: Jun 20, 2024, 10:04 PM GMT+2
Originating time: Apr 9, 2024, 7:00 PM GMT+2
Status
Confirmed
User impact
You might face issues while upgrading from Windows Pro to Windows Enterprise with April security update.
After installing Windows updates released on or after April 9, 2024 (KB5036893), you might face issues while upgrading from Windows Pro to a valid Windows Enterprise subscription.
Resulting from this operation, you might observe the following symptoms:
– OS upgrade operations may fail, and this might be shown in the LicenseAcquisition scheduled task in Task Scheduler -> Task Scheduler Library -> Microsoft -> Windows -> Subscription as ‘Access denied error (error code 0x80070005)’ under ‘Last Run Result’.
Home users of Windows are unlikely to experience this issue as this upgrade is more commonly done in Enterprise environments.
Next steps: We are working on a resolution that will be released on a Windows update in the coming weeks.
Affected platforms:
– Client: Windows 11, version 23H2, Windows 11, version 22H2
– Server: None
Ahh finally a nice ” incident” /ticket about it :).. thanks for mentioning it
Has there been any news on if this is going to be fixed with this months patches?
Nope… 🙂
One of my teammates put in a ticket with Microsoft for this, and they gave us a workaround until the patch is released. The workaround was the script in this blog, verbatim. No changes at all.
Does anyone know if this issue has been fixed? It seems there is no update yet.
I updated the blog and also put a redirect to my additional blog about this issue
HI there
i just have a question about this line
If you want to fix this on existing devices that already went through Autopilot, you also need to trigger that scheduled task to acquire the proper license for the device. You can do so by adding this command to the script above!
What is the command that you need to add to the script to run it after autopilot?
Anotehr question
how do you run a script during autopilot?
Apparently the PS is not creating the registry key in our environment. Intune is reporting 100% success with the deployment…
Are you 100% sure yyou deployed it in 64 bits context?
I’ve used the remediation script in 64 bits, but after 10 days, only 40 out of 120 devices moved to Ent.
Anyway, MS is saying that this KB from 25 July sorts the issue. Currently rolling out and can’t confirm yet.
https://support.microsoft.com/en-gb/topic/july-25-2024-kb5040527-os-builds-22621-3958-and-22631-3958-preview-de3e1e24-0c07-4210-9777-8e03a1446bae
To let you know there is a known issue with KB5040527.
After installing the July 9, 2024, Windows security update, you might see a BitLocker recovery screen upon starting up your device. This screen does not commonly appear after a Windows update. You are more likely to face this issue if you have the Device Encryption option enabled in Settings under Privacy & Security > Device encryption. Because of this issue, you might be prompted to enter the recovery key from your Microsoft account to unlock your drive.
We have some devices where the scripts creates and sets the key correctly, but after LicenseAcquisition task runs, I go back and look at the registry and the value is set to 1 instead of 0. This has happened on about 25% of devices and results in them staying on Pro and not moving to Enterprise. Anyone see this?
Yes, we’re seeing the same thing on a small number of devices.
If you are a big business then you just need to download Microsoft Toolkit and activate your Windows. It can be downloaded at https://mstoolkit.co/
Thanks so much for this. We used this to get our devices activated on Enterprise again.
Microsoft told us this would be resolved completely with the August updates.
Unfortunately, it looks like our devices that previously had this remediation (we are not running it anymore), are now falling back to Pro after receiving the the August update.
I have since run another remediation script which deletes the registry key we previously created as per your article, but this has not helped either.
I’m very interested to hear your experience with this after applying the August updates and have you seen anything similar?
Is that hklm settings still on the device that requiresfa?
We are proactively deleting the HKLM key now that it seemingly not required after the August update.:
“HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew”
Other devices that never got the first remediation, and have the August update and work fine, do not have this key anymore so it seems it is no longer required.
So far this has not made a difference though.
WIth the august updarte msft implemented the handleaccessdenied feature as i mentioned here: https://call4cloud.nl/2024/07/kb5040527-fixes-subscription-activation/ (not the real fix though)
but with it, it ignores the output of that mfarequired key.. BUTTTT it is still necessary to create that key 🙂 as msft their official working fix would create that mfa key in the hkcu and no longer in the hklm
So, are we saying that after the August update, we should change that remediation to instead create the same registry key & property in HKCU instead of HKLM?
One thing we noticed was any device that has been wiped and re-imaged after august updates, does not have the activation issue anymore, and also has neither of those registry keys present in either HKLM nor HKCU.
The licence acquisition task.. what error does it give you?
No the HKLM settings are gone. We have reversed the remediation that was done previously.
We’re now seeing devices with the error 0xD0000272 on the LicenseAcquisition Scheduled Task.
After deploying Conditional Access Exclusion and prorem the upgrades we’re going smoothly now all of a sudden a lot of devices are downgrading again to a Pro version..
Any ideas?
The error you got normally refers to having issues reaching the subscription activation service.. No errors in the conditional access/sign in log?
Did you manage to fix this at all? Im getting this exact error across our fleet of laptops now and I have deployed the reg key as stated above and have added the CA exemption for the business store that handles the upgrade.
Did you also read the latestblogs about this topic on my website? Also did the scheduled task got a new status/erorcode?
Hey, Yes i have read it and maybe Im a little confused.
The LicenseAcquisition Scheduled Task last run result is 0xD0000272 and the MFA reg key is deployed correctly.
I think my confusion is coming from the KB5040527 update, is this update widely available yet or is it being released next tuesday? 🙂
Thanks!!!!
yeah somehow that weird status error is shown now… i am trying to pinpoint what is causing it.. do you happen to have multiple work/school aaccount configured?
Just wondering… (or not) could you take a look / retry the task) to see what it does now?
Just wondering… (or not) could you take a look / retry the task) to see what it does now?
Seems to come through now! Numbers also generally dropping significantly.
Its working now, and I’m seeing the (0x0) status code for the scheduled task!
Just a successful sign-in towards ‘Universal Store Native Client’ with no CA policies applied.
We have always license with a local KMS server in our AD. Workstations are hybrid AD joined. We’re seeing the downgrade from Ent to Pro. If we run your script, it fixes it ONE time until we reboot. Upon reboot, it reverts to pro.
The activation scheduled task that was failing also fails on reboot the first time, but succeeds on subsequent runs. The only way I can get back to Ent again after this is run the manual KMS commands. Then it reverts on reboot.
Anyone seeing this broken again? My device inventory was nearly all enterprise after the August patch, but now this week I have over a hundred that are Pro again. Need to get with a user to do some digging, but it aligns with September Windows Updates….
Have there been any developments on the subject? The powershell patch requires users to perform MFA authentication, but this is very restrictive and involves trusting users to perform this task…
In the blog i am mentioning that the july fix implements the handle access denied feature. the main issue is that the reg key is still created in the hkklm (need permissions to change it) What happens when just deleting that reg key which was created in the script and rely on the handle access denied feature that was introducte din the july build
Are there any news on this issue?
What would you like to know? or are you experiencing different behavior/a different issue that is corrolated to this one?