Last Updated on August 26, 2023 by rudyooms
This blog post will be the first one in a nice blog post series about WinDC and the EPMPolicies.
In this series, I will try to explain more about a wonderful “refresh schedule” I noticed in the task scheduler, that arrived after EPM was deployed. This first blog post will focus on how this scheduled task is being used by EPM (Endpoint Privilege Management) to refresh the WinDC Policies…even when the device is OFFLINE!!!!!
I will divide this blog into multiple parts
In one of my earlier blogs about what was exactly happening when EPM was activated in our tenant and deployed to our devices, I noticed an additional weird schedule being created on my device
In this blog above, I noticed the “Refresh Schedule created by declared configuration to refresh any setting changed on the device” but at that point in time I couldn’t find anything related to it but now I do!
So let’s start with me talking about the complete flow first and from there on I will explain what I noticed
2. The Complete Flow
As mentioned at the beginning of this blog post, this will be the first part of 6 what’s going on with the WinDC (declared configurations) and EPM (Endpoint Privilege Management)
When spending time figuring out what this task exactly does and why I got myself stuck in the biggest maze I have ever seen. Let me shortly tell you what I noticed and from there we will zoom in on each part a little bit more (or maybe a lot more).
Please Note: I will add the links to the blog posts once they are “live”
This part will show you which “process” executes the “Refresh Schedule created by declared configuration to refresh any setting changed on the device” To make it even funnier, it works even when being offline! So no MMP-C check-in or sync was performed.
If you haven’t heard of the wonderful MMP-C, make sure you read this blog first
The Second part will focus on how this “process” is being scheduled in the background and how this “job” looks for specific registry settings to determine the proper schedule (even when those registry settings aren’t there!!!)
The third part will be zooming into a specific function I couldn’t explain before but stumbling through the internet and looking at some MS Docs (yeah apparently it already was documented in 2020!!)This blogpost will be a small one but I needed to pull it apart!
Besides the Declared Configurations (dcsvc.dll) that arrived on the device with a late 2022 Windows update, I also noticed the “manager” arriving on the device to orchestrate the processing of the policies when the EPM policies were delivered. Guess what it’s called? DBManager / MSOrchestrator. The fourth part will be about the one that does all the heavy lifting to make sure the policies are applied!
Besides the “manager”, I am also zooming into the declarative part a bit more.
In part 4, we learned about the orchestrator, in this part I will zoom in, on why the “Refresh Schedule created by declared configuration to refresh any setting changed on the device” schedule is sometimes missing on the device and how to repair it! (They told me not to mess with anything… so I did NOT)
When spending time on the Orchestrator and looping through all the code, I noticed some funny named functions. GET –> TEST –> SET. Sounds a lot like Desired State Config (DSC)? And yeah this part refers back to the MSDoc I mentioned in part 4, so stick with me and read all the blogposts!
3. The Refresh Schedule overview
As mentioned in the complete flow, this part will focus on how a wonderful Enterprise MGT scheduled task is being used by the EPMService to make sure all the EPM policies that are delivered from the MMP-C platform are refreshed on the device occasionally.
These policies are delivered from the MMP-C Platform with the use of the Declared Configuration Service. So the WinDC, plays a huge role in it!
In the picture above, I called it DC but looking at the code and logs, I guess I need to change it to WinDC.
If you want to read more about my first experiences with the WinDC, please read this blog
Let’s start with the overview of what’s happening and how the “refresh schedule” is triggered! Of course, like always, you can click on it to download the BMP version, so you can zoom in a bit!
4. The explanation
So now we have walked down through the first part of the flow, let me explain what’s happening. When looking at the beginning of the flow, you may have noticed that I decided to make sure my EPM enrolled device is Offline.
After my device was offline, I removed the EPM policies from the device by clearing the ElevationRules and the RuleLookup EPMAgent registry keys. To be sure, I also deleted the policy from the device itself and tried to run PowerShell in an elevated session (which was approved in the policy)
That one got me the famous 0x80070005 (access denied) error mentioning that I am not allowed. From there on I just let my device be and enabled all the tracing I thought I needed (Message Analyzer tool and selecting the Device management event log, Procmon)
From there on I noticed that within 15 minutes the EPM Elevation policy was back and I could start PowerShell elevated again. I started by looking at the EPMServiceJobs log. This log mentioned that some jobs were added to the serial job scheduler.
One of them was called: PolicyConsistencyEnsurerJob. Remember that name!!
With this name tattoed in my head, I opened the EPMService log and I noticed that the moment the policies are refreshed (duh it’s in the name) it starts with that same PolicyConsistencyEnsurerJob
This PolicyConsistencyEnsurerJob seems to be executed each 15 minutes but more on that in part 2 of the blog!
When taking a closer look at the EPMservice log, we notice some funny things. First, it tells us it can’t find the MDM/MMPC server instance… MMP-C that’s a word that we heard before, right? MMP-C as in Intune version 2? (at least in my opinion…maybe you share the same after reading all parts)
From there on, we will notice that the EPMService, checks the amount of WinDC (declared configurations) device policies. As we can notice in the registry, we have indeed 4 EPM device policies
- A DC policy referring to the download URL of the EPM agent msi
- A DC policy referring to the EPM policy settings (not the elevation rules but the default behavior rule)
- A DC policy referring to the EPM policy settings (not the elevation rules but the telemetry settings)
- A DC policy referring to the installation results of the EPM agent msi
With the device policies analyzed we also need to do the same for the user policies. First, it finds the proper user and the corresponding WinDC policies. Guess what those 2 EPM user policies contain?
- A DC Policy refers to the processes that are allowed with an EPM Elevation Rule
- A DC policy referring to the EPM default action that needed to be performed
With the device and user policy indexed and analyzed it will try to find if the actual policies are inside the EPMAgent\Policies\ElevationRules registry key.
If the EPMservice couldn’t find those registry keys, it means the device needs to have a refresh of the WinDC policies. To do so it triggers the scheduled task we were looking for and with it, the EPM policies are refreshed! Even on an offline device.
I guess we can presume that the PolicyConsistencyEnsurerJob will make sure the policies are going to be reapplied even when they got deleted just by looking at what it got “cached” in the WinDC registry keys!
5. What’s coming
So we have learned that the PolicyConsistencyEnsurerJob will refresh the EPM policies on the device (I assume there will be more policies that need some refreshing in the future… ) In the next blog post I will focus on those 15 minutes and the 5 retries it does to repair the broken WinDc Policies
Let me give you a small heads up, so you really want to read the next part: RegistrySettings….
When looking at the complete picture that I am going to describe in this blog post series, I am so deeply amazed by it all.
I want to name/thank “mvm” for this amazing stuff. Even when it’s not only those people but the whole team behind it, you are creating something beautiful!