MDM Session: OMA-DM message failed to be sent. Result: (Unknown Win32 Error code: 0x80072efe).

Copper Contributor

I'm having an issue with some devices in our environment enrolling successfully into Intune. 


Here is the lay of the land. 


1. Devices are hybrid joined.

2. Using GPO to enforce auto-enrollment. 

3. PCs that are not successful in joining to Intune are getting the following error: 


4. Certificates are valid.

5. Scheduled tasks are present. 

6. Sync in accounts shows same error:


7. In Azure devices the device shows up as enabled, with an owner, MDM as Microsoft Intune, and Compliance as No.



I've searched all over for the exact same error of 0x80072efe and nothing that helps me.


There is no smoking gun that is similar among these PCs. No firewall issues. Some PCs on the same VLAN will register just fine while others continue to get this error. 


Total PC count: 1400

PCs having issue: 600


Any help is appreciated!

7 Replies
Sounds like a fun issue! :) ... looking at the error it just tells you WININET_E_CONNECTION_ABORTED

If you could share logs, I could take a look at it...
Thanks for the reply!

Any specific logs you are wanting?
depends.... :)
Try to sync the device and run this command (will fetch all logs... ms also uses it :) )

wget -outfile IntuneODCStandAlone.ps1
powerShell -ExecutionPolicy Bypass -File .\IntuneODCStandAlone.ps1

@Rudy_Ooms_MVP I'm working on getting the logs unfortunately people are actively using the computers so I will get it asap. 


I do fine this interesting that they show up in Azure as a device with a MDM status:



But in Intune it doesn't even show up as a device:


You will have to trust me a little that the names are both correct. 


I find this odd too. We get random usernames with Windows and the date show up in Intune but it doesn't seem to correct itself and associate with the windows device. 




best response confirmed by imyouradmin (Copper Contributor)

We believe we figured this out. We are still monitoring it but we believe that SSL decryption was the cause of this. Even though the Microsoft articles say to not do it to we tried that with no success we had to exclude all Microsoft traffic from being decrypted on our firewall via a Dynamic List. Hope this helps someone out!

Article in reference was that mentioned just that one URL.


We also prevented our PCs from being Azure AD Registered as Hybrid was our preferred method and we set the following registry key.


HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin "BlockAADWorkplaceJoin"=dword:00000001