Last Updated on August 19, 2023 by rudyooms
This blog will show you how you could “Kickstart” your EPM enrollment on your own turf when the EPM agent is somehow not being deployed even when you have met all the requirements!
I will divide this blog into multiple parts
- Kickstarting it on your own!
When first looking at EPM and how it triggered a Silent *MMP-C enrollment using the AAD device token I was pretty amazed. If you don’t have read that blog, please do!
While writing that blog I also noticed some EPM Enrollment issues being mentioned in the tech community
Those enrollment issues were simple being caused by not having all the Windows Client requirements met.
If you don’t have an up-to-date device, you can forget about deploying EPM to your device. When looking at some other enrollment issues, they were caused by errors with the Device Health Monitoring Policy (Send Elevation Data for Reporting)
If somehow this policy failed to deploy, you will end up with an error mentioning the “Allow Device Health Monitoring” and the EPM agent would not be installed
As shown above, it only shows the “Allow Device Health Monitoring” setting run into some error. Nothing more! Microsoft their advice, for now, is to change the “Send Elevation data for reporting” to NO
When taking a closer look at the device you could notice that the device management event log is mentioning the fact that it couldn’t find the file
Somehow on those devices, the DeviceHealthMonitoring registry keys were all missing in action. As shown below, in a normal working situation, the device should have this key.
If those keys are missing, you are up for a challenge! Let me help you a bit!
2. KickStart it on your own!
Kickstarting the enrollment on your own would bypass the requirements. The only requirement left would be to have a device that has the October update installed. The Declared Configuration Service needs to be active on the device!
So let’s move on to kickstart the MMPC / Linkedenrollment on your own because it is supposed t be fun!
After making sure the device was enrolled with Intune and the initial sync was done I opened a PowerShell session and elevated myself to “SYSTEM” with the use of the psexec tool.
Once elevated, I first installed the localmdm powershell module
Install-PackageProvider -Name NuGet -Force
Install-Module -Name localmdm -Force -SkipPublisherCheck
Once I installed that beautiful tool from some stranger called Niehaus, I created the same CSP I got from another great tool! The syncml tool!
With the <syncbody> in good shape, I made sure I opened a new PowerShell session with the -MTA parameters
Within the MTA PowerShell session, I copy/pasted the sync body and fired off the send-request
$test1 = @" <SyncBody> <Exec> <CmdID>12</CmdID> <Item> <Target> <LocURI>./Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/LinkedEnrollment/Enroll</LocURI> </Target> </Item> </Exec> </SyncBody> "@ send-localmdmrequest -SyncML $test1
Within a few minutes, the device got enrolled into MMPC, got the Intune Enrollment linked to the Privilege Manager, and got the EPM agent installed
I was wondering if Intune had the same feeling. So I opened the Intune portal and looked up the device, only to notice every required setting was marked as “succeeded”
Knowing how to trigger stuff on your own turf, can be very useful if you want to spot every single detail in it. Besides getting to know the details a bit faster, you can also use it to trigger it on your own if for some reason the EPM deployment doesn’t work