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
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?
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!
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.
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
When looking at those registry keys on my device itself and searching for the keywords: policyconsistency, I didn’t find anything useful.
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
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.
As shown above, I created the registry keys myself and restarted the procmon trace again
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?
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?
