Did Microsoft fix the Config Refresh bug with the March update? However, that doesn’t mean it also works. In this blog, I will examine how Config Refresh was still not working even when my device installed the latest Windows 11 build.
1. Introduction
With the Windows 2024-03 March update, Microsoft fixed a nasty config refresh bug that could have caused many problems with future enrollments and certificate renewals.
The fix Microsoft implemented would move the ConfigRefresh registry node to a folder above to make sure it was not conflicting with the MS DM Server registry key that holds the EntDMID /Emmdeviceid (Enterprise Device ID)
With this fix now available in the regular March update, I reprovisioned my Cloud PC to test it again.
After my cloud PC was reprovisioned, I logged in and waited until all policies arrived on the device. While logging in, I opened the Intune portal to check if the Config Refresh CSP was applied successfully.
2. The Issue
The moment I opened the corresponding Config Refresh policy report in Intune, I immediately noticed something terrible. The policy report showed me the same error I had before. The report was showing me the 2016281112 and 0x87d1fde8 errors
Those errors are telling me nothing useful, only that remediation has failed. Well, that’s nice! From there on I logged in to the cloud PC and started looking at the device management enterprise event log
This event log mentions the error code 0x86000002. If we look up this error in the cfgmgr2.err.h file, we will get to the conclusion that, somehow, the specified node doesn’t exist. Cfmgr_E_NODENOTFOUND
Error code 86000002 can occur when a device is expected to receive an Intune policy but the CSP (Configuration Service Provider) node (ConfigRefresh) necessary for this operation is missing, specifically under the URI path ./Device/Vendor/MSFT/DMClient/Provider/MS DM Server/. The CSP DM tree, or Configuration Service Provider Device Management tree, is a hierarchical structure representing device settings and configurations.
This is pretty weird, I would say, because the enterprisecsps.dll holds all the information needed to create the config refresh node in the DM CSP tree in the first place.
To be sure I wasn’t going crazy, I tried to do the same as I did in the first blog about Config Refresh I wrote
As shown above, sending a localdmdm request to the ./Device/Vendor/MSFT/DMClient/Provider/MS DM Server/ConfigRefresh node resulted in the same 404 error I had previously received.
It seems that looking at the event logs will not help me. To find out what was happening, I opened the IDA tool and the enterprisecsps.dll file, which is responsible for all of this.
3. IDA and Enterprisecsps.dll
Inside the Enterprisecsps.dll, we will find different operations, such as Add, Get, and Set, corresponding to the config refresh node.
In the localmdm example in the previous part, I was trying to “get” the ConfigRefresh Node information. When decompiling the code to something more readable, this is what it tells me:
The function begins by checking if the Config Refresh feature is enabled. If this check fails (wil::details::FeatureImpl<__WilFeatureTraits_Feature_Servicing_ConfigRefresh>::__private_IsEnabled returns false), the function immediately returns the error code 2248146946. This indicates that the feature required for ConfigRefresh is not enabled, leading to the failure. This failed with the error number: 2248146946 corresponds to the 0x86000002, which sounds more familiar.
If we look at the other operations, such as set and add, we will spot the exact kind of requirements. Each time such an operation needs to occur, the code checks if the config refresh feature is enabled. (Servicing_ConfigRefresh_IsEnabled)
The code will determine if the config refresh feature is enabled and will report the status to the service.
When I noticed the feature ID, 46551074, I started questioning myself. Why? Because this config refresh feature has a different ID in the insider preview.
To be sure, I opened the enterprisecsps.dll from the insider canary preview and opened the same function. As shown below, this working dll version shows me the same feature ID.
Well, that’s weird, so I downloaded the Vive tool to enable the feature to discover what would happen.
4. The Vive Fix
It certainly looks like the config refresh feature was not enabled, and the config refresh DM node wasn’t created because it was not enabled. I downloaded the Vive tool and manually enabled the 46551074 feature, as shown below
By enabling this feature in the Vive tool, the correct ID in the feature management registry node will be created and enabled
After a feature has been enabled with the Vive tool, you must reboot the device before it will kick in. I rebooted the device, and after it was back online, I performed the same steps with the localmdm powershell module
As shown above, the config refresh node will be added to the CSP tree after enabling the feature. Once the config refresh node has been added, the omadmclient can configure and enable the settings.
Well, that was pretty cool, right? But that started me wondering…. Shouldn’t it be possible to bypass this feature requirement and “add” the node ourselves?
5. Manually creating the Node
After reading and learning more, I opened the dmclient DDF file to get the details. As shown below, when we want to add the configrefresh node, we need to ensure we will use “add” (well that’s obvious). Besides the add operation, we need to make sure we are going to use the format: “Node”
That sounds easy, right? I changed a couple of lines in the localmdm request to make sure the config refresh node would be added.
As shown above, after pushing the request, I received a 200 response. Well, that looks good! Without having to reboot the device, the ConfigRefresh CSP node was created! With the node created, I synced the device with Intune to ensure it would receive the Config Refresh settings once more.
Once the sync was finished, I immediately noticed the config refresh settings being applied to the device
6. KB5037853
If you don’t want to do experimental stuff on your device (which I pretty much understand), you need to install the latest May security update: KB5037853 to enable Config Refresh.
Once you have installed this update and rebooted the device, you will notice that Config Refresh is Enabled without you needing to do weird stuff on your device.
Once it is enabled, you will also notice that Intune is finally reporting the status of the settings as Succeeded!
Conclusion:
The funny thing is that after noticing this issue, I decided to be the happy family guy and go out with the family. While enjoying the sun and the time off with the kids (and some beer), my brain didn’t stop thinking; the above steps were the results.
It’s quite cool that you could create the CSP Node yourself and skip the MS requirements.
I wonder if it was scheduled for 22621.3235 but pulled at the last minute? the CSP metadata was updated recently https://github.com/MicrosoftDocs/windows-itpro-docs/commit/5a0a5d22adb641320b3bc060246c4d1be067a353#diff-254b7eb1497068cc59d921d6d4eb26be1314fd2f199b728c1e141c3d7385aec3R635
I am getting the exact same issue trying to enable ConfigRefresh and ConfigLock feature, Win11 23H2 fully patched. Your findings are interesting, it seems that these settings are not ready for the enterprise yet, one would not want to hack away at the registry like that on a large fleet of computers, this should just work out of the box.
The bigger question is, why is the config refresh feature not enabled and the config refresh DM node created when the CSP settings are pushed to the device?