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

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

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:

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.

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:

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.

 

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..

 

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

Define a Maintenance Window, ensuring you select Software Updates.

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

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:

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