The PolicyConsistencyEnsurerJob and the order of the EPM Settings

Last Updated on August 25, 2023 by rudyooms

This blog post will be the second one in my journey to find out what the “refresh schedule created by Declared Configuration to refresh any settings changed on the device” actually does and how this task is triggered.

In the first part, I focussed on PolicyConsistencyEnsurerJob and how this job “lives” in the Endpoint Privilege Management Service (EPMService) to make sure the EPM policies are always refreshed on the device even when it’s offline.

In this part, I am focussing on the 15-minute background schedule and how this refresh is scheduled, and how we can alter those 15 minutes.

I will divide this blog into multiple parts

  1. How it began
  2. The explanation
  3. The hidden flow
  4. A small summary and what’s coming

1. How it began

When doing a small recap from the previous blog post, we will have learned that the PolicyConsistencyEnsurerJob will trigger the refresh schedule created by Declared Configuration to refresh any settings changed on the device.

This “refresh job” will make sure that when somehow the EPM policies were removed that they will be reapplied. This Declared Configuration refresh seems to be triggered each 15 minutes?

A screenshot of a computer screen

Description automatically generated

Besides the 15 minutes, I noticed that when I deleted the EPM registry entries multiple times (just to see what happens) and let it refresh each time I noticed that somehow it tried to refresh it for max 5 times!

A close-up of a computer screen

Description automatically generated

That made me wonder a bit, because are these hardcoded triggers in the EPMservice.exe or something else? This time I will start with the explanation to show you the flow in part 3 of this blog

2. The explanation

I opened the IDA tool and loaded the EPMservice.exe. As we have learned by now, we know that the policyconsistencyensurerjob seems to trigger the refresh itself so I just started searching this keyword in IDA.

After trying to read the code and finding the magical number 15, I noticed something better. As shown below, the EPMservice tries to find the appropriate settings in the registry.

A screenshot of a computer

Description automatically generated

When taking a closer look at the “get” part I noticed that those numbers should be configured in minutes. I decided to look further and tried to find the root registry key.

After a bit of searching, I noticed that the only registry root key that is mentioned in the code is: Microsoft\\epmagent

A screen shot of a computer

Description automatically generated

When looking at those registry keys on my device itself and searching for the keywords: policyconsistency, I didn’t find anything useful.

A screenshot of a computer

Description automatically generated

But I am not easily fooled, so I made sure I created a good filter for Procmon (only showing stuff the epmservice.exe touches) and also opened the EPMservice log files.

After deleting the EPM policies from the registry I decided to just restart the EPMService and start watching Procmon

As shown above, the EPMService is looking for a “settings” registry key inside the EPMAgent root key. Okay I am so interested

Leeds Festival | The clock's ticking if you want to ...

Guess what I did! I just created the settings registry key, started the Procmon trace, and restarted the EPMservice again.

The same thing happened! But this time it didn’t mention it was missing the “settings” registry key!! No, it was mentioning it was trying to find the corresponding jobs by their actual names in the settings registry key.

A screenshot of a computer

Description automatically generated

As shown above, I created the registry keys myself and restarted the procmon trace again

A close-up of a computer screen

Description automatically generated

This time it showed me, it was a success! That was fun!! So I again removed the EPM policies and this time I just waited. Instead of 15 minutes it tries to refresh the policy each 5 minutes?

A screenshot of a computer

Description automatically generated

Whooop… that’s cool, right? We can even change the EnsurerDeclaredConfigurationRefreshRetries if we don’t want to be stuck at max 5 retries!

3. The hidden flow

The whole story but within a simple flow. As always you can click on it to get a link to the BMP file (better quality)

4. A small Summary and what’s coming

To give a small summary from blog posts 1 and 2 combined: The policyconsistencyensurerjob will make sure that the refresh schedule will be triggered to make sure that accidentally deleted EPM policies will be reapplied/refreshed on the device (even when the device is offline!). This background job is executed every 15 minutes and will be retried a maximum of 5 times.

Luckily we can manually change this by creating some registry keys in the EPMAgent\Settings registry key(or maybe not!! Don’t do this in production… as it will not be supported by Microsoft I assume… even when they put it in the code)

The next blog post will zoom in on something that caught my eye when first looking at MMP-C and the WinDC. The WcosCheckin I noticed when the device was checking in to the MMP-C infrastructure service to fetch the latest EPM Policies

Conclusion

If you don’t know how something works, just pull it apart and mess around with it. While doing so, make sure you enable some logging so you get to learn more about it! When you know how something breaks, you also know how to fix it….right?

dem glasses, gabriel gray, heroes, sylar, zachary quinto | Zachary quinto,  Zachary, Sylar heroes

Leave a Reply

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

  +  63  =  70