Call4Cloud | MMP-C | Autopilot | Device Preparation

The Infernal MMP-C Discovery

Patch My Pc | install & update thousands of apps

This blog will be an additional blog post to the MMP-C one. In this blog, I am deep diving into the first MDE MMP-C enrollment steps which will kick in once you have activated EPM/Endpoint Privilege Management.

1. Introduction

Last week, after getting some emails and noticing the same kind of reply(error message) to a question on the TechCommunity, this specific issue got my attention

Endpoint privilege management, deployment unsuccessful with “device health monitoring” error – Page 3 – Microsoft Community Hub

The OP was experiencing an issue when enrolling his devices with EPM (Endpoint Privilege Management). Most of the time this could be caused by not meeting the prereqs (Windows Build) or having SSL inspection in place but this time it was a bit different.

When looking back at the emails I got and spotting the same kind of error on the TechCommunity forum, I noticed a similarity. They were all getting the same error: Failed to enroll MMP-C For dual enrollment mode. Result: (The endpoint address URL is invalid) Event 4022

Failed to enroll MMP-C For dual enrollment mode. Result: (The endpoint address URL is invalid) Event 4022

If we take a look at the error above, we will notice that it got an invalid endpoint address? But what specific endpoint address are we talking about?

Before continuing this blog, I really advise you to read my previous blog about MMP-C (Microsoft Managed Platform – Cloud)

MMPC | Dual Enrollment | Microsoft Managed Platform Cloud (call4cloud.nl)

This blog was literally my first experience with MMP-C…

2. Comparing Intune with MMP-C

To get a better understanding of what could be happening when we got that endpoint error it’s always smart to have a good understanding of what’s actually happening. So let me explain….

When we are looking at the official MDE/Intune enrollment docs we will notice some basic steps in it.

  1. Discovery
  2. Get Security Token
  3. GetPolicies
  4. RequestSecurityToken (Intune Certificate)
MDE enrollment flow.

If we open the mdmregistration.dll and compare it with a WPR trace I got, we will spot a bit of the same behavior in it

Afbeelding met tekst, schermopname, Lettertype, lijn  Automatisch gegenereerde beschrijving

The only major difference is the RequestSecurityToken part has a different name in it. In the mdmregistration.dll this part is called the “Get/Apply Provisioning” as it seems.

So that’s the Intune enrollment! Now let’s do the same with MMP-C. When we activate EPM, a CSP will be kicked off and the device will get a linked/dual enrollment. The device will be enrolled into MMP-C. If we look at the Fiddler trace we will notice that it performs almost the same steps as the Intune Enrollment.

Afbeelding met tekst, schermopname, Lettertype, lijn  Automatisch gegenereerde beschrijving

The device would start the discovery of the enrollment URIs. In the response, we will get the actual enrollment URIs (enrollment.dm.microsoft.com)

In the next step (skipping the token), the device would perform the getpolicies action (getting the x509 certificate blueprint). With the blueprint in our pocket, the device would start the actual enrollment and fetch the corresponding Device Management Certificate.

So basically, the same steps, right? We can even map the mdmregistration.dll MDM mentions to the Fiddler flow

MDE/Intune and MMP-C enrollment all start the same!!! So having a good understanding of the MDE enrollment will help you troubleshoot EPM enrollments!

Afbeelding met Menselijk gezicht, kleding, schermopname, person  Automatisch gegenereerde beschrijving

3. The Flow

You will need to press the image to get the possibility to save the BMP file to get a better picture. So please before you continue the story please take a look at the flow

Afbeelding met tekst, diagram, schermopname, Parallel  Automatisch gegenereerde beschrijving

4. Flipping back to the problem

With a good understanding of the MMP-C enrollment, I needed to ask some more questions as I also wanted to know what happened before he got the error

So when looking at the flow, it fails at the first step, the discovery step. Luckily, before it all falls apart, it could still reach out to the discovery.dm.microsoft.com URL

Afbeelding met tekst, Lettertype, lijn, schermopname  Automatisch gegenereerde beschrijving

As shown above, in a normal situation the device would reach out to the service and will provide its userdomain and the osversion. Again sounds like the MDE Enrollment right?

Afbeelding met tekst, schermopname, Lettertype, lijn  Automatisch gegenereerde beschrijving

Looking at the second step, we will notice that the device found a certificate whose SPKI matched one of the expected pinned certs. When looking at the MDMregistration.dll it really looks like this function in the enrollment flow: IsCertificateTrustedForMmpc

IsCertificateTrustedForMmpc function in the mdmregistration.dll to check if the certificate is valid

So I guess the next step the flow goes through would be the step in which it breaks? This step would be to get the Discovery Response. In a working situation, we should get back the Enrollment URLs

Afbeelding met tekst, elektronica, schermopname, scherm  Automatisch gegenereerde beschrijving

With this information, we could ask if it was possible for him to get us a Fiddler trace. After showing him my Fiddler blog and giving some tips on what to enable he sent me back this wonderful Fiddler Trace.

the discovery of the mmp-c enrollment uri got the "errorCode":"InvalidRequest","message":"Invalid discovery request" response

As shown above, instead of the JSON with the enrollment URI information in it, we got the errorcode: {“errorCode”:”InvalidRequest”,”message”:”Invalid discovery request”}

So the discovery request is invalid? That’s odd, right as the request only contained the domain name and the osversion? Taking a closer look at the request itself, showed me no issues with it.

in the request we could spot the userdomain and the full fqdn of the k12 school

When asking other people who were experiencing the same issue, every time I noticed the same kind of domain name . When looking up that domain name it all pointed to a “school” domain. K12.NC.US.

That can’t be a coincidence? Is it the domain name? Is it because of the amount of dots in it? I guess we ruled out the client part, up to the next step!

5. The Next step?

If you are running into issues with Intune or some other Microsoft product, the first thing you always need to do is put in a service ticket. I am not saying you will always be happy when doing so but that ticket is needed!

When I was talking to some more people experiencing that same error, I realized that they weren’t alone. A lot of other K12 schools could also be experiencing this issue with their EPM enrollments so I decided to reach out to Microsoft myself. By providing the fiddler trace and the ticket number to Microsoft we started a nice conversation. At the end of this conversation, it was clear that something was going wrong.

In the evening (GMT +1) he contacted me again asking if it was working again… The reason why it broke? NDA 🙂

After reaching out to the people who were experiencing that issue, they told me that it started working out of a sudden. It was like magic!!! So thumbs up!! The issue was fixed within a couple of hours!!!

Conclusion

I can’t tell you enough when you need to troubleshoot stuff, you need to know where to start looking (or just ask me ?)

One thought on “The Infernal MMP-C Discovery

  1. This blog post is magic! Thanks again for your help with this one, Rudy. I wish I would have reached out sooner!

Leave a Reply

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

  −  2  =  1

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