Do you have devices that are missing the Intune Device Certificate or have sync issues? This blog will show you a possible root cause and how to solve it! Nothing is worse than having sync issues on your devices. But it’s way worse when your devices are dropping out of Intune because of some missing Intune Certificates.
1. Introduction
I guess you may be wondering why I am writing this blog. Over the last couple of months, I have noticed a lot of questions asking why devices stopped syncing with Intune.
When trying to answer some of those questions, I also got asked if there could be an explanation for why the MDM Intune certificate is missing in action! Here are some examples..
Computers dropping out of Intune : Intune (reddit.com)
Devices Disappear in Intune but still in Azure (18 Months?) : Intune (reddit.com)
MDM Certificate missing on some devices : Intune (reddit.com)
didn’t find cert in both store – in IntuneManagementExtension – Microsoft Tech Community
Of course, I did write a blog about the Intune Certificate in the past and how to deal with the expired Intune MDM certificate
Sync issues 0x80190190 and the Intune MDM device Certificate (call4cloud.nl)
Okay Okay… that blog is indeed only about expired certificates, not about the missing certificate! For your information, I also wrote an additional troubleshooting blog which is explaining how to deal with duplicate Intune Certificates or when the Intune certificate is missing its private key
Troubleshooting the Intune Device Sync error 0x80072f99 (call4cloud.nl)
But still, that doesn’t solve the issue in which the Intune Device Certificate is gone and seems to be missing. So I had the feeling I needed to write an additional blog to show you what happened with those devices that are missing the Intune MDM device certificate…. NO! for everyone blaming the Device Cleanup Rules, you are wrong!
2. The Issue
So no expired certificates, no duplicate certificates, and no certificate with its private key missing… What else do we have left? Nothing… and I mean nothing.
Let us take a look at the “nothing”
As shown above, the problem device is missing its Microsoft Intune MDM Device CA certificate! When you have enrolled your device with Autopilot, the Ms-Organization-Access certificate and the Intune certificate are both delivered to the “Local Computer Personal Store”
I am explaining that flow in this blog below
TenantID and the Azure Device and Intune MDM Certificate (call4cloud.nl)
If you have read the blog, you could have stumbled upon this picture, describing the ms-organization-access-flow.
Please note: If you have read the above blog, we will also know how the device knows to which tenant it belongs by looking at the Certificate Properties
I guess we all know how important that Intune Device cert is right? Without it, there should be absolutely no communication possible with Intune. Even the Intune Management Extension log is telling us it didn’t find any certificates. That can’t be good right?
Shall we go further and take a look at how this started happening?
3. How did they enroll the device?
After asking around a bit, I noticed that those problem devices were manually enrolled to Intune AFTER being Azure Ad Joined in the first place.
Microsoft’s official supported method would be to wipe the device and let it enroll with Autopilot to make sure the device becomes Azure Ad Joined and Intune Enrolled.
But I get it. Sometimes, wiping all the already Azure-ad joined devices to let them enroll into Intune isn’t fun.
The last time I needed to do this was two years ago, and I did so using my own blog.
Enroll existing Azure Ad joined Devices into MDM | Intune (call4cloud.nl)
It worked perfectly, and I didn’t receive any notification that their devices stopped syncing, so it was pretty much a flawless victory.
But I was still wondering how my fellow it persons enrolled their devices into Intune
4. MDM Enrollment Options
Before I am going to show you some other options, we need to check what Microsoft has to tell us about the options we got.
MDM enrollment of Windows 10-based devices – Windows Client Management | Microsoft Docs
In the above MS-Doc, Microsoft is telling us: “ALL Windows 10-based devices can be connected to MDM. You can connect to an MDM through the Settings app.”
We can do so by pressing the “Enroll only in device management” button in the Access work or school settings on an already AzureAdJoined device.
Of course, we could also use the company portal to enroll the device into MDM. The only thing we need to do is, press the “This device hasn’t been set up for corporate use yet. Select this message to begin setup” button
After asking for your credentials the device becomes MDM enrolled
5. Something not working with MDM-only?
So we have three options: 2 Microsoft-supported options and one non-Microsoft-supported solution. That sounds quite fun, right?
I decided to take a deep dive into all of the options. When taking a closer look at the supported Microsoft options and implementing them I noticed that all of my PowerShell scripts weren’t applying.
When thinking about it, that’s odd, right? Because when you have an AADR device that got enrolled into Intune, the PowerShell scripts do work!
Azure Ad joined vs Azure Ad Registered | AADR vs AADJ | PRT (call4cloud.nl)
But let me get back to the story, I will show you how I noticed it. Some time ago I wrote down my “bonkers” idea to make sure the device was compliant at first login
Device Health Attestation Flow | DHA | TPM | PCR | AIK (call4cloud.nl)
In that specific blog, I was deploying Bitlocker to my device with a scheduled task and an attached PowerShell script/command.
So I was expecting that when the AADJ device was being enrolled into MDM, that scheduled task would kick in but it wasn’t deployed and my hard drive wasn’t encrypted with Bitlocker! Luckily something in the IME log was showing me that the Scheduler failed to get the device id, which will affect script status…
Another error that I spotted was: Failed to get device id, abort PowerShell check-in
Okay… that doesn’t sound good. When taking a look at the agentexecutor.log (which should mention the PowerShell scripts I deployed) it is ONLY mentioning this couple of lines and nothing more
WinHttpGetProxyForUrl call failed because of error 12180]LOG]…. Which corresponds with (ERROR_WINHTTP_AUTODETECTION_FAILED) AKA Proxy Auto-Configuration File was not discovered
As shown above, it’s missing stuff like my PowerShell script and other important PowerShell scripts!
That’s odd, right? PowerShell is not working, and we are also still missing our important Device cert, which I also showed you in the second part of this blog!
6. Troubleshooting part 1
So our existing AADJ device becomes Azure Ad Joined but PowerShell scripts aren’t working and the Intune device certificate doesn’t show up in the local machine store.
As mentioned in almost all of my Intune device cert blogs, without that certificate your device can’t sync! So why not test it?
As shown above, the device could sync, and the sync was also successful. Okay, that’s something I wasn’t expecting: the ability to sync your device without having the MDM certificate in the local machine store.
If you have read my troubleshooting blogs, you would know that the Certificate that Intune/MDM is using is listed in the software\microsoft\enrollments\guidoftheenrollment section in the registry.
As shown above, we got ourselves the Intune Certificate Thumbprint (DPMCertThumbPrint). So I decided to do 2 things.
- Performing A sync to determine where it looks
- Performing a new enrollment and watching Procmon and the event logs
7. Performing a sync
So, I made sure I ran Procmon with system privileges and watched the omadmclient.exe process while performing a sync with Intune
As shown above, while syncing the device I noticed that omadmclient.exe was querying the SOFTWARE\Microsoft\Provisioning\OMADM\Accounts\guid folder. It does sound like it’s trying to find the right EnrollmentCertStore doesn’t it? Ow wait, yes it does! The getenrollmentcertstore shows the same behavior
When looking at the key it tries to find, we notice it is looking specifically at the SslClientCertReference key
Did you spot the MY;User part in that key? Not Machine but User! After fetching that key, it starts looking for the profile path of the S-1-5-18 user. Guess what that SID stands for
As shown above, it found the “profilepath” of the System User and after a couple of nanoseconds it performed a file query on the c:\windows\system32\config\systemprofile\appdata\roaming\microsoft\systemcertificates\my\certificates folder
As shown above, the query was a success! Guess again who that folder belongs to!
To find out if that was really the case, I opened Psexec to elevate myself to SYSTEM and opened the local cert store of the system account. You may take one wild guess about what we will find in this store
As shown above, it shows us the “missing” Intune MDM device certificate!
8. Performing an MDM-Only Enrollment
Let’s track down what will happen when performing a new Intune enrollment on an already AADJ device! I made sure I again had Procmon open, and while watching Procmon run, I also opened the Crypto-Ncrypt event log
As shown above, I noticed that Event 9 mentioned a key written with the name ConfigMgrEnrollment0. Sounds like a certificate being deployed to me. Just before closing that screen, I scrolled down to notice the Userid:
Sounds familiar right, the UserId: S-1-5-18. I closed the event logs and switched to Procmon.
As shown above, it is almost the same behavior as we noticed when we started a “sync” but the only difference is that it creates files instead of querying them. Of course, it will also set the “SslclientCertReference” key instead of opening it
When watching Fiddler when the device is being enrolled we will also stumble upon some information
The device will request enrollment and will get back an encoded response. When decoding this response, we will notice that it contains the Intune MDM certificate and some additional information.
As shown below, the response also holds the information to which Certificate Store the Intune device certificate belongs!
To zoom in a little bit closer after doing some proper formatting, we will notice SSLCLIENTCERTSEACRHCRITERIA is being mentioned with the My;User Store
If you are interested in how I noticed this information, please read this blog below. This blog is version 2 of the Willy White glove blog!
Autopilot Pre-Provisioning | Technical Flow V2 | Intune (call4cloud.nl)
9. Performing an MDM enrollment with PowerShell
Of course, I was curious about what would happen when choosing the unsupported GPO enrollment option.
Enroll existing Azure Ad joined Devices into MDM | Intune (call4cloud.nl)
While writing this blog, I also updated the above blog to make sure the AADJ device will enroll into Intune within seconds. I changed a couple of lines so go check it out first!
After putting down those PowerShell commands in a PowerShell session in the System context I noticed that it was also setting the SslClientCertReference key but this time not with MY;User but with the MY;System settings
Guess where I could find that Intune cert? Yeah again, you guessed it! In the Local Machine Cert Store. Also good to know is that the PowerShell scripts that weren’t working with the first 2 options, were kicked off immediately.
10. Comparing the Enrollments with Enrollments
But I am not done yet, as something else caught my eye. When looking at the enrollments registry key I mentioned earlier. I noticed some differences.
As shown above, the left picture is showing us the settings with an MDM-only enrollment (Company Portal and Settings) and the right one is showing us the settings when you performed the Intune enrollment with the PowerShell script.
Both devices are AADJ and Intune Enrolled, but the MDM-only device shows “EnrollmentType = 0” while the PowerShell script Intune enrolled device shows “EnrollmentType = 6.” Sounds like a different kind of enrollment, right?
When taking a look at what MS Graph has to tell us, we will notice the same difference. The first screenshot is from an AADJ MDM-only enrolled device
The second one is an AADJ enrolled device but this time I enrolled it with the PowerShell/GPO option
So I simply guess that 0, means “UserEnrollment” based and 6, means “AzureDomainJoined”? I am not sure, but it looks pretty much like it.
When doing the same on an Azure Ad Registered device that’s enrolled in Intune, we will notice that the enrollment type is “AutoEnrollment”. And this value corresponds to Enrollmentype = 13.
11. What about AADR and the Certificate?
As mentioned in the previous part of this blog, I also decided to take a look at what would happen with an AADR device. So I enrolled a new device but this time I did not perform an Azure Ad Join but made sure the device would only be Azure Ad Registered AND Intune Enrolled.
I was curious about the location of the Intune MDM device CA certificate! As shown below, the Intune Device CA certificate is also in the System Personal Certificate Store. So no differences here right?
Guess again… while waiting and waiting some more, something caught my attention on the Azure Ad Registered Device! I did not notice this behavior on an Azure Ad Joined device that I enrolled into Intune with the MDM-Only option.
As shown above, the IME log on the AADR and Intune enrolled device is mentioning that it will add the MdmDeviceCertificate (with the matching thumbprint) into WebRequest. Okay, it also is mentioning the same error we noticed on the Azure Ad Joined device: Find 0 MDM certificate but it also shows us some more information.
When looking at the total flow from above, it looks way better! Let me show you why.
- First sets the MdmDeviceCertificate
- Then it tries to find the Mdm Certificate in the Local Machine store
- It will fallback to the user store and will check if it exists in that one
- It finds the right one and will add it to the WebRequest
So I guess that’s why stuff does work on an AADR device and NOT on an AADJ device that is enrolled into Intune with the MDM-Only option!
12. Fixing the Missing Certificate
If you have a previously AADJ device and enrolled it to Intune with the supported MDM-only options, you are up for a challenge… Luckily it’s very easy to fix the missing certificate and the not working PowerShell scripts. When you have system permissions, you can do almost everything you want even exporting the Microsoft Intune MDM device CA with its private key!!
Isn’t that just beautiful? Just right-click on the certificate and select export.
After pressing export, you have the option to export the needed private key.
After the export with a nice password attached, you can import it back again… but this time in the Local Machine instead of the System User Certificate Store
When you want to automate it, you could use this PowerShell script (Of course you need SYSTEM privileges to access the System Personal certificate store)
$certificate = Get-ChildItem -Path Cert:\Currentuser\My\
$password= "secret" | ConvertTo-SecureString -AsPlainText -Force
Export-PfxCertificate -Cert $certificate -FilePath c:\intune.pfx -Password $password
Import-PfxCertificate -Exportable -Password $password -CertStoreLocation Cert:\LocalMachine\My -FilePath c:\intune.pfx
net stop IntuneManagementExtension
Net start IntuneManagementExtension
As shown below, it will export the key to a pfx and will import it back again!
After restarting the IME, within a few seconds, your PowerShell scripts will start to appear on your device and the IME log will mention it found 1 MDM certificate!
For the people with some “funny” ideas… NO, you can’t export the MS-Organization-Access certificate with the private key attached when you have a TPM!
13. Certificate Location Overview
I will finish this blog by giving you an excellent simple overview of the location of where the MDM and AAD certificates will be stored.
| AADR + Intune Enrolled | Intune enrolled during AADJ | Autopilot | Existing AADJ + Intune enrolled with GPO | Existing AADJ + Intune Enrolled with MDM-Only | Existing AADJ + Intune Enrolled with Company Portal | |
| AAD identity cert | Current User personal Store | Local machine Personal certificate store | Local machine Personal certificate store | Local machine Personal certificate store | Local machine Personal certificate store |
| MDM cert | System User Personal certificate store | Local machine Personal certificate store | Local machine Personal certificate store | System User Personal certificate store | System User Personal certificate store |
I still need to add Hybrid… but then again……
14. Microsoft their Script/opinion
At the start of this blog, I was mentioning this blog. It showed us how to recover from an expired certificate
Sync issues 0x80190190 and the Intune MDM device Certificate (call4cloud.nl)
When looking back at the script I mentioned in that blog, something catches my eye, and something made me laugh a bit. Let’s start with the part that catches my eyes
As shown above, even Microsoft their script to fix it is looking for the “SslClientCertReference”. That can’t be a coincidence, right? Let’s move on to the funny part
Microsoft doesn’t care about our device when the Intune Device Cert is not in the MY;SYSTEM certificate store. So for everyone who has a lot of devices without the cert in the Local Machine Certificate store, screw you! 🙂
Conclusion
In my opinion, AzureDomainJoined sounds way better than UserEnrollment, and if you ask me…. I guess the UserEnrollment option could give you a lot of issues.
What happens when the certificate has expired? Is the device capable of renewing it? As I have seen many devices with duplicate or no certificates and sync errors in the last few months
What happens when the device switches to another user without wiping it?
I know for sure that the GPO/PowerShell option works perfectly (even when it’s not supported) and looking at all the topics that are mentioning that the device stopped syncing and how they enrolled the device is can only have 1 conclusion….. it’s because of the enrollment and the certificate being placed in the wrong store.
Hello Rudy, great article. Sadly we are affected by this problem. Wondering why it worked for years as it seems.
Seems as the script you published for automation is missing a “$” in the first line, assuming it should be a variable.
It works only if SYSTEM has only one certificate in the personal store, if there are more present some logic has to be added to identify the correct certificate to export I think.
Had also a case open with Microsoft, but they focus on the fix you mentioned, remove the clients and re eroll them, which is not suitable for larger environments.
Ow… oops.. it was indeed missing a $, just changed it… also added the system privileges requirement…
That fix is indeed not fun when you need to do so on large scale… hopefully (i guess not) Microsoft will come up with a proper way to fix it
To be honest, it seems Microsoft is not interested at all to do something. At least I have been told that there will be no RCA and also no support to build the script or whatever. I will not blame the engineer I have been working with, since those actions are out of his support boundaries. He did what he could do. But there was no escalation, transfer to higher support level. Do not know what is going on behind the scenes, maybe a fix will be presented in some time.
Also wondering if if might be possible to have the deviceenroller to look in the “wrong” store for the certificate? Have to do some investigation 🙂
Thanks again for all your work on this issue and this blog at all – highly appreciated!
Hi.. Thanx! also added some more information about how the device knows in which store the certs belongs to… will digg some more if you could “alter” the request
I noticed the image with Groku hiding from the MDM cert. So, uh, I how do I do this for Hybrid? I only experience this on hybrid devices. None of our AADJ devices have this issue, just HAAJD. Any updates?
Hi,
Thank you for your article,
i have a question please ? we have a co-managed environment and affected with the same issue
so, when i export and import the certificat, the probleme persist
could you please help ?
Do you have some logging to share, as I need a bit more info to go with I guess
Hi Rudy, we had this issue on a lot of devices and i was already trying to fix this following this article. But somehow in the last two weeks this issue has been resolved automatically on all the devices but i can’t find any article from Microsoft where they explain anything about this.
In the logs i also see that it sets the MDM Certificate ‘Set MdmDeviceCertificate : ……..’
Hi… did you happen to have installed the preview updates from last month (September) ?
Where can we find the MDM certificate on linux(Ubuntu)/macOS devices when these devices are enrolled with Microsft Intune?
So I’m just starting to see this on my own environment, and I’ve come across a variation of this where the cert was in the correct local machine store, but the Provisioning\OMADM registry value for SslClientCertReference value was missing entirely. I was able to populate it manually using the correct thumbprint ID and after restarting IME service, it immediately started syncing and is back up to date.
But here’s the kicker… all of these systems were provisioned by Autopilot as pure AADJ+Intune, so I have no idea how this could have happened.
Regardless, I’m actually gonna put together a little detect-remediate script for this, because this sort of stuff, so I’m gonna bookmark this blog post and come back to share it when I’m done. This is nuts though… especially the part in the MSFT script suggesting they “don’t care.”
Hi… Mmm… I am interested!.. what kinda sync errors are you getting? could you share some screenshots ? was the whole key missing or only the contents of that key? (info@call4cloud.nl)
That reference should be configured once the certificate arrives at the device (part of the security token)…. so that’s weird its gone…
looks like the device cert is now enrolled as non-exportable and in the TPM, at least for my Autopiloted Win11 devices. have you managed to export it for Fiddler decryption?
Hi… When i open the local cert store as admin, i can still export it (latest windows 11 build) not with a private key but dont need that for fiddler
I have a question about the MDM cert when running certutil -store my.
If it says Missing store keyset, does that indicate the cert is corrupted, missing, or just not communicating with Intune?
And is the fix to manually reenroll it into Intune?
Hello,
Unfortunately at the end of 2024 still with similar issue. In my case , even as NT AUTHORITY/SYSTEM im not able to export the certificate with private.
Using psexec Export-PfxCertificate : Cannot export non-exportable private key.
Do you have any suggestions ?
My devices is manually enrolled.
Depends on what issue you have…:) what issue are you trying to fix ?
Hello
It’s been a long time since I wrote it, so I don’t know if you’ll check my comments, but I’m writing because I have a question.
I saw this while searching for an issue where the device is not registered in intune now.
I don’t know the exact reason why the device is not registered in intune yet, but I’m trying to proceed with the above method.
I’m not sure if it’s a certificate issue because it’s still before applying the above method, but if it’s a certificate issue, can I know why?
(I’m in a network environment where only the URL and IP allowed by MS to communicate on the M365 side in an Internet-free environment are open in the firewall.)