SOLVED

MDM Session: OMA-DM session ended with status: (Unknown Win32 Error code: 0x80072f0c)

Copper Contributor

Hi,

 

An increasing number of devices are getting a non compatible status. Is active is non-compatible. When inspecting the event logs with event viewer I see the following error message. 

 

MDM Session: OMA-DM session ended with status: (Unknown Win32 Error code: 0x80072f0c)

 

This error code did not lead to any results after a search on the internet, so I thought let's try it here. Does anybody have any ideas how I can resolve this?

 

Thanks a lot

 

Best wishes

Martin

 

13 Replies

@martingroen Did you ever get any help for this? I am having the exact same problem, thanks

@NFederico No one offered any help. It is a weird error message. I couldnt find any mention of it on the internet.

What version of Windows 10 are you on? This happened with a couple of laptops that had upgraded themselves to Windows 10 20H2. I resolved the matter by resetting the Windows installation from the cloud. Now they are happily syncing again with Intune.

 

Best wishes

Martin

@martingroen Yes! That is exactly what happened with ours as well! We upgraded to edition 19041 (2004) and these workstations immediately stopped checking in to Intune and now we cannot re-enroll them. What do you mean by "resetting the Windows installation"? Do you mean you rolled back the upgrade? Unfortunately I am not in the position to do that because we require 2004 for full Windows Defender Application Control functionality with custom OMA-URIs

@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? 

best response confirmed by martingroen (Copper Contributor)
Solution

@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 Thanks! Very interested. A much more elegant solution than mine :)

 

Cheers, Martin

@martingroen 

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

Thanks - when you say reinstall from cloud, are you referring to the new feature in 20H2? I’ve not used this feature yet but I believe it was go live for this feature release?

Autopilot reset therefore won’t fix this issue?

Thanks
John

@John Dooley IT Hi John, I am indeed referring to the new 20H2 feature. This works perfectly, with a good internet connection. 

 

The problem I had was that MDM sync wasn't happening. Everything worked fine on the laptop itself, only the MDM sync didn't work with that mysterious error code as a result. I did a extensive search on the internet for more info on this error but to no avail. So, I decided to try this new cloud reinstall feature. And that helped. Apparently, during the previous update to 20H2 something went wrong which was corrected this time around. 

 

I'm not using autopilot yet, but am planning to start using it. Hopefully that will make it easier to locate the source of these issues?

 

Thanks

Martin

@NFederico Great work. We had the same issue on a company device and we could fix it with these steps. Hopefully Microsoft will fix this in a future update soon, because this problem is blocking our deployment of 20H2.

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'
}
}

I had a similar issue that lead me to this page, My error code was a little different but the same steps worked to resolve the issue.

 

So thanks for this information, was banging my head against the wall for a few days trying to figure this out :)

1 best response

Accepted Solutions
best response confirmed by martingroen (Copper Contributor)
Solution

@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! 

View solution in original post