Call4Cloud | MMP-C | Autopilot | Device Preparation

Alice and the Intune MDM Device Certificate

Patch My Pc | install & update thousands of apps

This blog will show you how to start troubleshooting when some features of the Company Portal aren’t working. In addition to the issues we had with the Company Portal, we were also experiencing syncing issues with the Intune Service!

While troubleshooting, it really took me down multiple rabbit holes

1. Introduction

In one of my last blogs, I showed you which steps you could take to implement Adminless and how to make sure the end-user experience is still great.

At the same time, we had a customer specialized in electrical systems with a dedicated service team who was very interested in making me an admin solution. After a good conversation to determine if other solutions would perhaps be better, we noticed the service team really needs to be able to configure or install apps when they need them.

Within a few minutes, we ensured that only the technical service group was receiving the Make Me admin app. All those users were very happy except for one, the make me admin tool was not pushed to his device.

2. Troubleshooting

First, we need to do some troubleshooting before we can determine the root cause. When an App is not automatically pushed to the device, you can also configure it as “available.” If you configure the app as available, the user can manually install the application from the Company Portal app, so we asked the user to open the company app and install the app.

As shown above, the app just hangs on downloading… That’s odd because the app is not that big. We opened the incoming folder to see if the Intune management extension was doing “something.”

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Incoming\”

But it was completely empty. We needed to be sure that the Make Me Admin app was the only one experiencing problems, so we tried to install another app.

This time, we received the error: “While requesting the app an error occurred“. After looking at some other information and settings in the company portal, we noticed that the compliance status was also not checked for the last 16 days. That’s odd?

compliance was not checked for the last 16 days

We pressed the button to check if the device still had access to the company resources… but again, nothing happened, nothing changed, and there were no errors or warnings. The next step was to sync the device, so we did.

last sync attempt failed

The last sync attempt failed. Of course, we tried to sync the device from within the Intune portal, but nothing changed again. We even tried to sync the device from the account settings.

synchronisation could not be started and showing the 0x80190190 error

As shown above, synchronization couldn’t be started but this time, we got a nice error with it:0x80190190 AKA Invalid Request (400)

The next thing we did was check the intune mgt log. This log is very important for troubleshooting app or sync problems.

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\intunemanagementextension.log

DNS detection: A Proxy for url call failed

DNS detection: A Proxy for url call failed? There were definitely no proxy servers configured. All other devices were working without any problems, but to be sure there was also no proxy configured for the Intune management extension, we checked the registry.

HKLM:\Microsoft\Softwre\IntuneManagementExtension\Proxies\AzureAD

As shown below… no proxy!

You could also use dsregcmd /status within the user’s session to check if there are somehow proxies configured!

Now that we are 100% sure there are absolutely no proxies configured, we needed to determine if the IP address is the same as on another device. We did ICMP/ping from a working device and the device with issues. Both of them showed us the same IP address corresponding to the FQDN.

Okay, that’s strange. I was expecting to get an error message: hostname not found, but it just resolved the same IP address. There goes my poem

Now we know it was definitely not a DNS issue, let’s check if there is a difference when we open the edge browser and browse to the FQDN (fef.amsub020.manage.microsoft.com) on those two devices.

3. Checking the Intune MDM certificate

Okay, so now we noticed that the not-working device is prompting us to select a certificate. It certainly looked a lot like the missing MDM Intune certificate issue from some time ago. The Intune MDM certificate was missing after some devices were updated to the latest build.

The Intune MDM Device certificate is issued when your device is enrolled in the Intune Service. It is used to communicate with the Intune service.

the microsoft intune mdm device ca certificate

Please note: This Intune certificate must NOT be mixed up with the Azure Ad Certificate (MS-Organization-Access), as shown below!

MS-Organization-Access certificate

Please beware, that when the Intune certificate is NOT present on the device it can’t establish a trust relationship with Intune. You will notice some problems will start to occur.

  • It stops receiving new policies/apps or changes to existing policies
  • There could be compliance issues because the compliance check is not working.
  • The company portal is just totally broken.

We opened the Local certificate store to rule out the missing Intune certificate issue!

