Oct 25 2020 08:49 AM
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
Nov 27 2020 07:25 AM
@martingroen Did you ever get any help for this? I am having the exact same problem, thanks
Nov 27 2020 10:14 AM
@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
Nov 27 2020 07:21 PM
@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
Nov 28 2020 01:51 AM
@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?
Nov 28 2020 11:20 PM
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!
Nov 29 2020 07:09 AM
Nov 30 2020 08:40 AM
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.
Nov 30 2020 08:48 AM
@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
Nov 30 2020 09:22 AM
Dec 01 2020 02:05 AM
@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
Dec 11 2020 07:00 AM
@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.
Nov 18 2021 11:40 AM - edited Nov 18 2021 11:47 AM
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'
}
}
Feb 28 2023 01:23 AM - edited Feb 28 2023 01:23 AM
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 :)
Nov 28 2020 11:20 PM
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!