In the Shadow of the DiscoveryEndpoint

This blog will be about my attempt to enroll my device with the latest 25977.1000 insider preview using Autopilot. I will show you how I stumbled upon some Endpoint Privilege Management DiscoveryEndpoint issues that could potentially break things.

You might be wondering what EPM Discovery stuff? If you are unaware of some critical changes, let’s discover what “new stuff” will break your LinkedEnrollment / EPM Enrollments. This blog will show the first one!

1. Introduction:

On (19-10-2023) while enjoying my vacation, I downloaded the latest insider canary iso 25977.1000 and created a new Virtual Machine to enroll the device with Autopilot. I wanted to trigger Autopilot v2 AKA APv2 by setting a specific reg key, which I also mentioned in this blog.

Windows Autopilot Version 2 | APv2 mode | DevicePreparation (call4cloud.nl)

Before doing anything weird and doing a “rudy thing”, I installed the Virtual machine with an officially downloaded iso from MS to make sure everything works as expected (setting the baseline of what should happen before breaking it)

At that moment, I noticed that my device did not have the Endpoint privilege management agent (EPM) installed.

To be sure I wasn’t going crazy or messed up something else, I also reinstalled the older Insider preview machine (25951.1000) and a VM with the latest Production build from last month 2023-10 (no insider)

Both of those other VMs got EPM installed. A funny thing is that the insider 25951 one, got the EPM agent installed during the Enrollment Status Page step: registering for MDM provider

So, it looks like something is off with the 25977.1000 build. To make sure, I reinstalled it again and watched the DeviceManagement event logs

2. Something not set?

Before doing anything else I started with looking at the device management event logs.
During the Autopilot enrollment, I noticed some event logs showing up, mentioning Dual Enrollment: discovery endpoint is not set.

And just after the first error, another one: The System cannot find the file specified: Linkedenrollment/Enroll

For people who do not know what LinkedEnrollment means, I would recommend reading my previous blogs about the world-famous Declared Configuration enrollment.

MMP-C | Microsoft Management Platform Cloud (call4cloud.nl)

Luckily, with the EPM enrollment flow in the back of my mind, I started looking at one of the requirements, the HealthMonitoring settings. First, I checked the registry to ensure the DeviceHealthMonitoring settings arrived on the device.

Comparing them to a working one, showed no issues…. but Intune and the EPM settings report gave me a different response.

To resume: The Healthmonitoring is configured but the enrollment process fails to start the discovery because the Discovery Endpoint is NOT set….I guess we need to take a closer look at it, do some troubleshooting, and take a look at what should happen!

3. Troubleshooting

If we take a look at how a device SHOULD be enrolled into MMPC to kick off the EPM installation, there are a few things that should be configured during the first few steps (things could change…. )

• 1: LinkedEnrollment sub reg key and the MMPCLocked Key will be set at first

BUTTTTT, those keys weren’t created on the problem device! No linkedenrollment and no MMPCLocked reg keys

• 2: Schedule to enroll the device for dual enrollment to Mmpc

BUTTTTT again, because the linkedenrollment and the MMPC locked key were not set, this important scheduled task is also NOT created on the problem device (insider build 25977.1000 ) 

At first, I found it a bit weird because, as far as I know… between the device health monitoring settings that were delivered to the device and those registry keys, and the scheduled task is set, there isn’t much in between. So, I needed to find out what was happening. Let’s go hardcore!

4. LinkedEnrollment CSP

I was curious if I could manually enroll the device to find out which errors I could get. Of course, using that LinkedEnrollmentEnroll CSP is not supported, but it has a success rate of 100%. Until now, it could always kick off the MMPC enrollment. I have never seen it fail, even on W365 devices in which EPM was not yet supported.

So, I kicked off that LinkedEnrollment CSP with the localmdm to enroll the device manually

But this time… it got me the same event log error as I showed previously … Mmm… that’s funny as if the PowerShell command is not properly configured. So I decided to take another look at the DMClient CSP documentation. I noticed that something called discoveryendpoint is now mentioned in the DMClient CSP documentation.

Discoveryendpoint… sounds like the endpoint we need?

5. DiscoveryEndpoint

Let me tell you a funny story before we proceed… with the previous working insider preview build, I was playing around with the EPM enrollment and also trying to get/set a specific endpoint. Why? because I had the stupid idea to try to enroll the VM into “something else” (AKA confidential…not going to talk about it… blablabla).

That particular blog I wrote, is in drafts and would probably stay there forever (next to some others). But nothing happens for no reason because while trying to configure that endpoint, I also tried to configure the DiscoveryEndpoint , to accomplish the same thing.

When I tried to manually set or get the DiscoveryEndpoint (with the older insider preview), it got me a 405 error… AKA node doesn’t exist?

