This blog will be the 7th one in the Windows Declared Configuration series (WinDc). In this WinDc series I am focusing on what the “Refresh Schedule created by declared configuration to refresh any setting changed on the device” is doing.
This seventh part of that series will focus on migrating that same Declared Configuration refresh task (MigrateRefreshTask). I will divide this blog into multiple parts.
1. Introduction
When our device is getting enrolled with Endpoint Privilege Management, we will notice that the device will get a LinkedEnrollment. With this Linkedenrollment/dual Enrollment, the device will start communicating with the Declared Configuration Server to receive the Endpoint Privilege Management (EPM) Policies AKA Declared Documents
It communicates with the service by using the Declared Configuration CSP (WinDc / Declared Configuration Service/dcsvc)
Source: Declared configuration protocol – Windows Client Management | Microsoft Learn
If you are interested in my insights, please visit my blog about this enrollment. I just added a new kind of flow I was working on, to get it clearer.
When you have read Microsoft’s article or mine (I will advise mine :)), you will notice that the Declared Configuration Protocol is one of the most important pieces on the device to start talking with this Declared Configuration server.
That’s why I dedicated a lot of blogs to it! In my opinion, the dcsvc.dll (declared configuration service on the device) has a lot of magical stuff in it!
One of the magical things is definitely the “Refresh Schedule created by declared configuration to refresh any setting changed on the device”
This “one piece” is a true treasure! You can compare it with this nice treasure chest.
Once you have opened it with tools like IDA/Procmon/MessageAnalyzer, you will be amazed at what’s inside. At first, I thought this blog series would only have 6 parts, but somehow, while writing, I stumbled upon some more stuff. My advice, start with part 1 before reading this one… but hey, that’s only my advice.
Let me continue the story because suddenly the Uber super duper refresh task was moved to the corresponding Declared Configuration enrollment (I used to call it the mmp-c enrollment. Moving on now…)
In this part of that series, I will be zooming in on how that task Is migrated, and maybe more importantly, I will show you how you could get to know what’s coming just by searching for some keywords.
2. The Refresh Task gone!
While playing around with the declared configuration protocol and trying to break things to get to know it, I noticed that somehow the “refresh task” that was stored in the scheduled task root: Microsoft\Windows\EnterpriseMgmt was gone
At first, I thought I broke the declared configuration again and I needed to sync my device to bring it back to life but after syncing the device that schedule was still missing in action. It didn’t take that long to find it as somehow that schedule was now moved to the declared configuration enrollment task folder.
Huhhh… okay, so Microsoft moved that refresh task to the enrollment corresponding to the declared configuration protocol. Sounds obvious right? Taking a closer look at the “actions” I also noticed something.
As shown above, that schedule is now specifying the enrollment! Almost as if Microsoft is trying to configure a refresh scheduled task per enrollment…. ….. …… Why should they do that?
Almost as if it also needs to refresh some Declared Configurations in a different enrollment. Who knows?
3. Follow the rabbit hole.
So, I decided to start looking around how and why Microsoft decided to migrate that task. To get more details I opened IDA and started searching for “Migrate”.
I guess it’s all in the name! Without looking at it, we can be pretty sure, that function is responsible for Migrating the Refresh Task.
While looking at the flow and how that task is being migrated, I bumped into the “scheduledeclaredconfigurationrefresh” (Yep I switched to start using pseudo code)
Everything happens for a reason! This function led me to the registry key called: “ManagementServiceConfiguration”
This function mentioned “GetDriftControlDword” and NO!! I am not talking about Alligare Drift Control
Guess what Part 8 will be about! Windows Declared Configuration Drift Control! Sounds and smells like fun, right?
While playing around with DriftControl, I also stumbled upon some other registry settings that could be configured in ManagementServiceConfiguration
4. What you could search for
At the Workplace Ninjas, I already mentioned it during the session but if you want to know what new features are coming, you could make sure you have the latest Windows Insider Preview in place.
If you know what DLL files Microsoft their solutions (Windc/Autopilot/Intune) rely on, things can become very easy.
As shown above, every feature Microsoft implements uses KIR (known issue rollback). In all of their code, they are using Feature_WilFeatureTraits to place a “shield” among the code to make it very easy to disable it when needed.
Great!! It’s even more great that it allows me to search for it in the insider preview DLL files and compare them with the older ones I still have on my device. (Every time a new release hits production/testing, I fetch all the important files and place them on my own disk, categorized by build number)
If we do the same with the Declared Configuration service (dcsvc.dll), we could get this. (I removed some parts, as I still want to be alive a bit longer)
As shown above, the DriftControl is indeed pretty new and awesome… Everything happens for a reason! The scheduled task to refresh all policies that was moved to it’s own enrollment led me to DriftControl!
5. The Flow
What we discussed above but now in a flow you are familiar with (if you have read my other stuff)
Conclusion
While working my way through the Declared Configuration DLL file, I stumbled upon many great things. The Refresh Task is absolutely one of them! But…. there are also a lot of other things but those are better left unspoken. 🙂