As shown above, the Intune certificate was still present! But I am not done yet! Let’s continue and check out if the Microsoft Intune MDM device certificate also matches our own enrollment.

To be sure which certificate was in use, I opened the registry and compared the “issued to” with the one mentioned in the MS DM server registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\……\DMClient\MS DM Server

entdmid matches the intune certificate

As shown above, the EntDMID matches the Intune MDM device certificate and inside this key, there is a “GUID” key that also matches the EnterpriseMgmt task in the task scheduler!

Okay… We are now sure that we don’t have any old and revoked Intune certificates, and we are also very happy that the Intune certificate was still present, but does the Intune device cert also have a matching private key?

the certificate still has the private key attached

Please take a look at this blog for more information about this “private key”

But wait….what? After taking a second look at the Intune MDM certificate, I noticed the Expiration date is 10-03-2021. That was last month. That could definitely be the problem. But still, it’s very strange that the user was not experiencing any other problems.

Some background information: You could also use Graph to check the device Intune Certificate expiration date

 Certificateexpirationdate shows the certificate is expired

Let’s continue our investigation. Normally, the schedule created by enrollment for renewal of certificate warning would ensure that the certificate is renewed. I guess this schedule didn’t work for some weird reason.

We tried to manually run the task even when we knew this wasn’t going to work but we needed to try. Before I continue, I will show you some more information about this “Schedule Created by enrollment client for renewal of certificate warning”

4. Certificate Renewal Flow

If you are interested in how the Intune Device Certificate is renewed and what could break during that process, this blog should explain all the details that are out there! I hope you enjoy it

What happens when renewing the Intune MDM Certificate (call4cloud.nl)

5. Solving the Intune Certificate problem

Now that we have seen the certificate renewal process let’s solve it! We have multiple options if we want to solve it. We went for the first option just because we did not have the time to get more information about this issue… and time is money.

Please Note: Before trying to solve it, please ensure you aren’t blocking personal devices in the Intune Device Enrollment Restrictions.

Otherwise, you could end up with error 71 mentioning that the MDM-Server doesn’t support this platform (DeviceManagement-Enterprise-Diagnostics-Provider) This error is also known by the famous error code 0x80180014

80180014 is shown when the mdm server doesnt support this platform or version

5.1. Manually disconnect and connect to Azure Ad join

After rebooting the device and reconnecting to Azure Ad, we could log in again. Of course, we needed to configure Hello again and other settings. We also noticed the Make me admin tool was installed almost instantly. Again we opened the certificate store to check the certificate.

A new Intune certificate was deployed, and of course, the syncing and app installation issues were also resolved…

5.2. Automatically without configuration loss

After some reading, while creating this blog, I found out that it was also possible to solve this problem without some configuration loss. This method should work. (I did test it of course, on a working device)

This PowerShell script will:

*Remove Enrollment registry keys

*Remove the Intune MDM certificate

*Remove the scheduled tasks

*Reenroll into MDM

You will need to run it as system!!!. You run PowerShell as system, by using: psexec -i -s powershell.exe

$RegistryKeys = "HKLM:\SOFTWARE\Microsoft\Enrollments", "HKLM:\SOFTWARE\Microsoft\Enrollments\Status","HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked", "HKLM:\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled", "HKLM:\SOFTWARE\Microsoft\PolicyManager\Providers","HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Accounts", "HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Logger", "HKLM:\SOFTWARE\Microsoft\Provisioning\OMADM\Sessions"

$EnrollmentID = Get-ScheduledTask -taskname 'PushLaunch' -ErrorAction SilentlyContinue | Where-Object {$_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt*"} | Select-Object -ExpandProperty TaskPath -Unique | Where-Object {$_ -like "*-*-*"} | Split-Path -Leaf

		foreach ($Key in $RegistryKeys) {
				if (Test-Path -Path $Key) {
					get-ChildItem -Path $Key | Where-Object {$_.Name -match $EnrollmentID} | Remove-Item -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue
	}
}
$IntuneCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
		$_.Issuer -match "Intune MDM" 
	} | Remove-Item
