WSUS is an underlying Prerequisite Service that needs to be in place before you can set up and configure the SCCM role that is called Software Updates.

As mentioned earlier the Software Updates role will also do all the setup and configuration of the WSUS. That said, there are some further steps you need to take care of within the WSUS Console as well as the Active Directory Group Policy Management Console.

There has been, and still is, confusion around whether or not you need a Group Policy setting and Windows Update settings for the clients, since there are different opinions and experiences on this.

Why should I need a policy when the SCCM client is setting it for me? Wouldn't that be the easiest way to go?

Yes, the easiest, but not the safest way.

Well, as long as you have SCCM client agent installed and the Software Update Point (SUP) role working well, it's all good.

However, I would advise you to establish a Group Policy forcing the Windows Update settings for all your clients. By having this in place you have full control, and the clients are forced to that specific Software Update Point (WSUS) so that the Windows Update engine is able to update from the WSUS; or even more importantly so that all your clients do not download all available updates if for whatever reason there is no working SCCM client; or if the Software Update Point role is to be removed during troubleshooting for some reason. I have seen this happen: The Software Update Point role was uninstalled, and suddenly all the clients downloaded and installed the latest Internet Explorer. Not great fun, if your business it not yet ready for this.

A disadvantage of this scenario is that roaming clients traveling between different locations might not be utilize Windows Update scanning towards WSUS in the most efficient way at all times. However, this will most likely be a minor issue, and will result in slightly more network traffic between the locations.

This will of course depend on your SCCM hierarchy and structure, and might not be a topic to worry about at all if you have perhaps only one Software Update Point (WSUS) role in your hierarchy.

A client will still download updates from update packages from SCCM based on the Boundary settings you have. Another tip regarding Boundary settings: use the IP Range only to avoid the super netting issue. If you have several clients it will hit the SQL Database Server more and increase CPU usage.

Another aspect is that, if you are utilizing the SCCM client installation method, which pushes the client though WSUS to the client machines, wouldn't that be another reason to have a Group Policy defining your Software Update Point (WSUS)?

So this is the Group Policy setting you need to link to your SCCM clients Organization Unit (OU) in Active Directory.

Group Policy Management

In the object I have created called SCCM WSUS I chose to disable User configuration settings because this speeds up the Group Policy processing as I have no need to configure any user-based policy settings regarding this.

When you open the policy object there are two settings that you have to define in PoliciesAdministrator TemplatesWindows ComponentsWindows Update:

Different settings within Windows Update GPO

The following screenshot shows you the first setting you need to configure for Automatic Updates.

Configuring for Automatic Updates

You just need to Enable it and SCCM will do the rest.

Updates deployed through SCCM will have their own schedule setting working together with the SCCM client agent settings.

Define the Software Update Point

The preceding screenshot shows you the setting where you define the SUP server that the clients will be attached to. In the address on the preceding screenshot, you change the address to fit your environment. Replace supserver with your servername, as well as port 8530 if that should be different.

If you are using System Center Update Publisher to deploy updates from third parties such as Adobe, Dell, or HP, among other possible vendors, there is one more setting you should define in this policy.

The setting is to Enable Allow Intranet Updates.

This allows locally signed updates, published through WSUS, to be downloaded from Windows clients.

Enable setting for Allowing Intranet Microsoft Updates

You need to ensure that WSUS/SCCM is able to download updates through your proxy or Firewall, especially if you have content filtering, which many Firewalls and organizations have.

I have seen it working well and then, after a period of time, the Firewall gets new improved features that suddenly stop the downloading process of definitions.

You need to make an exception rule so that this doesn't happen.

The PatchDownloader.log file will not give you much, but it will give an error message as shown following:

Basically this means something is interfering with the download phase. Have a look at this link to find what addresses you need exception rules for:

https://technet.microsoft.com/en-us/library/bb693717.aspx