Good to note is, that when trying to get all the possible nodes from the linkedenrollment CSP root, it also didn’t show me the discoveryendpoint subnode. Only the enroll/unenroll/priority/lasterror and enrollstatus were available.

When I tried to do the same with the latest 25977.1000 insider preview (which wasn’t working), it did show me the discoveryendpoint! 

Whoop!!! Something was changed in this build and that discoveryendpoint node was added!  Nice?

So, I decided to do something stupid by setting the discoveryendpoint csp manually and trying to enroll the device again. (you could also just create a CSP in Intune to do the same… but capturing errors would be more difficult due to all the other events that get created during a sync)

Within a millisecond… the dual enrollment scheduled task was indeed created!

With that scheduled task created, the device started reaching out to the service! Whoop Whoop!…

Looking at the registry, it also created the required linked enrollment and mmpclocked keys (as expected).. and the missing discovery endpoint.

After the keys were set and the scheduled task was executed, the MMP-C enrollment continued. So, with the DiscoveryEndpoint CSP configured it starts the enrollment, without that DiscoveryEndpoint CSP being set it does not!

Now that I knew for sure that this CSP was required, the first fix I implemented was creating a CSP in Intune to define the official (or not official) discovery endpoint. With this CSP configured, the device initiated the Dual Enrollment.

OMAURI: ./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/LinkedEnrollment/DiscoveryEndpoint

Value:

https://discovery.dm.microsoft.com/EnrollmentConfiguration?api-version=1.0

So we fixed it right? Yeah, sort of, but I was still curious about the “why” and the “how.” Let’s take a closer look at the corresponding DLL files and the code to see if we can find something.

6. LinkedEnrollmentNode/ Enterprisecsps.dll

One of the functions in the enterprisecsps.DLL is to execute the linkedenrollmentnode from the dmclient (sounds like the function that was called upon)

A good thing to add to the story is that I am moving over the important Dlls to my device in a separate folder with each version of a new insider. So, I decided to look at them.

This picture above shows me that in the latest insider preview, the discoveryendpoint was added…. and yeah…. when the CSP is being set, that value will be set in the linkedenrollment registry. 

When looking up that value in the older builds… it isn’t there.

From there on, I decided to do something really stupid (yeah, that’s me.. doing stupid things). Before the Autopilot enrollment, I took ownership of the enterprisecsp.dll and replaced that version from the 25977.1000 build with the 25951.1000 version. Why? to find out if it was indeed the enterprisecsp.dll that was causing the issue and required the DiscoveryEndpoint to be set.

After ensuring the old enterprisecsp.dll was in place, I started the autopilot enrollment…. Guess what happened… The device started the enrollment but again failed when reaching out to the service when it needed to fetch the Device management certificate.

With this file replaced, the discoveryendpoint requirement isn’t there anymore, so one thing is for sure, something inside this version of enterprisecsp.dll is triggering it. I spent some time looking at that DLL file and I guess the only conclusion I can draw is that the device fails to set the linkedenrollment string

It fails to set the linkedenrollment string because the linked enrollment node also has an additional required setting that needs to be set?

7. A Funny thing

When I was almost done writing this blog, I was doing more research. While going through the DMClient documentation, I noticed a change I hadn’t noticed before. (even when it is placed a bit in a bad location if you ask me… it mentions the unenroll …)

Besides replacing MMP-C with Declared Configuration Enrollment, I noticed something else: When the DiscoveryEndpoint is not set, the Enroll node will fail with ERROR_FILE_NOT_FOUND (0x80070002). And there is no scheduled task created for dual enrollment. Owwwwww… oooooopssssie, I missed that one, big time!.

I am still wondering how and why I missed that one but looking at the bright side, I learned a lot while spending some time debugging it… but still, I am unsure if I need to laugh or cry about it.

Also, just thinking out loud here…. Microsoft added this to their documentation, so why are they also not making sure that the DiscoveryEndpoint information is sent to the device when the device is targeted with the EPM enrollment? (Getting the CSP for the dual enrollment/linkedenrollment).

For now, I am going to assume that this will be done in a future Intune release and we don’t need to worry about this one

To add another funny thing, if I hadn’t installed my VM with the latest insider build I wouldn’t have stumbled upon this issue….. and another big one! 🙂

8. The Flow

Conclusion

Sometimes, stuff does change, and now, when deploying EPM, we need to be aware of an additional setting. The discovery endpoint needs to be configured otherwise the device wouldnt enroll into mmpc. When manually setting it with an additional CSP it will create the scheduled task to start the dual enrollment.

I am going to assume that Microsoft will make sure that this DiscoveryEndpoint will automatically be set soon when you are targeting devices with EPM