Local Group Policies for WSUS and the Software Update Agent of ConfigMgr 2012

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.

Scenario

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.

Behavior

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.

At the moment that the first policy arrives at the client with Enable software updates on clients set to No in the client settings the following information will show in the ScanAgent.log. LogFile_ScanAgent

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.

EventViewer_GPOThis 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.

Solution

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:

  1. Use compliance settings to set the correct registry keys;
  2. Export the registry keys and deploy them via an old-school package (use regedit);
  3. Export the local group policy and deploy it via an old-school package (use secedit).

5 thoughts on “Local Group Policies for WSUS and the Software Update Agent of ConfigMgr 2012”

  1. Hi Peter,
    Thanks for the tip.
    We ran into a situation where clients in a remote office in US were crossing over WAN to scan against SUP there.
    This caused network spike so we provisioned local sup hoping if we force clients to “switch to next SUP” they will find local SUP and bind to it.
    But it seems unless we completely shut down other Primary SUP’s in europe completely for more than 2 hours(which we cannot afford) these clients will not loose affinity to the SUP they have successfully against in past.

    Next up was to apply a Domain Group Policy with LocalSUP in URL location and set client setting to NO for Software updates.
    We hoped that client setting will clear the keys which will then be filled by group policy to point to local sup.

    When we dont have client setting set to NO for software updates and domain policy tries to overwrite local group policy on client we keep getting following error in WUAHandler.log

    Its a WSUS Update Source type ({CA3250B6-B93F-4244-A37F-073DBAFF9FD3}), adding it. WUAHandler 30.06.2019 04:33:25 3796 (0x0ED4)
    Enabling WUA Managed server policy to use server: WUAHandler 30.06.2019 04:33:25 3796 (0x0ED4)
    Waiting for 2 mins for Group Policy to notify of WUA policy change… WUAHandler 30.06.2019 04:33:25 3796 (0x0ED4)
    Group policy settings were overwritten by a higher authority (Domain Controller) to: Server and Policy ENABLED WUAHandler 30.06.2019 04:33:41 3796 (0x0ED4)
    Failed to Add Update Source for WUAgent of type (2) and id ({CA3250B6-B93F-4244-A37F-073DBAFF9FD3}). Error = 0x87d00692. WUAHandler 30.06.2019 04:33:41 3796 (0x0ED4)

    Reply
  2. Hi Peter,
    We eventually removed the GPO and everything is back to how it was.
    Out of around 2k clients in US only 300 scan against local SUP and rest cross over WAN to scan against two primary SUP’s in Europe. Network team records daily spikes for around 10-20 minutes in which around 4-5 GB data is consumed by these clients from these remote SUP’s.
    If these clients were just scanning for metadata we should not have such huge traffic considering we do have a local DP at US site on the SUP.
    Reading through technet forums i came across this but we are already using shared database among two SUP’s

    https://social.technet.microsoft.com/Forums/en-US/f1145388-cb1e-45d9-8cef-0607b36803ca/wsus-servers-generating-a-lot-of-traffic-and-hitting-network-line?forum=configmanagersecurity

    “Also, since you have two SUPs, are they using a shared database? If not, every time a client switches between SUPs it will trigger a full catalog synchronization instead of the usual delta if using the same WSUS database.”

    Do you think is there any other way to force these clients to scan against local SUP apart from shutting down
    primary SUP’s for few hours hoping fallback works eventually and local sup is found by these clients.

    Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.