This blog post will be the first in a nice series about the Windows Declared Configuration Service (WinDC) and the EPMPolicies.
In this series, I will try to explain more about a wonderful “refresh schedule” I noticed in the task scheduler 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!!!!!
1. Introduction
In one of my earlier blogs about what exactly was happening when EPM was activated in our tenant and deployed to our devices, I noticed an additional weird schedule being created on my device
https://call4cloud.nl/2023/04/declared-configuration-epm/
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 7, 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 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.”
Part 1:
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
Part 2:
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!!!)
Part 3:
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 small, but I needed to pull it apart!
Part 4:
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 ensure the policies are applied!
Besides the “manager“, I am also zooming into the declarative part more.
Part 5:
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)
Part 6:
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!
Part 7:
While working on part 6, I realized that I was still not done yet because somehow, the important task of refreshing any policy on the device was suddenly migrated to its corresponding dual enrollment.
So, now that I am finished with all of the blogs… here is the total flow
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 using 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
MMP-C | Declared Configuration | dcsvc.dll | Service (call4cloud.nl)
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 that we have walked through the first part of the flow, let me explain what’s happening. 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, which 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 every 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
After indexing and analyzing the device and user policies, it will try to find out if the actual policies are inside the EPMAgentPoliciesElevationRules registry key.
If the EPM service can’t find those registry keys, it means the device needs to refresh 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 will be reapplied even when they got deleted just by looking at what it got “cached” in the WinDC registry keys!
Conclusion
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 and thank everyone who works on this amazing stuff. You are creating something beautiful, even when it’s not only those people but the whole team behind it!
