Last Updated on September 11, 2023 by rudyooms
This blog will be about some new Intune feature that is in development. This wonderful feature is called “ConfigRefresh”. A small note: We don’t need to mix this new feature up with ConfigLock or the declarative stuff I have been talking about lately. (even when ConfigLock seems to perform the same actions)
I am dividing this blog into multiple parts
1. Introduction
Keeping an eye out for what’s new in Intune development is always a smart thing to do. This time something got my attention.
ConfigRefresh was added to the in-development and is only available for Windows Insiders! It mentions the fact that this feature will let you set a cadence (time frame) for Windows devices to reapply previously received policy settings, WITHOUT requiring devices to check-in to Intune.
At first, I had the stupid idea that this feature was going to make use of the Windows Declared Configuration service. Stupid me as this is of course not the case (Enough reasons… not going to “spoil” them here …)
So what else does it use or abuse? I installed the latest insider preview and started testing but after a couple of minutes I noticed that the Enterprisecsps.dll itself was only holding 1 function to create the node instance of the ConfigRefresh and nothing more
So trying to enable the ConfigRefresh or trying to perform a get on the node will fail with the error status 404
Luckily last weekend I noticed that my Insider Preview Windows VM just got updated to the latest build (25941.1000)
I immediately copied the enterprisecsps.dll to my own device and opened it with IDA. YES!!!! All the functions and related nodes are mentioned in it!
So I guess Dano was right 🙂 … Just a couple of days later the required functions were included in the enterprisecsps.dll
Finally, I can start taking a look at the famous configrefresh!
2. Enable Config Refresh
When looking at the DMClient CSP, we can also enable it with a CSP but that wouldn’t be fun, right? Enabling it with a CSP and syncing the device with Intune will give me a lot of false information and a lot that is not related to ConfigRefresh. So I fired up a PowerShell MTA session in system context and fired off this SyncML message with the send-localmdmrequest command
This time no 404 error but a nice and expected 200 status. Please note that I needed to use “replace” and not add…
While trying to manually enable ConfigRefresh I was also already looking at the code so I knew where to start looking.
When you enable config refresh a new scheduled task named: “schedule created by DM client to refresh settings” will be created inside the Enterprisemgtmtnoncritical scheduled tasks folder.
After clearing out the garbage I noticed the scheduled task being created
Besides this task being created the “ConfigRefresh” registry key in the corresponding enrollment will also be set
After a few seconds, I opened the scheduled tasks and started searching for that specific task. As shown below, there it is! A nice scheduled task.
When taking a closer look at that task, we will notice that it (OF COURSE!!) uses fightclub the device enroller to trigger the /ConfigRefresh with some parameters. /o and the enrollmentguid
If we decide to take a closer look at the “triggers” we will notice that this scheduled task is repeated every 90 minutes
These 90 minutes correspond with the default cadence time from the DMClient CSP Docs
Of course, we can change them from 30-1440 minutes (but you could also just change the scheduled task?)
But of course, that’s not allowed, right? Don’t do that in production! So let’s move on to actually launching that scheduled task to refresh the Intune settings
3. Launching the scheduled refresh task
Before launching the scheduled task, just like first, I wanted to know what to monitor. I opened another IDA session and opened the deviceenroller.exe
As shown above, after searching for the ConfigRefresh part, I stumbled upon a function inside the main one. This function first uses the known issue rollback/KIR (if GetCachedFeatureEnabledState is mentioned, I know there is something brand new being added.. The fun thing is, you can just search for that keyword with IDA)
From there on it imports a function from the PolicyManager called “RefreshAll”. We will notice this by looking at Procmon. First, it will load the policymanager.dll
Besides loading the policymanager.dll we will also notice that it uses the refreshall function. We can do so by just opening the properties of the deviceenroller.exe in Procmon and taking a look at the “stack”
So up we go to the policymanager.dll. When taking a look at the RefreshAll function below, I noticed some things
First, it will try to find all the related policies that are set at the device and user level (GetActiveUserSid) in the Policymanager registry key
So by the looks of it, it only refreshes the policies configured in the PolicyManager registry key…. So for example no Applocker Refresh! The deviceenroller.exe will look up all the providers and the corresponding ADMX settings and will “flag” them all as “dirty”!
After all the policies are flagged as dirty, it will start to search for all the “dirty” policies and will delete all of them!! Yeah ALL of them! I was also amazed but it will first get rid of all existing configured policies (values) even while there is nothing wrong with them
I was expecting it would try to figure out if there is a mismatch between the configured and the applied policies but by the looks of it, it just trashes all of the policies its values and will set them again within a couple of milliseconds!
So after removing the OneDrive policies as shown below, I fired off the scheduled task to refresh all settings, and literally within a second or 2, the policies came back to life!
The funny thing is I also tried it with some security-related settings that are mentioned in the ConfigLock that I mentioned at the start of this blogpost
Secured-core configuration lock – Windows Client Management | Microsoft Learn
Guess what came back after clearing all of the Defender Security Center subkeys? Yeah you guessed correctly
So ConfigRefresh… Smells like ConfigLock to me?
4. The Flow
In this flow I monitored the OneDrive KFMSilentOptin policy to determine the flow and what happens. If you look closely at the timeframe… within a couple of milliseconds everything is refreshed!
Conclusion
It’s just refreshing! I love it! This refresh task isn’t exactly using a desired state config but it does the same thing. It will make sure that the policies are refreshed on the device without contacting Intune!
A small side note: It looks like only policies that live in the policymanager are refreshed and even the security related settings that are also mentioned in the ConfigLock docs!
