This blog post will be the second one in my journey to discover 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 ensure 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.
1. How it began
When recapping the previous blog post, we learned that the PolicyConsistencyEnsurerJob triggers the refresh schedule created by Declared Configuration to refresh any settings changed on the device.
This “refresh job” will ensure that the EPM policies are reapplied when they are removed. Does this Declared Configuration refresh seem to be triggered every 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, somehow it tried to refresh it a maximum of 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 I took a closer look at the “get” part, I noticed that those numbers should be configured in minutes. I decided to look further and try 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
I didn’t find anything useful when looking at those registry keys on my device itself and searching for the keywords policy consistency.
But I am not easily fooled, so 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 created the settings registry key, started the Procmon trace, and restarted the EPM service again. The same thing happened! But this time, it didn’t mention that it was missing the “settings” registry key!! No, it mentioned it was trying to find the corresponding jobs by their 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 that it was a success! That was fun!! So I again removed the EPM policies, and this time, I just waited. Instead of 15 minutes, does it try to refresh the policy every 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 is told 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 of 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 Microsoft will not support it 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?
