Last Updated on December 23, 2023 by rudyooms

This blog will be about me trying to enroll my device with the latest 25977.1000 insider preview by using Autopilot. I will show you how I stumbled upon some issues that could potentially break stuff.

You might be wondering what stuff? Let’s find out what “new stuff” will break your EPM Enrollments if you are unaware of some critical changes. This blog will show the first one!

I will divide this blog into multiple parts.

1. Introduction
2. Something not set?
3. Troubleshooting
4. LinkedEnrollment CSP
5. DiscoveryEndpoint
6. LinkedEnrollmentNode/ Enterprisecsps
7. A Funny Thing
8. The Flow
9. Conclusion

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. This was my view, while I was playing around with the EPM Enrollment and Autopilot, while I was on vacation in Luxemburg 🙂

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 in time, I noticed that my device did not get 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 taking a good look 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 not knowing 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 off, I checked the registry to make sure the DeviceHealthMonitoring settings arrived on the device.

Comparing them to a working one, showed no issues…. but Intune and the EPM settings report were giving 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 devicehealthmonitoring 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. Using that LinkedEnrollment\Enroll CSP is of course not supported but it had a success rate of 100%. Until now, it could always kick off the MMPC enrollment. I have never seen it failing even not 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 was trying 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 linkedenrollment and mmpclocked keys (as expected).. and also the missing discoveryendpoint?

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

Now I knew for sure, that this CSP is required, the first fix I implemented was creating a CSP in Intune to define the official (or the not official) discoveryendpoint. 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 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 with each version of a new insider, I am moving over the important Dlls to my device in a separate folder. 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 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 is requiring the DiscoveryEndpoint to be set.

After I made sure 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

The moment I was almost done writing this blog, I was doing some more research. While going through the DMClient documentation, I noticed a change I didn’t notice 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