[German]A quick note for administrators who manage Windows 11 clients in corporate environments. With the April 2024 preview update KB5036980, Microsoft caused a problem for administrators who wanted to switch from Windows 11 Pro to Windows 11 Enterprise using AutoPilot. Rudy Ooms has analyzed the issue and developed a fix. Microsoft is aware of the problem and wants to release a fix – at the moment it is unclear to me whether this has already happened with the May 2024 update.
Advertising
Windows 11 23H2/22H2: Preview Update KB5036980
Microsoft has released the preview update KB5036980 for the current Windows 11 version 22H2 – 23H2 on April 23, 2024 (see Windows 11 23H2/22H2: Preview Update KB5036980 (April 23, 2024)). The support article for update KB5036980 lists a number of quality improvements and fixes.
Enterprise upgrade broken
Administrators in corporate environments will upgrade Windows 11 Pro to Windows 11 Enterprise. This can be done using AutoPilot, provided the relevant Enterprise subscriptions are available. Anyone with a Microsoft 365 E5 license is entitled to upgrade to Windows 11 Enterprise. This subscription upgrade should happen automatically when the user logs on to the device – provided the subscription activation works.
However, I already came across tweets from MVP Rudy Ooms a few weeks ago, around May 2024, who reported that this is exactly what does not work and that there are problems with activating the Enterprise subscription during the update from Windows Pro to Enterprise when this happens via AutoPilot.
Rudy Ooms had already published the blog post The KB5036980 breaks the Windows 11 Enterprise Subscription Activation zon May 3, 2024. A bug has crept in with the mentioned preview update KB5036980 for the current Windows 11 version 22H2 – 23H2. The activation of upgrades to Windows 11 Enterprise licenses for Windows 11 Pro machines only works if the account used is a member of the local administrator group. If a standard user logs on, an automatically executed LicenseAcquisition task throws the error 0x80004005 (Access is denied).
Ooms has analyzed it in more detail and documented it in the blog post linked above: The problem is that a standard user lacks permission to create keys in the registry, but these are needed to upgrade. Therefore, Ooms has developed some workarounds that set the permissions to access the required keys to "Everyone". This is possible with a PowerShell script, for example.
Advertising
In an addendum dated May 22, 2024, Ooms now mentions that Microsoft's product team wrote in a post on May 3 that they were aware of the problem. There is probably already a fix, but at the beginning of May 2024 it was unclear when it would be rolled out with an update. This does not seem to have been the case for the May 2024 patch day on May 14 – or has the problem been fixed?
Advertising
Hello,
You can add the following script to Intune: https://intune.microsoft.com/?ref=AdminCenter#view/Microsoft_Intune_DeviceSettings/DevicesMenu/~/scripts
Platform scripts tab, then Add Windows 10 and Later
Name
Autopilot to ensure Windows 11 Enterprise license acquisition
Application description
Autopilot to ensure Windows 11 Enterprise license acquisition
PowerShell script
Windows11Enterprise_Activation.ps1
Execute this script using login credentials.
Yes
Check script signature
Yes
Run script on 64-bit PowerShell host
No
Groups included
Your Win11 devices
—-
Script Powerschell :
# 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
#Start-Process "$env:SystemRoot\system32\ClipRenew.exe"
—
Result : https://i.ibb.co/PCN6wsS/2024-07-05-23-52-25-Clipboard.png
Correction on the values of the strategy to be implemented :
Execute this script using login credentials.
No
Check script signature
No
Run script on 64-bit PowerShell host
No
See my article: https://www.linkedin.com/pulse/windows-11-update-kb5036980-blocks-activation-guillaume-devaud-n7wce/?trackingId=mgm%2FxoGBSRykfAt7I%2FDY6A%3D%3D