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.
Create Windows Update Device Collection Download
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!
53 thoughts on “Configuring WSUS with SCCM Current Branch (Server 2016) – Part II – ADRs & Baselines”
Greate blog, love the detail. Enjoyed this and part 1 very much. I have to say that I generally prefer to set up ADR differently so I look forward to hearing why you prefer more separation. One big issue I would point out is with having the ADR’s run on the second Wednesday of the month……sometimes the second Wednesday of the month is actually before the second Tuesday, check out Nov 2017 for example.
Keep up the great, very clear and detailed posts. Thanks!
Awesome guide! Just finished this one and joined the Slack channel 🙂 Can’t wait for Part III! Thanks!
Almost forgot to mention… Got some “improvements” for the guide I think 😉
I had to edit some criteria in your PowerShell script.
The filters for all servers (development & production) have the following criteria:
where SMS_R_System.OperatingSystemNameandVersion like ‘%Microsoft Windows NT Server 6.1%’
or SMS_R_System.OperatingSystemNameandVersion like ‘%Microsoft Windows NT Server 6.3%’
or SMS_R_System.OperatingSystemNameandVersion like ‘%Microsoft Windows NT Server 10.0%’
I think there should be an extra % between NT and Server, like this:
where SMS_R_System.OperatingSystemNameandVersion like ‘%Microsoft Windows NT%Server 6.1%’
or SMS_R_System.OperatingSystemNameandVersion like ‘%Microsoft Windows NT%Server 6.3%’
or SMS_R_System.OperatingSystemNameandVersion like ‘%Microsoft Windows NT%Server 10.0%’
One of my servers wasn’t found because the OperatingSystemNameandVersion is Microsoft Windows NT Advanced Server 10.0. Notice the word “Advanced” in the name. You did add this %-sign in the specific OS filters, so I think you just forgot in the upper filter.
Another change… The specific OS filter for Server 2016 specifies ‘Microsoft Windows NT%Server 10’. This should be ‘Microsoft Windows NT%Server 10.0’. Without the .0 (or %), it doesn’t work.
I’ve also got a question about the cumulative updates. Are you sure they shouldn’t be included in the baseline? Aren’t any single updates and previous cumulative updates set to “superseded” when a new cumulative update releases which contains these previous updates? If this is the case, you will only get these updates through ADR when a new cumulative update releases. If this is not the case, thanks for reading 🙂
Thanks again for the great guide!
Great article 🙂
A note: Your PowerShell script creates a query on the collection: “Development – Windows Updates – All Windows Clients” to query all Windows 7, 8 and 10 computers, same as with the Production one. Is it intended to have both collections query the same workstations? I beleive that the development one should have no query to manually add workstations to this collection. Alternative having it point to a OU in AD with development users.
Anyway, I really enjoyed this article 🙂 Great work.
Nope, good spot, simply a result of my copy pasting from the Prod collection!
Script has been updated to remove all queries from the Dev collection.
I’m not very familiar with Powershell. What do i edit in this to make the script work for me?
Disregard, i didn’t see the folders at first, I didn’t think it ran. Awesome!!!
No problem! Glad you got it sorted. Any issues let me know!
This is Excellent work Rich, exactly what i have been looking for. Great instruction, organized and very informative! Maybe i missed it, but the one thing I didn’t see is a section for setting GPO to point all your systems to SCCM instead of windows updates? (I’ll look when im done with this comment)
I do have a random question though, So say i have a few computers in the windows 10 production group that i don’t want to apply updates too. What is the best way to go about excluding them from getting the updates?
It is not recommended to use GPO to point to the SCCM WSUS server.
If you got a GPO already make sure that it is set to “Not configured” as the SCCM Client will make sure to point the clients to the correct server.
Ok that threw me off, a while back we were running SCCM 2012, at that time we had our GPO pointed to the Sccm Server for Updates. Well i recently rebuilt and upgraded our SCCM to Current Branch from scratch and during this time i had pointed all our systems to pull updates directly from Microsoft.com as wsus was rebuilt as well. Now i have everything in line and im am using SCCM CB to push my updates out. Your telling me that in GPO, i leave it set to “Not Configured”. As i understand, these updates will now be coming via software center. Is that Correct? I do not want anyone pulling updates or upgrades from the web, will “Not Configured” accomplish this or should i set it to disabled?.
Leave it “Not configured” and the SCCM Agent will set your SCCM integrated WSUS as default update server.
Correct, seeing the intranet point to not configured will indeed allow the sccm client itself to set it as a local policy. However, if you only have a single SUP, then I would recommend setting the GP.. Simply from a security point of view as you can be sure its being enforced.
Also, do you have any good reads or instructions on how we should handle Windows defender and Endpoint protection updates?
I will leave that to the author of the article 🙂
I’m just another happy reader of the article.
Eh i found it,, You just haven’t got there yet, I guess i’ll wing it till then!
“In Part III, I’ll cover Client Settings, Maintenance Windows, Group Policy configuration and HTTPS.”
LikeLiked by 1 person
Thank you for such a well written guide -I’m fairly new to SCCM and in the process of deploying within our school. It is a very interesting bit of kit, though a tad confusing!
Thanks Sean. SCCM/Configmgr certainly is a big old bag of tricks. If you’re not there already, I’d suggest you come join the WinAdmins Slack.
I also need to move from existing WSUS to SCCM&SUP environment… What is the right way (best moment) to move away from the WSUS GPO settings and let the SCCM client settings take care of those?
TBH, i’m scared of that time if the client is without any settings 🙂
Really looking forward your third part of this article. Any estimate for it?
Thanks Ben. The best moment would probably be right after you release a month’s patches from your WSUS standalone. Give yourself a month till next release that you can plan in SCCM. If youre only going to have a single SUP, then you can just set the GPO to it still if it makes you more comfortable.
Excellent guide. Thanks.
I know You don’t want to get too deep into all the possible ways to do things, but you mention “Preview” updates early on.
I recommend adding Title to your search filters in both manual searches of all updates, and in the Software Updates selection criteria for ADRs.
Check the box for Title in the property filters, and set the value to -Preview. (As in Title does not contain preview). No need for quotes.
After last month’s issue where Microsoft released Delta updates that made a mess in some cases via WSUS, I also added -Delta in case those are presented again.
Loving Part 1 and 2. Any estimate on Part 3?
Thanks Mike! I have 100% been distracted by something more shiny and unrelated which I’ll be posting in a few days, so keep an eye out for that.. But afterwards, I’m going to finish off part 3.. Likely after Xmas.
Hello Amazing! Its really awesome paragraph, I have got much clear idea regarding from this post. gracias
This is amazing! I am only sorry I did not find it earlier – I did have a question. I am using the powershell script and it has created my collections but I am not seeing the difference in the query between the production and the development systems. I am not seeing how the query is doing anything but populating the collections with all system that match the OS.
Sorry if this is an obvious one. Any help appreciated.
Thanks Debi, glad you’re finding it helpful!
You are completely correct in how the collections are working. You will need to specify what systems you want to be in your top level Prod/Dev collections.
Good Morning! So my sync went fine last Tuesday at 11:00 but my ADR’s were “last evaluated on the 8th which seems wrong. The SUG’s were created last on 12/9 at midnight-ish by the autoupdaterule.
My deployments are set for dev – 12/9 and production 12/16. My ADR’s are showing teh sync happening on the 2nd Tuesday and the Eval on the second Wednesday at 5:00am (which looks like it did not happen). Can you think of any ideas why this would happen? I have been rechecking everything for hours.
Hi Rich, this guide has been brilliant for setting up our SCCM/WSUS environment.
Part III will be just as important… I hope you are typing away 😉
Excellent article! We are linking to this great content on our site. Keep up the great writing.|
These articles are fantastic!! Do you know when part III will be available?
Thanks Adam! – Next month fingers crossed.
Can you clarify one thing please… for all your servers that are also software update points, those all require WSUS to be installed, right? If so, is it also necessary to install the “Database” role service on them as well? I’m thinking no as it should be getting that info from SUP, but I’m not sure how integrated the two are. Thanks!
Yes you’re correct.. I think (unless there are 2 people with your name) I replied to your previous comment with a couple links about this very topic, so check them out 🙂
Hi Rich. I just tried this on a test Win10 VM and everything worked as far as I can tell. Thanks!
One thing though. Should you be able to go to Windows Update > View installed updated history using this update method? I checked the VM’s event viewer’s system log. It showed each update installed. However, the “View installed update history” came up blank. Is that normal?
Hi, glad it worked for you!
Yes, you should still be able to see installed update history. Still blank after a restart?
Hi, yes, still blank after a restart. The system log in Event viewer shows them installed, such as 2018-03 Cumulative Update, update for Adobe Flash, etc. And if I go to “Uninstall Updates”, they are listed there as well. But none of the updates are displayed under “View installed update history.” Strange…
Looking on the Windows Feedback hub and on technet, this sounds like it’s a bug. Quite a few complaints there.
LikeLiked by 1 person
one question only: every month i need to create a new baseline and a new deployment package?
No, the ADR’s will take care of that every month. The Baseline is created to cover off all the past updates at time of creation.
You may however wish to recreate the baselines to include all the updates every 6 months or so.
wow, thanks for the fast reply! 😀
Perhaps I missed mention of it, but what do you do with the old SUG’s and Deployments made by the ADRs? I’ve been following your method for a few months now, and with 3 ADRs with 6 deployments each, I’ve already got over 50 deployments including this month’s!
Thanks for all the work you’ve put into this!
Good timing, I’ve just covered this in Part III.
Just wondering with regards to Windows 10 and cumulative updates, do you still feel having the baseline approach is the way to go? Could I not simply include the most recent, monthly cumulative update rather than all the separate, monthly quality updates? I know there’s more to it than just that–also monthly updates for Adobe Flash Player etc. And Office of course. Thanks.
The Baseline is to cover off all past updates at time of creation. And it’s best to separate these into individual categories as its less for clients to scan among other reasons.
ADR’s are there to automate future updates. Automate being the key word there so you do not need to intervene or do anything manually.
If you prefer to do it manually, sure, but it’s abit pointless. Let it do it’s thing and grab a cuppa.
However, if you’re feeling like you need to tidy it up, then check out the short “Baseline \ ADR Maintenance” section in Part III.
OK, I guess this is where I’m confused. When I follow the steps above for Windows 10 and *don’t* select any cumulative updates, I have 21 updates listed, four of those which are the 2018-04 Adobe Flash player updates for various releases of Windows 10….which in mind is not a lot. (I’m not including any x86 updates as we don’t have any systems running Win10.)
For example, if I’m not downloading cumulative updates, should I not be seeing the June 2017 update for 1703, July 2017 update for 1703, etc, followed by June 2017 update for 1607, July update for 1607 and so on. I’m using the search settings above.
Thank you so much for writing this up. It has helped me hugely. I know i’m a little late to the party but is the winadmin slack group still running?
Glad it helped!
Certainly is; WinAdmins Slack Invite
Great articles! Helped me a lot.
I have two questions:
1. My company wants me to push software updates to test/development group as soon as they come out and we know that Microsoft releases critical and security fixes not only every second Tuesday, but also in between. Do you have any suggestion on how to setup SUP to do this? Should I tick ‘Run the rule after any software update point synchronisation’ and schedule SUP synchronisation daily or is there a better/smarter way to do it?
2. If I decide not to deploy certain updates to production, after I’ve tested them in development, what is the best way to do that?
Thank you in advance for the answers and I’ll keep an eye on this blog regularly!
Hi Tom! Glad they’ve helped!
1) Ticking ‘Run the rule after sync..’ is something that seems a great idea, but you shoot yourself in the foot everytime you need to manually sync. Just have your SUP sync every day, and the ADR’s run a few hours later.
2) Right click them, and remove them from the production software update group.
Have a rather minor question on search criteria. Why would Architecture not work? I wanted to limit my search to only X64 patches but that always returns no items found.