if ($EnrollmentID -ne $null) { 
	foreach ($enrollment in $enrollmentid){
			Get-ScheduledTask | Where-Object {$_.Taskpath -match $Enrollment} | Unregister-ScheduledTask -Confirm:$false
			$scheduleObject = New-Object -ComObject schedule.service
			$scheduleObject.connect()
			$rootFolder = $scheduleObject.GetFolder("\Microsoft\Windows\EnterpriseMgmt")
			$rootFolder.DeleteFolder($Enrollment,$null)
} 
} 

#####IF EPM ENROLLED#### Unblock this 
#$EnrollmentIDMDM = Get-ScheduledTask | Where-Object {$_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt*"} | Select-Object -ExpandProperty TaskPath -Unique | Where-Object {$_ -like "*-*-*"} | Split-Path -Leaf
#		foreach ($Key in $RegistryKeys) {
#				if (Test-Path -Path $Key) {
#					get-ChildItem -Path $Key | Where-Object {$_.Name -match $EnrollmentIDMDM} | Remove-Item -Recurse -Force -Confirm:$false -ErrorAction SilentlyContinue
#	}
#}
#if ($EnrollmentIDMDM -ne $null) { 
#	foreach ($enrollment in $enrollmentidMDM){
#			Get-ScheduledTask | Where-Object {$_.Taskpath -match $Enrollment} | Unregister-ScheduledTask -Confirm:$false
#			$scheduleObject = New-Object -ComObject schedule.service
#			$scheduleObject.connect()
#			$rootFolder = $scheduleObject.GetFolder("\Microsoft\Windows\EnterpriseMgmt")
#			$rootFolder.DeleteFolder($Enrollment,$null)
#} 
#$IntuneCert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {
#		$_.Issuer -match "Microsoft Device Management Device CA" 
#	} | Remove-Item
#}	
Start-Sleep -Seconds 5
$EnrollmentProcess = Start-Process -FilePath "C:\Windows\System32\DeviceEnroller.exe" -ArgumentList "/C /AutoenrollMDM" -NoNewWindow -Wait -PassThru

Please note: When you don’t delete all of the stuff that I mentioned you will end up with some weird behavior mentioning that there are no more endpoints available from the endpoint mapper 0x800706D9

the scheduled tasks hshowing that there are no more endpoint available from the endpoint mapper (0x800706d9)

So please ensure everything is removed before starting the enrollment using the deviceenroller again!

5.3. Microsoft Remediation script?

Unfortunately, I did not have a real-life problem device to test if this script would also work if the intune device certificate is expired: https://aka.ms/mdm_enrollment_cert_script

But looking at the script itself, I would say yes at first sight?. To be sure, I needed to break down a test device to check it out. After removing some registry keys and the device MDM certificate, I tried it out.

It’s not working because the device is not co-managed. So this option is not the one you need when your device is not co-managed.

After this error, I applied the Powershell script from option 2… After a minute or two, the certificate was recreated, and the device was ready to sync with Intune again.

6. Monitoring

Of course, you want to monitor this important certificate to ensure it’s available and certainly not expired.

You could use this script as a part of your Proactive remediation detection script

Try {
$Result = Get-ChildItem -Path cert: -Recurse | where { $_.notafter -le (get-date).AddDays(30) -AND $_.notafter -gt (get-date) -and $_.issuer -like "CN=Microsoft Intune MDM Device CA" }  | select issuer, notafter
$ID = $Result | measure-Object
If ($ID.Count -gt 0)
{
    Write-Output "Intune MDM certificate is going to expire $result"
  Exit 1001
}
Else
{
    Write-Output "Intune MDM certificate is NOT going to expire"
  Exit 0
}
}
catch
{
Write-Warning "Value Missing"
Exit 1001
}

7. Troubleshooting Intune Device Certificate Issues

I removed this part from this blog and dedicated a unique blog to it. It will show you all the steps you could take when you need to troubleshoot 0x80072f99 and 0x80090029 errors.

https://call4cloud.nl/2022/07/privatekeycertificate-missing-syncerrors

