Group Policy blocking SUP

[joeman1881]

Hello all,

 

I have an issue that creeped up on me, and I have been too buried to go back an fix it. Now it's critical so I have been allocated time to fix it......

 

Basically I had my SUP working with weekly update deployments. I then broke these deployments by enabling a GPO that forced users to go to http://sccmserver:8530 for updates. The reason I did this is unless they searched online for updates...it always showed there were no available updates. The error I am seeing from the clients is:

 

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://sccm4:8530 and Policy ENABLED WUAHandler 4/4/2014 8:34:51 AM 9976 (0x26F8)

Failed to Add Update Source for WUAgent of type (2) and id ({4A138D6C-12EE-4BC4-8D74-D5DCFC745EDA}). Error = 0x87d00692. WUAHandler 4/4/2014 8:34:51 AM 9976 (0x26F8)

If anyone has a similar configuration please advise on best practice for configuring this.

Thank you,

-Joe

[Peter van der Woude]

Is the server you point to from the GPO the same as the "real" SUP? If it is, it shouldn't be a problem. The reason why we always advice NOT to use GPO when using ConfigMgr, is because ConfigMgr uses local policies to set the exact same setting(s) and you probably know that a GPO overrules a local policy.

[joeman1881]

Is the server you point to from the GPO the same as the "real" SUP? If it is, it shouldn't be a problem. The reason why we always advice NOT to use GPO when using ConfigMgr, is because ConfigMgr uses local policies to set the exact same setting(s) and you probably know that a GPO overrules a local policy.

 

Thank you for the reply. What I just finished doing is I set a dependency in my gpo saying if the registry file showing config manager is installed is there, then do not point to the SCCM server for WSUS. Otherwise, point there. This seems to be working, however my machines that do have the client say there are no updates available when manually searching from control panel > Windows Update.

 

Is this typical?

[Peter van der Woude]

That's expected behavior if you are using ConfigMgr/SUP for update deployment. You will need an a client to find applicable updates. because ConfigMgr does not approve/reject updates in WSUS.

[joeman1881]

That's expected behavior if you are using ConfigMgr/SUP for update deployment. You will need an a client to find applicable updates. because ConfigMgr does not approve/reject updates in WSUS.

 

This is the same case if I have gone in and manually configured WSUS ADR's as well? Prior to shutting of the GPO for all, I was able to manually hit "check for updates" (not search online) and it would look to my SUP server for updates and install them according. It was just killing my ConfigMgr/SUP deployments because the GPO was in place. I guess it just confuses me that the client can point to SUP in the local policy, but can't point to WSUS itself if configured.

[Peter van der Woude]

The reason is actually pretty simple, because ConfigMgr/SUP just uses WSUS. The ConfigMgr client also uses the WUA client to scan for updates and compliance, so the settings configured by ConfigMgr for software updates on the client are actually just WSUS settings. That means both ConfigMgr policies and GPO are both writing to the same registry keys to write their WSUS information.

 

Hope this makes it better to understand, it did in my head

[joeman1881]

The reason is actually pretty simple, because ConfigMgr/SUP just uses WSUS. The ConfigMgr client also uses the WUA client to scan for updates and compliance, so the settings configured by ConfigMgr for software updates on the client are actually just WSUS settings. That means both ConfigMgr policies and GPO are both writing to the same registry keys to write their WSUS information.

 

Hope this makes it better to understand, it did in my head

 

Yes it does! That is why adding this new GPO via registry with a dependency that the client is not installed works now. Thank you for the reply!