WSUS

Configuring WSUS with SCCM Current Branch (Server 2016) – Part III

 

Introduction

In Part I I took you through configuring the required Server Roles & Features, WSUS Installation and Configuration, IIS settings, Folder Permissions and linking it all up into SCCM.

In Part II we went through in-depth how to deploy updates and properly manage the future with ADRs, whilst catering for the past with Baselines.

Finally, here in Part III, I’ll cover Client Settings, Maintenance Windows, Group Policy, Multiple SUP’s, HTTPS, ADR\Baseline Maintenance, and the big scary WSUS Maintenance.

This Part III is really to cover off the little nitty gritty bits that just don’t fit elsewhere.

I’ll likely add to this as time goes on..

 

Client Settings

You must configure the SCCM Client Settings for Software Updates to take effect on clients.

For ease of show and tell, I’m going to make a new Client Setting policy, but you can add it into your current ones where appropriate.

Administration>Client Settings>Create Custom Client Device Settings

Tick Software Updates

vmrc_2018-03-20_16-38-25

Ensure you set “Enable Software Updates on Clients” to Yes

vmrc_2018-03-20_16-40-24

Highlighted above are the settings I’ve changed.

I’ve enabled Software Updates, and I’ve enabled it to automatically install any other software update deployment that’s due at the time within 1 hour.

We also have a couple other settings here:

vmrc_2018-03-20_16-42-45

These defaults mean that the receiving clients will scan for new Software Updates every 7 days (randomised  on clients).

Depending on your companies polices, that might be a little too relaxed taking into account that could mean it’ll take some clients up to 7 days to install the Doomsday4000 patch after you’ve deployed it.

So consider making that a little more regular, every 1-2 hours, I think is as short as you’d want to go.

Once finished, deploy the client settings to your clients.

Keep in mind here, you could have numerous Client Setting policies with different schedules and configurations deployed to numerous different collections.

vmrc_2018-03-20_16-50-03

Group Policy

A lot has changed with the last few versions of Windows 10, and the goal posts keep moving.  However thankfully, there are some pretty good documents which tell us where to.

Before you step into changing anything with Windows Update related Group Policies, you need to understand, the sometimes not so obvious side effects, and to do that, you have some homework, firstly starting off with how things use to be..

Firstly, read this.

Now this one.

Finally, this one.

Now, go and read them all again!  That should set you up to be in a good place where I don’t need to cover anything else off, and all questions on Dual Scan answered.

So, moving on..

Now what I will cover is where time and time again conflicting information and advice is given.

So, let’s talk about this policy:

vmrc_2018-03-20_16-54-30.png

This group policy is here for a very simple purpose, tell X machine to talk to Y server for Windows Updates.

However, in the previous section, we configured Client Settings to tell our clients to use SCCM for Software Updates.

So what’s going on?

Group Policy is Group Policy.  It Wins.

Client Settings are Local Policy.  It Loses.

If you have this group policy set to UpdateServerA, but your SCCM WSUS Server is UpdateServerB, then the client, regardless of how hard SCCM tries, will never get it updates from SCCM.

If you have this group policy set to Not Configured, then SCCM can successfully set it at local policy level, and everything will work great.

So I should just not set the Group Policy then?

Kind of.

And honestly, this is where my opinion differs from most others.

If your environment is numerous SUP’s deep and complexity of OU structures all over the place, then yes, leave it Not Configured and just let SCCM do its job.

If however, like I know the majority of you reading this actually have, is just a single SUP, well then actually my advice is to set the Group Policy.

Why?

Can you wholeheartedly tell me not a single one of your users is local administrator?

Now tell me the truth!

Client Settings are Local Policy.  Local Policy can easily be overridden.  So if you’ve got a simple setup of OU’s and a single SUP, then why wouldn’t you enforce the server from the top?

And this is the common misconception.  That if this group policy is set, then SCCM Windows Updates won’t work at all.

Wrong

This policy simply has to be set exactly to the SUP.  Port number and all.

vmrc_2018-03-20_17-07-38
HTTP://FQDN:PORT – or – HTTPS://FQDN:PORT

 

So, just to summarise what I’m saying here..

If you have a single SUP with simple OU structure, set the Intranet Update Location in GP.

If you have multiple SUP’s, great OU structure and want to lock things down, set the Intranet Update Location in GP (where different policies have different SUP’s based on location\boundaries).

If you have multiple SUP’s, complex OU structure, mass machine moving between sites\boundaries, multiple SUP’s in single boundaries or just really want an easy life, then do not set the Intranet Update Location in GP.

The above advice is given assuming you are not setting any “deferral” policies belonging to Windows Update for Business which would in turn trigger Dual Scan.

Also, as an aside tangent, if you set the GP, then you can utilise this underutilised awesome method of client delivery for scenarios Client Push lets you down..

chrome_2018-03-20_17-16-15

 

Maintenance Windows

This one’s simple enough, have some machines you want to ensure don’t install updates during the day?  Or only every Tuesday morning etc..