Conclusion:

Sometimes, an easy-looking problem will take you down the rabbit hole. Luckily, when you are at the bottom of the rabbit hole, you can climb up again and solve the problem.  Lesson learned: if a new problem finds your way that you have never seen before, just go for it!

While troubleshooting and solving the problem, you could learn a lot of new stuff. Without a working Intune device certificate, a lot of things will break, but with multiple working certificates, things could also break.

13 thoughts on “Alice and the Intune MDM Device Certificate

  1. Thank you, sir. The re-enroll script helped me get a machine back into MDM that had the error in company portal saying “this device is already set up in another organization”. This happened because a machine was imaged with the same name as the problem machine, then renamed and deleted from on prem AD. (we are in co-mgmt with SCCM). We then re-joined to the domain (which created a new computer object), and everything worked except for intune mdm. Thanks for the quality content!

  2. Thank you very much Rudy! Same as Max, I wasn’t able to enroll devices that were imaged with the same name and your script helped to enroll the device back to Intune. Great content !

  3. Hi Rudy,

    Your blogs and your guidance on this issue has given me a new way to troubleshoot any issue.

    Thank you so much for helping Sysadmins like me.

    Your in-depth saved a lot of my time.

    Kudos to you Rudy. 🙂

    Regards,
    Ashish Arya

  4. Hello,

    First of all thank you very much for the article. When I try to follow the 4.1 method, and adding the AD Account again, I received the error “Something went wrong. Confirm you are using the correct sign-in information and that your organization uses this feature. You can try to do this again or contact your system administrator with the error code 80180026. Try again.”

    I created a local admin account, logged in with this account, disconnect the Azure AD account and try do add again. Is something missing me?

    We’ve have got 3 more devices that the certificate were not renewed without aparently explanation, and I have to fix it without resetting the PC.

    Thank you

    Sérgio Batista

    1. Could you tell me some more about your setup? was the device haadj joined before or? did you also tried the 4.2 option?

  5. Hi There
    Your post just fixed a really enoying bug where our intunewin package was simply not downloading. running your powershell fix script did the trick.
    However I have one question: I am having this problem on every machine that was already azure ad joined and was enrolled by clicking “enroll only in MDM”. Do you have an idea why this cert issue happens then? Is this a know issue? I didn’t find anything about it.

    1. Hi… First of thanx!!!.

      Mmmm, thats good to know… as I am hearing this a lot… But no one could answer the question of how those devices were enrolled… Got me thinking
      This should be a better option to enroll the devices instead of enroll only in mdm… 🙂

      https://call4cloud.nl/2020/05/intune-auto-mdm-enrollment-for-devices-already-azure-ad-joined/

  6. Thank you for all the great information. While the script in 5.2 resolved the initial problem, I found after it was run that many of the built in scheduled tasks have disappeared. This was first noticeable when I could no longer type in the search bar and found that the scheduled task for ctfmon.exe was gone. This was easily remedied by exporting it from a known good computer and importing it to the one that was not working. However, upon further investigation doing a side by side compare to a known good computer, most, if not all of the scheduled tasks under Microsoft/Windows/ are gone! This includes the one for bitlocker which I believe is why now my computer shows not compliant in Intune because of bitlocker, even though the drive is encrypted with bitlocker. In this particular case, you cannot import the task from another computer as it just gives an error saying the task scheduler service is not available. Have you heard of this happening to anyone else and if so, is there a good solution short of reimaging the device?

    1. Hi… that script was indeed already an older version with some flaws in it if it couldn’t detect the enrollment. I created the intunesyncdebugtoolkit some time ago with the updated version in it (also updated the script in this blog)

      https://www.powershellgallery.com/packages/intunesyncdebugtool/1.0.0.19/Content/IntuneSyncDebugTool.psm1

      1. Thank you for the update, any tips on how to repair the scheduled tasks that got inadvertently removed by the older script? I’ve done some work exporting from a known good machine and importing to the one missing them, but in some cases it doesn’t allow you to import them.

Leave a Reply

Your email address will not be published. Required fields are marked *

  −  1  =  2

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.