There have been bugs with this process since 2007 was launched – specifically around clients within a secondary site’s scope using the WSUS instance from the primary site’s SUP and not the one within the secondary site. Thus, it’s possible you are hitting one of these bugs that hasn’t been stomped out yet.
What happens if you uninstall the client and reinstall it on a test system already located within the scope of the secondary site? Ultimately, you may need to open a support case on this to truly get any sort of resolution. J From: [email protected] [mailto:[email protected]] On Behalf Of George Salmaniw Sent: Thursday, February 4, 2016 8:59 AM To: [email protected] Subject: Re: [mssms] WSUS integration and strange client behaviour Thanks for the feedback Jason. Appreciate the knowledge and experience you bring to this forum. These are secondary sites with the SUP role installed. Each secondary site is a downstream server from the primary upstream server. Some other bits of information. We image our PCs at a central location that scans from the upstream server, as it is within it's boundary. The PCs are then shipped to different areas of our company, where the downstream servers are located. As SCCM updates the local GPO WSUS location, is it possible that this information is kept within an SCCM table, or exists within the existing SCCM client WMI? I have witnessed the upstream server WSUSpool restarting, and almost instantaneously I see SCCM clients re-homing to the upstream server. The only way I can see this occurring is that this information is embedded within the client WMI. George On Wed, Feb 3, 2016 at 7:25 PM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: I can’t explain all of the behavior that you are seeing, but ConfigMgr clients will never pull content from WSUS. The WUA is perfectly capable of doing this though if (and only if) the updates are approved in WSUS directly (which you should never do). This is one reason (of multiple) to disable automatic updates on your clients via GPO. When you say secondary sites, do you truly mean secondary site or are you talking about an alternate, possibly remote, location? J From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of George Salmaniw Sent: Wednesday, February 3, 2016 6:37 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] WSUS integration and strange client behaviour Bump anyone? Extremely strange behaviour. I have had the WSUSPOOL stopped on our upstream WSUS server to prevent SCCM clients from directly connecting to this server. However, once I restart the Application Pool in IIS, within 2hrs I have over 400 [out of 10k clients] redirecting themselves almost immediately from the downstream to the upstream server. This cannot be policy-driven, as most likely the policies have yet to run. Is there a potential that a setting exists within the registry to include the fallback WSUS, which for some reason, is pointing to the upstream server? George On Tue, Jan 26, 2016 at 2:47 PM, George Salmaniw <[email protected]<mailto:[email protected]>> wrote: SCCM 2012R2 CU2 Single Primary with multiple secondaries Single upstream WSUS/SUS server at the Primary Multiple downstream SUS servers at the secondaries Noticing over time that clients at secondary sites are slowly repointing to the upstream server, and causing bandwidth issues as it's pulling update scan metadata from this WSUS. It also seems that it may be pulling updates directly from the WSUS server itself and not from the SUP and not from the DP. Does anyone know how to repoint the SCCM clients back to their local SUP and not failover to the upstream server? What I have done in the past is stop the WSUSPOOL on the upstream server. This will result in the SCCM client timing out and reverted back to the local WSUS. But once I restart the WSUSPOOL, SCCM clients start to slowly repoint to the upstream server. Really frustrating. Also why would an SCCM client pull directly from a SUP [WSUS] and not from the DP? The only thing I believe I can do is use SCCM to update the registry settings based on boundary collections to ensure that it doesn't change the settings. I'm loath to use GPOs as we may inadvertently repoint a client that is no longer located in the appropriate location OU. Ideas anyone? George
