This blog post will describe a scenario that I ran into this week. Also, to be honest, I wasn’t aware of this exact behavior and, until this moment, I haven’t been able to find any documentation that describes this behavior.
The scenario is that the customer wants to have the ConfigMgr client deployed on their server environment. This server environment is currently patched by using different methods and one of them is WSUS. So far, nothing weird, but the servers patched by WSUS are configured via local group policies.
I think that by now everybody knows that the ConfigMgr client uses the local group policy Specify intranet Microsoft update service location to point to the WSUS server of the ConfigMgr environment, if, of course, Enable software updates on clients is set to Yes in the client settings. What I didn’t know is the behavior of the ConfigMgr client when Enable software updates on clients is set to No in the client settings. My understanding was that it would simply disable the Software Updates Agent and, if previously configured by the ConfigMgr client, it would remove the local group policy of Specify intranet Microsoft update service location. Sadly, I was wrong, big time! What actually happens is that the ConfigMgr client will always remove all WSUS related local group policies with the first policy that has Enable software updates on clients set to No in the client settings. This is even the case when Enable software updates on clients is set to No in the default client settings.
Basically it’s stating that it’s disabling the Software Updates Agent and deleting a Windows Update policy. At this point I would still assume that the log file is referring to the local group policy Specify intranet Microsoft update service location, but, even if nothing is configured by the ConfigMgr client, it will delete all all WSUS related local group policies. Everything that’s configured in a local group policy located under Computer Configuration\Administrative Templates\Windows Components\Windows Update will be removed. This relates to the registry key’s located under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. Once a policy is applied with Enable software updates on clients set to No in the client settings the ConfigMgr client won’t touch these local group policies (and registry keys) again.
This behavior doesn’t cause any problems when domain group policies are used, because directly after deleting the WSUS related policies it triggers a domain group policy update to restore those settings (see event viewer message).
Funny note: When uninstalling the ConfigMgr client it only removes the Specify intranet Microsoft update service location local group policy. In that case it leaves every other WSUS related local group policy untouched.
Sadly, there is no real solution, as there is no way to prevent the ConfigMgr client from initially removing all WSUS related local group policies. In most situations this won’t be a huge problem. It will only be a problem when there are no domain group policies available, or when domain group policies are not used. The only solutions are actually workarounds. Simply accept this behavior and make sure there is something in place to cover this little gap. Three possible workarounds are:
- Use compliance settings to set the correct registry keys;
- Export the registry keys and deploy them via an old-school package (use regedit);
- Export the local group policy and deploy it via an old-school package (use secedit).