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.
Now, In Part II i’ll show you how to deploy updates and properly manage the future with ADRs, whilst catering for the past with Baselines.
Handling Windows Updates can be tricky at the best of times. Timing, testing and the sheer resource to complete that can be a headache. However by utilising SCCM’s ADRs (Automatic Deployment Rule) and ensuring we are testing on Dev machines first can really take the strain off.
I’m going to stick to the easiest base to build from in this guide, and go with a once monthly deployment routine. Certain products like Endpoint Protection don’t fit this so I shan’t be covering them. Also for the sake of simplicity and the length of this blog already, this won’t cover Office 365.
Also this post has been written over a few months, so please excuse a few time differences in screenshots!
If you’re new to the Cumulative model in regards to Windows 7 and 8.1, or just need a refresher on the naming conventions, I’d advise you read Microsoft’s release here.
What we’re going to do
As hinted in the Introduction, we are going to split our updates into two categories, and its best you understand this first:
Covering the past.
A Baseline is a group of updates for a Product that have been released since Day 1 of its life cycle, to the current day.
For instance, Windows 7 was released on 22nd July 2009.. The baseline I would create would hold every relevant non superseded update between then and today.
We will create a Baseline for each Product. 1 for Windows 7, 1 for Windows 10, 1 for Server 2016, 1 for Office 2013 etc.
These Baselines will then be deployed to collections containing clients of their relevant OS’.
Covering the future.
An Automatic Deployment Rule is there to create a monthly update package. As per its name, it will run automatically on a schedule we configure, and go off, download the updates we pre-configured it to, and then deploy them to the clients we tell it to.
The idea here is every month you as an administrator should have very little hands on, and even if you decide to take a holiday, it will still run on a schedule. (Just remember to let change management know first!).
Collections – Prod & Dev
To really utilise the ADRs in particular, I’ll show you how to deploy your monthly updates to Development machines firstly, giving you time to test out the updates for any gremlins, prior to the automatic deployment to Production, say, a week later.
First things first, lets setup those collections we spoke about. Granularity here is key to having full control later.
I’ve created a Powershell script which can do the below automatically and configure the folder structure, queries and limiting collections automatically.
But for an overview:
I’d advise splitting between Servers & Workstations, then a level deeper by OS:
Create top level Server Device Collections which contain all Servers. 1 for Production Servers, and 1 for Development or Pre-Production Servers.
A level down, split your Server OS’s into individual folders and Device Collections. So a folder for Server 2016 with Dev and Prod collections. One for Server 2012 etc.
Set the limiting collection for these OS specific Device Collections to the top level ‘All Server’ groups.
Do the same for Workstations. All workstations at the top, with Dev & Prod. Then each individual OS below that you wish to support.
For the OS specific collections, set a query to ensure only that OS is included, and set an Include Collections from the Top Level.
With Products like Windows 10 now being fully Cumulative, there is a fair argument to say a Baseline isn’t required for these, however, i’m going to create one for the sake of fullness. Other products that are not or have not always been cumulative, certainly need a baseline created.
We need to create a baseline for each Product you need to update. Windows 10, Server 2008r2, Office 2013 etc.
To do this, navigate to Software Library>Software Updates>All Software Updates
Right of the Search Button, select Add Criteria and add the below, then hit Search;
Product = Windows 10
AND Superseded = NO
AND Update Classification = Critical Updates
OR Update Classification = Definition Updates
OR Update Classification = Security Updates
OR Update Classification = Update Rollups
OR Update Classification = Updates
Please be very careful with the ‘Updates’ classification – in many cases this will include ‘Preview’ of updates. i.e next months rather untested updates.
This will now show you what should be all applicable updates for the selected Product.
Select a single update in the list, and hit Select All – Ctrl+A.
Right click > Create Software Update Group
Give it a sensible name;
“Baseline – Windows 10 Updates – DDMMYY”
Before you shoot off anywhere else, lets save this Criteria Search so you don’t have to enter them all manually again..
Now change the Product in the search and repeat the above for all your Products.
Id advise once you’ve done your main Products, you also do a single one for the lesser categories such at Silverlight, Visual Studio etc.
Do the same with the baseline creation but add multiple Product lines.
Call it ‘Baseline – Windows Update – Windows General Products’
Once you’ve finished creating, let’s go see what we’ve created..
Software Library>Software Updates>Software Update Groups
As alluded to at the start of this section, cumulative updates don’t really fit into what we’re trying to achieve with Baselines, so before going any further.. I’d advise you view the members of each Update Group and remove any Cumulative Updates, or other updates you simply don’t want contained.
Download the Baseline’s
Software Library>Software Updates>Software Update Groups
So there are all our Baseline’s. But all we’ve done is collect them all together and given them a name.
Lets Download them…
Right Click > Download
Create a new Deployment Package
Give it the same name as the Baseline itself
Set the Package Source location to the SCCMDeploymentPackage location we created in Part I.
You will need to manually create the folder itself inside the location.
Click Next and select a Distribution Point\Group to send them out to
Select your Distribution Settings
Download from the Internet
Your language preference..
Summary, and Next to finish
This part will take a little while as it runs through and downloads them all..
Once Complete. (Check the bottom of this page for any errors, if there are any –i’m looking at you Windows 7-, then repeat the process again until success).
You can now check the file location, and you will see all your downloaded updates. Inside each folder you’ll have the individual .cab files.
Repeat this process for each of your Software Update Groups..
Deploy the Baseline’s
We’ve grouped them, we’ve downloaded them, we’ve distributed them… Now to deploy them..
We’re going to make two deployments of each. 1 to our Dev collection, 1 to Prod.
Right Click > Deploy
Name it the same again.
As this is the Windows 10 Baseline, select the Windows 10 Device Collection – Dev in this instance.
Set to ‘As soon as possible‘
Display in Software Center, and only show notifications for computer restarts.
This does what it says on the tin, and is my preferred option.
This can be used to override any Maintenance Windows you have set, by default, you wouldn’t use this.
Device Restart Behaviour
Tick if you want to suppress automatic restarts after installation.
Write filter handling
Windows Embedded devices only
Software Updates Deployment re-evaluation behaviour upon restart
TICK IT! – This forces the client to rescan the device after it has restarted for updates. If you don’t tick this, you run the risk of SCCM not being aware of updates being installed after a restart, prior to the next scheduled scan.
Set alerts if you see fit..
Download options. Most environments will want to Download / download and install.
Read the second to bottom tick box carefully and decide. If software updates have been deployed to your clients\servers but for whatever reason they cannot access the update from a Distribution Point, then you can allow them to download it from Microsoft Update.
Select an Existing Deployment Package
The correct one we created earlier…
Set to Download (although we’ve already done this)..
Before you click next again, hit Save As Template
Save as Baseline Default
Click Next to Finish
Repeat the Deployment again, this time to the Production product specific collection.
Select ‘Select Deployment Template’ and hit the Baseline Default you created.
Run through all the steps ensuring its correct and finish.
Until you have your Baseline deployed to both your Development and Production Device Collection.
Repeat the above for all the Baseline groups you have.
For the Non-OS Specific Software Update Groups like Office, and our Windows General Products Baseline, follow the below.
Use the same Template you created, but deploy them to the top level All Windows Clients & if it applies, ALL Servers.
This way, our Non-OS Specific products will get deployed to all Operating Systems which could house them.
Automatic Deployment Rules
So onto patching the future.
In the same vein as Baseline’s, we are going to create product specific ADRs. Each ADR will then be deployed to our Dev and Prod device collections accordingly. Only the Prod deployment will have a delayed release time of 7 days.
This means, when our ADR runs, it will automatically release the updates to our Dev devices, then 7 days later…once you have thoroughly tested…release to our production devices.
Create a new Automatic Deployment Rule
Give it a logical name – ADR – Windows Update – Windows 10
Description – Windows 10 Monthly Updates
Select Browse for a collection to target..
Select the Development – Windows Updates – Windows 10 Collection
Select Create a new Software Update Group and click Next.
Select Automatically deploy all software updates found by this rule, and approve any license agreements.
Now we need to set what criteria we want this ADR to match every time it runs. i.e, what updates do we want this to find?
Date Released or Revised = Last 1 Month
Product = Windows 10
Superseded = No
Update Classification = Critical Updates OR Definition Updates OR Feature Packs OR Security Updates OR Service Packs OR Update Rollups
Fairly self explanatory, when this runs, it’ll find any updates released or revised in the last one month for Windows 10 that are not superseded, that match any of those classifications.
You can hit Preview here, to see, well a preview of what this criteria currently matches in your update database.
Now for the schedule to run this ADR..
Currently, our Software Update Point Synchronisation takes place late on Patch Tuesday, the Second Tuesday of the month at 23:00. Now, we want to give it a few hours to complete before we run the ADR.. so that takes us into the Second Wednesday. 05:00am sounds like a reasonable time to me.
Do Not Set ‘Run the rule after any software update point synchronisation’.
If you do this, you are tethering your ADRs to your Sync and I guarantee you one day down the road you, or someone else, will go and manually sync your SUP, unknowingly kicking off the ADRs, and with them, deployments.
As at the start, we selected the Development collection, we want these clients to update straight away once the updates have been found, for this reason select As soon as possible here to both Available and Deadline.
A repeat of settings we configured for baselines earlier..
I’d advise you set to Generate an Alert here. Its good to know every month what the compliance of updates are. Set it to 80 percent after 7 days, and see if you can ramp it up to 90-95 over the coming months.
Download Settings for Clients. You may have specific requirements for boundaries\fallback, but generally most should set this as per below.
Select to Create a new deployment package with the same name you gave it earlier.
Place its content in its own folder under SCCMDeploymentPackages with the same name.
Select the Distribution Points \ Groups to automatically distribute to when the ADR runs.
Set to Download software updates from the internet
Set your required Languages
Again, lets save all this as a Template before going any futher..
Select Next and Close to finish
We now have our first ADR. If you select the Deployment Settings tab down the bottom..
You will see it’s set to deploy to our Development Windows 10 collection. This will happen automatically on the schedule we configured.
So now lets add to this ADR..
Right click the ADR, select Add Deployment
Browse for and select our Production – Windows Update – Windows 10 collection
Now we want to set a delay. We want to say, 7 Days after this ADR runs, these updates will become available to this collection.
Set the Software available time to Specific Time = 7 Days
Same settings again..
Next & Close to Finish
Now selecting the Deployment Settings tab will show both our deployments.
Easy way for a single ADR to manage the release of updates over a period of time to different collections.
Now repeat this process of ADR creation\deployment for each Product category you have.. Selecting the Template you created earlier to save a few button presses, and ensuring you change\select the correct reference collection each time.
Until you have an ADR for each OS you need to support, each with two (or more!) deployments.
For Office, you likely want to deploy to the top level collections.. After all, different Office versions could be installed on any OS depending on how you manage it.
Have Office on Servers too? Ok.. add in more deployments..
Now for our Windows General Products, which we covered in Baselines. Create an ADR in the same way, selecting the Top Level collections.
Simply add in the Product categories here that you need to cover..
Silverlight, Visual Studio 2012, Report Viewer etc
Once complete, you will have a nice selection of ADRs that will do their business on the schedule you configured.
However, should you be impatient (winadmins slack members 😉) then you can select the ADRs and hit Run Now.
Expect this to take a little time whilst they run..
Once complete, under Deployment Packages, you will be able to see your ADRs and Baselines all together.
Under Software Update Groups you can see the groups, per month in the case of ADR’s for what has been created.
On each Software Update Group, you can see their deployments, and the dates for which they will become available to the targeted clients.
Check the ‘Deployed On‘ time here. My single ADR sent updates to my Development machines on 02/08/2017 (yesterday at time of writing), but the deployment to Production won’t happen until 09/08/2017!
And lastly, for those of you following along with my naming conventions, you can now easily search the deployments monitoring to see client status for Baselines and ADRs alike.
So we’ve patched our products for all updates released so far with Baseline’s and we’ve covered future releases with ADRs, whilst at the same time giving ourselves flexibility to run granular tests per OS \ Product.
As I continue this series, I’ll demonstrate how this granularity and separation can be your best friend in times when you do find problems with updates or you just need slightly more detail in monitoring.
In Part III i’ll cover Client Settings, Maintenance Windows, Group Policy configuration and HTTPS.
Thank you for reading, I hope this has helped you, and a personal thank you to the WinAdmins SCCM Slack group for nagging me enough to complete this blog! – If you’re not a member already, I highly suggest you join!