Update scan failed due to Group policy settings were overwritten by a higher authority

Few years ago, I have blogged about the client update scan failure due to GPO’s. https://eskonr.com/2014/10/sccm-configmgr-2012-software-update-scan-error-group-policy-settings-were-overwritten-by-a-higher-authority-error-code-0x87d00692/

Introduction:

When the software update point is configured for a site, client computers receive a machine policy that provides the active software update point server name (WSUS) and configures the Specify intranet Microsoft update service location local policy on the client device.

The windows update agent retrieves the server name (WSUS) specified in the Set the intranet update service for detecting updates setting, and then connects to this server when it scans for software updates compliance.

Problem:

I was working on an issue to troubleshoot the server clients where the software update scan is failing. I have noticed that, it is failing on majority of the servers but not on workstations.

For a client to receive the software updates from SCCM, it must first complete a software update scan successfully.

Software update scan details are tracked in the wuahandler.log located in C:\windows\ccm\logs (client location).

Unable to read existing WUA resultant policy. Error = 0x80070002.

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server  and Policy NOT CONFIGURED

Failed to Add Update Source for WUAgent of type (2) and id ({B9DB41D0-CCA2-4FC4-BC70-5EC97B1FC1A2}). Error = 0x87d00692.

image

Based on the error, the first check is to review the GPO’s that are applied to the device with the help of RSOP.MSC( run as administrator) and gpresult on the local machine.

From the RSOP.MSC and gpresults, i could only see the following setting for windows update section which do not conflict with GPO. since these are servers, prefer to disable automatic updates (windows side).

image

The next is to look at the local group policy (gpedit.msc) to see if SCCM client has set the ‘Set the intranet update service for detecting updates ‘ with the WSUS entries.

I can see there are 2 settings configured by the client correctly. These are coming from the device client settings.

image

Next is to look at the registry if any entries listed for windows update at location Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

There are no entries found in the registry location for WUServer.

I have also reviewed the registry.pol (c:\windows\system32\grouppolicy\machine\registry.pol), it has the WSUS entries updated correctly.

The next location is event viewer for GPO entries, I could not find any errors or warnings there too.

During the course of investigation, it happened to see the GPO which is applied to the client ‘Turn off Local Group Policy Objects processing’

If you enable this policy, the client or the system does not process and apply any Local GPOs.

image

The fix:

Thee GPO policy must be set to either not configured or disabled. Once the configuration is changed, the local GPO that was configured by the client for WSUS will be picked by the client and complete the update scan.

Is there any workaround without making the changes to the GPO?

The SCCM client already applied the local GPO with WSUS server name and port number however it is not up for processing due to the GPO block.

I could not find any other methods to get the update scan work without modifying the ‘Turn off Local Group Policy Objects processing’ setting.

Temporary solution: We can have this policy one time off at the OU level, let the client process the local GPO and once this is done, you can revert the GPO and it should be ok as long as the client is not reinstalled. Any new servers that is onboarded and install the client, it will have the same issue again.

Hope this helps!

Continue reading

Troubleshoot software update management in Configuration Manager

Troubleshoot software update scan failures in Configuration Manager

Leave a Reply