Find a suitable Device Collection which contains the clients you want to define.

Select Properties>Maintenance Windows

vmrc_2018-03-20_17-20-37

Define a Maintenance Window, ensuring you select Software Updates.

vmrc_2018-03-20_17-21-26

If you wish, you can go again and create numerous Maintenance Windows per collection.

vmrc_2018-03-20_17-21-40

Now, Windows Updates will only install during these time windows.

But, but Rich!  Doomsday4000 has happened and we need to roll out its patch now!! It can’t wait till my Maintenance Window next February!

Well, it’s a good thing the ConfigMgr team saw this situation coming.. if you need to, and only when you need to, tick the below boxes on your update deployments:

vmrc_2018-03-20_17-25-59

HTTPS / PKI

Peter van der Woude has a great and still valid guide on this one, so head over there for this part!

https://www.petervanderwoude.nl/post/how-to-configure-a-software-update-point-to-use-ssl-for-communicating-with-wsus/

Multiple Software Update Points

This is easier then you may think and you may wish to consider it for the case of fallback, multiple sites with varying network speed, or perhaps just client numbers are over the recommended per SUP.

You really have two options, split them up and have them all working independently, which is usually a bad idea, or join them all up into 1 happy family.

Again, there’s no point me going over already laid ground, so, see the below!

https://blogs.technet.microsoft.com/configurationmgr/2016/10/12/how-to-implement-a-shared-susdb-for-configuration-manager-software-update-points/

Baseline \ ADR Maintenance

It’s been a little while since I wrote Part II, and if you followed along at the time, you’ll potentially have up to 8 month’s worth of ADR’s currently in production, all with their individual deployments.

Now, whilst this is absolutely fine, and there are literally no real downsides, you as the good tidy ever improving SCCM admin may want a spring clean.

So what do you do?

Well, the answer is actually very simple.  You simply recreate the Baselines, and remove the old ADR Software Update Groups and old Baselines.

By doing this, you’re giving everything a refresh.  Only the new currently still valid updates will go into your Baselines, and you can ditch off all the old groups.

There’s no set ‘do this every x months’ as it’s your prerogative, but every 6 months or so sounds reasonable enough to me.

Simple huh?

WSUS Maintenance

Do it.

Do it Regularly.

Automate it.

It’s often the case that WSUS starts performing horrendously, hogging all the CPU and Memory, and generally making a nuisance of itself.  This is almost always because no maintenance has been performed on the database.

I thoroughly recommend you read through, and preferably manually follow the steps the first time in the below article to get an idea of what’s going on.  Then, again as per the article, automate it so it does it for you.

https://blogs.technet.microsoft.com/configurationmgr/2016/10/12/how-to-implement-a-shared-susdb-for-configuration-manager-software-update-points/

There will however, always be cases where for whatever the reason, the WSUS server has fallen off it wagon and regardless of your efforts, it just won’t go back on.

At this point, you have to ask yourself, what are you losing by blowing it away, and just starting again..

Conclusion

I really hope this three part series has helped you in getting SCCM WSUS up and running, and has lifted the lid on its complexities.

I’d love to hear how you’ve gotten on, so leave a comment below!

Rich Mawdsley

15 thoughts on “Configuring WSUS with SCCM Current Branch (Server 2016) – Part III

    1. No, after the initial setup you shouldn’t ever touch WSUS directly (except for maintenance where advised).. WSUS is all the backbones and SCCM with SUP role sits on top and makes it all pretty and easy to manage. SCCM will handle everything for you.

      Like

  1. If you suppress the restart on the workstations and you have maintenance windows setup to install lets say overnight will the maintenance windows still restart the computer during maintenance so the end user does not have to manually restart their computer to apply those updates? or should I just leave suppress restarts uncheck for both servers and workstations? Also, how will these maintenance windows work with sleeping laptops that are left plugged in overnight? Thank you for such an amazing way of explaining all of this.

    Like

    1. If you suppress restarts, then they are exactly that, regardless of maintenance windows. So you would be relying on users or other external methods for those restarts.

      Same really goes for sleeping laptops, or even just desktops that are switched off every night.. If the machine isn’t up and running during the MW, then updates wait till the next MW.

      You can configure settings like override MW etc on manual deoloyments for say an emergency patch, but it would obviously defeat the purpose on an ADR.

      Rich Mawdsley

      Like

  2. Hi Rich, thank you for your thorough guidelines.
    I followed your steps and it’s all good up until one day when I noticed that the folders created by the ADR located in the SCCMDeploymentPackages folder have all been removed. Any idea what might cause this behavior?
    Even the folder for the baseline it’s gone as well.

    Cheers.

    Like

  3. Any idea why my clients would not get the WSUS settings from SCCM Client install? I am fine with setting GPO as backup but brand new clients are not getting there settings. Thoughts?

    Like

    1. Only reason would be either the client settings have not been deployed to the machines, or a gpo is just overwriting it with something else.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

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