This blog post will be the fifth in the WinDC Refresh Schedule series. In it, I will zoom into what happens when we run into corrupted Declarative Documents. I will try to explain how the Declared Configuration Service (dcsvc.dll) and the Orchestrator will take care of it!
I will divide this blog into multiple parts. If you already know how the device “checks in” to MMP-C with a 1224 alert, you could skip the first 3 parts. (Or maybe not, as they contain a bit more details than I showed you in earlier blogs)
1. Introduction
As mentioned at the start of this blog post, this blog will zoom into what will happen if somehow our Windows declared configuration (WinDC) / declarative documents go kaboom.
These WinDC documents actually contain some important information about the policies that are configured on your device. For “now”, WinDc ONLY takes care of the EPM policies. I guess we can say, that Windows Declared configuration documents are quite important.
If you have read my last blog (part 4) you will have learned that the Orchestrator AKA the Chef will make sure that those policies are monitored and taken care of. With the power of Declarative device management, the device could fix it on the fly for you. Isn’t that great?
Before we are going to zoom into what happens when those policies are corrupted, let’s do a small recap on how those policies are checked regularly when your device was enrolled into MMP-C
2. The arrival of the documents
Once the device is enrolled with MMP-C, a nice scheduled task on your device will regularly initialize the “sync” with MMP-C. At that point in time an alert 1224 will be sent to the MMP-C service to trigger the whole flow
OMA DM protocol support – Windows Client Management | Microsoft Learn
From there on the existing declared configurations with their state will be handed over to the service, so the service knows what to do with them.
It took me a while to properly understand the state that was mentioned in the declared configurations that were sent over to the service. Luckily while the device checks into the service we can monitor and trace which functions are being called upon.
When the scheduled task is launched, the OMADMClient will be executed but from there on the DCSVC.dll kicks in to generate the session action custom alert
If we open the DCSVC.Dll and just work our way through this “GenerateDeclaredConfigurationAlertXml” we will find out it will lead us to a function called: “GetStateString”
At first, it was hard to understand what was in it when looking at the decompiled GetStateString code (pseudocode)
So I decided to just copy and paste it all to chatgpt and start asking some weird questions and in the end, this was the summary it got me.
Looking back at the declared configuration documents, this actually could be very true. Most of the EPM configuration policies got the state 60 but the Epmagent installer document was somehow failing (for now let me say I was playing around with it….) The failing installation seems to get me a state 81. Everything the device was checking in, it wanted to download and reinstall the EPM client. (I know why… not going to share it….I thought it was pretty funny)
After the “state” has been sent over we will get the declared configuration results back in the response
From there on the device would reach out again to the service, this time not with an “alert” but with a “status” message and the actual status of the WinDC documents
From there on the whole raw/cooked will take place on the device that I mentioned in an earlier blog
https://call4cloud.nl/2023/04/declared-configuration-epm
3. The flow behind the Arrival
Words can be words, so here is a simple mspaint flow showing how I got there
So with the WinDc documents on our device, nothing could go wrong, right? But as mentioned earlier if some things do go south, there is the power of WinDc
4. The Corrupted Declared Configuration Documents
Now we have noticed how those WinDc documents arrive at our device when it checks into the MMP-C infra we now need to take a look at a specific function inside the declared configuration service DLL (dcsvc.dll)
This function: ReconstructQueueAndExecute will make sure that if shit hits the fan, the corrupted declarative documents and all the corresponding orchestrator and declared configuration registry keys are deleted.
While playing around with the schedule to refresh the declared configuration, I accidentally (or maybe on purpose) deleted some of the DeclaredConfiguration registry keys. While waiting a couple of minutes (because I changed some registry keys to speed it up) I noticed something funny.
Somehow besides the registry keys I mentioned, the scheduled task to refresh the declared configurations was gone, where it should be in the root folder
So everything around the Declared Configurations is gone? Almost because we still have schedule 3 to run the Omadmclient that triggers the deviceenroller. This one will be triggered and that task will reach out to the MMP-C service. With the power of the declared configuration service, the scheduled task will reappear on our device and all corresponding declared documents will be brought back to live
So to give a small summary: the ReconstructQueueAndExecute will trash all the existing declared configurations and will prepare the device to be able to fetch the working declared policies from the service. From there on the Omadmclient will kick in to put all the pieces back together. It is fixed without human interaction!
5. The reconstruction flow
Without some nice MSpaint flows, no blog… so here is another one you can chew upon!
6. Part 7.
At first, I wanted to write only 6 parts that would show you the magical world behind declarative device management but while doing some stupid stuff I noticed that somehow, that refresh schedule I was telling you about was suddenly migrated to the enterprise mgt enrollment scheduled task folder that corresponds/is dedicated with MMP-C enrollment
This simple function led me to something called “DriftControl,” which gave me a good idea of where Microsoft is going. Why else is Microsoft moving this task to its own dedicated MMP-C folder and specifying the enrollment? Will Microsoft do the same for the other “Intune” enrollment? Let’s find out in part 7?
Conclusion
I guess all of my latest blogs are of no use to a lot of people right now…. and I assume most of them don’t even know what I am trying to say :). But believe me, this will change next year!
