Troubleshooting Intune Endpoint Privilege Management

Today I want to show you how you can troubleshoot issues with Intune Endpoint Privilege Management (EPM) and will try a little deep dive in how it works.

Policies

Let’s start with the basics, in order to get Intune EPM started, we need to assign at least an EPM Settings policy from Intune to the device. In the settings policy we will configure how EPM should behave, in my case I want to use the support approved flow as fallback, if someone requests an elevation for an App that does not have a specific rule assigned:

Additionally, it makes sense to create and assign a rules policy, where we will configure which Apps have specific rules set, to change the behavior of EPM for these Apps. For example, Testapp1.exe should be automatically elevated and child processes will only be elevated if there is a separate rule configured:

Testapp2 for example should only be elevated if the user enters a business justification, but this time all child processes will be automatically elevated (this can lead to have processes elevated that you don’t want to be (e.g. run a cmd.exe from the File open dialog of your app), so be careful with this setting, only use it, when it is absolutely necessary.)

Enrollment

Registry

Now that we have configured everything that we need, we should see a few things happening on the client. The first thing is the “dual enrollment” where the device will do an additional MDM server enrollment to the service that is used for Intune EPM. You can see this in the registry in the “Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\” hive, that now additionally to the usual Intune enrollment key (ID is unique per device):

We should now see the enrollments key for the “dual enrollment” Intune service that EPM uses:

Task Scheduler

Additional to the registry, we should also be able to see the additional enrollment id in the Task Scheduler (must be started as admin) in: “Microsoft -> Windows -> EnterpriseMgmt. Here the tasks from the “normal” Intune enrollment. You can see the “Schedule #3” runs every 8h which matches the Intune check in cycle.

Additionally, we can now see the additional folder with the same id as in the registry containing the tasks for the “EPM enrollment”. You can see the “Schedule #3” is executed more frequently, on my test device all 3h50min.

Event Viewer

We can also see the enrollment in the Event Viewer under “Applications and Services Logs -> Microsoft -> Windows -> DeviceManagement-Enterprise-Diagnostics-Provider -> Admin
If there are issues with the enrollment, you should see error messages like this one, showing issues with MDM Declared Configuration:

Intune EPM Agent

Now that we looked into the dual enrollment, let’s have a look at what should happen next. The installation of the Intune EPM Agent. It will be installed in a similar way that the Intune Management Extension (IME) gets installed. Just like when we first assigned for example a Win32 App, the IME gets installed automatically using the MSI Line-of-business App flow of the MDM Stack:

Once we assign the EPM Settings Policy and the “dual enrollment” started, we can see the EPM Agent is installed using the same method:

From here on, it’s really just a like “normal” MSI LOB App, which gets installed, has an uninstall string in the registry:

And gets installed to C:\Program Files\Microsoft EPM Agent:

Logs and Troubleshooting

PowerShell Module

If we made it this far, and the device enrolled successfully and the EPM Agent got installed, we can start looking in the logs to start troubleshooting. To see if our policies got applied to the device, we can use the PowerShell module provided with the EPM Agent itself. This module is delivered in the “EPMTools” Folder within the application folder together with a helpful readme.md file that explains how to use the module:

Since the module can get changed with every update of the EPM Agent, I will not get into too much detail, just a few examples of what you can do with it. First you have to import the EpmCmdlets.dll module into PowerShell, then we can start:

We can for example lookup the settings for a specific app (Testapp1.exe from the demo) and see what is configured for it:

And much more…

Logfiles

In the Install folder we can also find all logfiles from the EPM Agent, where we can find all kind of information about the Agent, the driver and the overall health of the service:

Rule Files

What can we do, if we don’t want or can use this module? Well, all the data is available in clear text as well. All Policies are stored as .dat files in the Policies Folder of the EPM Agent:

We can open these in e.g. notepad and see all our policies in a json format and again we can find our testapp1.exe

Since these policy files are conveniently formatted as json we could easily create our own script, to read all policy settings if we want…

Registry

Additional to these rule files, there is a corresponding entry in the registry for each of these policy files and for each app that will be used by the PowerShell module for the file lookup:

As you can see, all policy files are stored with a base64 binary encoded SHA 256 File hash, file length and a matching signature, so a local file manipulation should not be so easy 🙂

Common errors

Now that we have some general info available, on how to troubleshoot the EPM Agent itself, I will show you a few common errors or issues that I saw with the current state. Check out the official Microsoft Docs for a more up to date list of things to consider: https://learn.microsoft.com/en-us/mem/intune/protect/epm-deployment-considerations-ki?WT.mc_id=MVP_317638

Support approved (primary user)

If you get this error message in a support approved flow, make sure the logged on user is the primary user of the device:

Once the primary user is modified to the currently logged on user, you will be able to send the request:

File from Internet

If you try to elevate a file, that has the “file from Internet” flag in its alternative data stream, you will see an error:

If you want to run this app, you can either remove the flag from the file properties:

Or remove it using the PowerShell “unblock-file” command:

Now you can run the App without issues.

Support approved (slow)

If you requested a support approved elevation, someone approved it, but nothing seems to happen, you can manually trigger a sync and you should relatively immediately the toast notification, that our request was approved.

And you can finally run the app.

EPM User account

One last thing to mention, especially compared to other EPM Solution, the Intune EPM Agent is not modifying the token of the current user, but instead it uses a virtual account to run the elevated apps. You can see this account under C:\Users once you enable hidden folders. These Accounts follow the naming schema “Domainname_Username_$”:

Keep in mind, that for all elevate apps, this would be the “current user”, so if setups are copying files to the current user appdata, this will end in this user account and not your “normal” user account. So, a whoami in cmd will output this user account. (Notice, they are still calling Intune “mem” :))

This will also mean, you cannot access network resources that authenticate through e.g. kerberos from within these sessions right now.

Conclusion

Hopefully this deep dive, can help you working with Intune EPM. So many new or different things come with Intune EPM, the additional enrollment, the EPM Agent itself and a lot more smaller things, so in my opinion it makes sense to have a look in how it works, in order to be able to troubleshoot issues here. If you have any additional things that I should cover, let me know in the comments below.