Forum Discussion
MDM Session: OMA-DM session ended with status: (Unknown Win32 Error code: 0x80072f0c)
martingroenHey, I worked on this today and was able to resolve it on several computers without resorting to reinstalling Windows, if you are interested. First, I removed the computers from the AAD Connect sync and GPO scope and completely purged them from Intune and AAD. I then ran dsregcmd /leave from an elevated command prompt on each workstation console. Next, navigate to the following registry hive on each impacted workstation: HKLM\SOFTWARE\Microsoft\Enrollments. Delete as many GUID-named keys as possible from this directory (example attached). Ignore any keys that cannot be deleted. Now restart the workstation and add it back to the AAD Connect sync and GPO containers/groups. Once I logged back in with a MEM-licensed AAD user (user auto enrollment), my devices were once again managed by Intune within the next ~15 minutes. Good luck and thanks for your collaboration on this!
NFederico Annoying isn't it. Seems to be some bug that MS have forgotten to address. 😉
Anyway, I didn't downgrade, I just downloaded a fresh install from the cloud. This is a new option in Win10 2004 that is extremely useful. I followed these steps
Optimize Windows 10 PC reset using the cloud
, making sure I clicked on the 'Keep my files' option. Unfortunately, I had to repeat this procedure with every laptop; it's very time consuming. But the colleagues get to keep their files and Intune syncing resumed so I could enforce my policies again and indeed enforce Advanced Threat Protection again and firewall policies. @microsoftsupport could you correct this before you release version 2101?
martingroenHey, I worked on this today and was able to resolve it on several computers without resorting to reinstalling Windows, if you are interested. First, I removed the computers from the AAD Connect sync and GPO scope and completely purged them from Intune and AAD. I then ran dsregcmd /leave from an elevated command prompt on each workstation console. Next, navigate to the following registry hive on each impacted workstation: HKLM\SOFTWARE\Microsoft\Enrollments. Delete as many GUID-named keys as possible from this directory (example attached). Ignore any keys that cannot be deleted. Now restart the workstation and add it back to the AAD Connect sync and GPO containers/groups. Once I logged back in with a MEM-licensed AAD user (user auto enrollment), my devices were once again managed by Intune within the next ~15 minutes. Good luck and thanks for your collaboration on this!
We had the same problem and I tried just deleting the GUID in Enrollements et after un reboot, the device enroll by it self in InTune after roughly 15min. I even create a powershell script do to the cleanup of the registry using SCCM to target those with the problem and it work. Thank you NFederico for this.
This is the script I did. No guaranty it doesn't cause any other problems, but so far so good for us.
$Rpath = "HKLM:\SOFTWARE\Microsoft\Enrollments"
Set-Location $Rpath
$subRKey = Get-ChildItem $Rpath | select Name | Where-Object Name -Like '*-*'
foreach($RKEY in $subRKey)
{
try
{
$ToDel = $RKEY.Name.split('\')[4]
Remove-Item $ToDel -Recurse
}catch
{
'Error'
}
}We are seeing this on our intune devices - brand new out of the box from the Department of Education. Autopilot configured. I've done a reset windows autopilot and still have this issue.
Do I need to log it with MS Support?
I came across it because I was hunting to find out why my devices weren't compliant and Chrome ADMX ingest wasn't working.
John Dooley IT Yes, I am afraid so. This is an error that has not been addressed by MS Support yet, as far as I am aware.
My solution to reinstall windows 10 20H2 from the cloud was rather crude and Federico's solution was more elegant.But this should not occur in the first place, of course.
Good luck!
Martin
