Time for some SCCM now and where better to start than with update management as we believe this is one of the key features SCCM generally does really well. This post will hopefully provide you with some useful tips and tricks for managing windows updates in your enterprise.
*Quick disclaimer – All tips are tried and tested on the latest version of SCCM at the time of writing (SCCM CB 1710)
Update Group Tips:
A key point to consider when planning your update groups and rules is the 1000 update per group deployment limit, SCCM will currently only allow you to deploy an update group to a device collection that has no more than 1000 updates contained within it. This means you cant just have 1 update group you want to deploy with all the updates ever released for every product in it because this will contain way more than the 1000 update per group limit. Of course you can have an update group which contains more than 1000 updates in and this can be quite useful for reporting, however try to deploy that group to a device collection and you will receive an error.
Thinking about how to overcome this hurdle we decided to split the update groups out into yearly chunks, by splitting out the groups in this way we were unable to reach the 1000 updates limit per group whist each group contains updates from server 2008 to server 2016. In practice this meant if we had an estate with some 2012 R2 and 2016 servers in it we would have a separate update group per year containing the updates for 2012 R2 and 2016, for example:
“Windows server updates from 2016” is the name of the group and it contains only the updates released for windows server 2012 R2 and 2016 from 1/1/2016 – 1/1/2017.
You can create these groups manually via custom searches in the “All software updates” section, once happy with your selection select all the updates and choose create software update group. A good tip here is to save your search so each time you move to a new year you can just reload your search and change the date. When downloading the updates give each yearly group its own deployment package for ease of management.
A good part of the leg work is now done, you have all your yearly software update groups all nice and ready to deploy to your device collections but what about next month when new updates are released, how can you now automate the process for ongoing patching without having to manually keep creating and editing the existing yearly group? The answer lies in Automatic Deployment Rules (ADR’s)
Automatic deployment rules are a must should you wish to make your update management process as Automated as possible. In this yearly scenario you will want an ADR that creates an update group containing just this months updates, the group can then be deployed to as many device collections as you like and at the end of the month the updates can either be manually shifted or automatically moved via PowerShell to the latest yearly update group so its ready for next months batch of updates.
key points when using ADR’s are:
Use the Add to existing software update group option – You only need 1 update group containing each months updates, there is no need to create a new update group each month and make the management untidy!
Property Filters – For windows server updates use the “Update Classification” option to select your critical and security updates, use the “Product” option to select your server version e.g “Windows Server 2016”, use the Superseded “No” option as its unlikely you want to be deploying outdated updates, use the date released or revised option to select “last 1 month” to only fetch updates from this month. Finally if you want to exclude certain updates a good trick here is to use the Title option and use the – card, for example “-preview” or “-KB1234567”. Use the preview button to see what updates you will be pulling.
For your deployment package choose the same package as your latest yearly group – remember when you enter a new year to update this!
The true benefit of using SCCM over other solutions such as stand alone WSUS is the much richer capabilities it allows for automation. A key part of this is the way you deploy your update groups to device collections, SCCM gives you the ability to make updates either Available or Required. Available deployments simply present the updates to a device collection, the updates will sit in software centre waiting for a user to click install, these types of deployments can be useful for those tricky workloads where a custom shutdown/startup procedure is required and it needs hand holding from an engineer. From an automated perspective you want to stay away from available deployments as much as possible. Required deployments on the other hand not only present updates to a device collection but will also force the updates to install automatically, if the update requires the machine to be rebooted then the machine will be rebooted (on default settings). Required deployments add the automation but can be dangerous if not configured correctly. In an Enterprise environment its unlikely that it will be OK for servers to be updated and rebooted left right and centre as soon as updates are released so the following tips can help in this situation.
Tip 1: Use Maintenance Windows
Maintenance windows are configured from the properties of the device collection, you can configure 1 time only windows or recurring windows, whatever window setup you choose its important that as soon as you deploy your update group you have a maintenance window set (even if the window is in the past). When a required deployment is presented to a device collection with a maintenance window set the client will wait until the start of the configured maintenance window before it attempts to install the update, if the update requires a reboot the machine will only restart during the maintenance window. Going back to why having a window set in the past is a useful idea, if you are unsure of when your next downtime window might be you might consider unchecking or removing previous windows set – Bad Idea, the client will now have the freedom with no window set to install and reboot the server at any time. We are all Human and make mistakes so having a window set in the past can help avoid this. Also when configuring a window remember to choose to apply this schedule to “Software Updates” from the drop down menu.
Tip 2: As soon as possible
Whist configuring your deployment schedule you may ponder over what option to choose for the software Available time and Installation deadline. You can either choose the “As soon as possible” option or a specific time such as 7 days. When using maintenance windows you will always want to choose the “As soon as possible” option as this will ensure as soon as the maintenance window becomes active updates will begin to install straight away.
Tip 3: User Experience
When deploying update groups as required it is possible to also specify the device restart behaviour under the “User Experience” tab, by default no suppression is specified so the client will reboot the server at will if the update requires it. For full automation it is a good idea not to suppress restarts however for those tricky workloads again you can go one better than manually installing the updates by using the suppress restart option, this way an engineer can login following the maintenance window and there only job will be to simply handle the restart process rather than having to manually install the updates first, wait a while then restart the machine.
Device Collection Tips:
When thinking about device collections you want to be thinking about how to mitigate risk, as mentioned earlier its unlikely in an Enterprise you want to be in a scenario where every server is updating and rebooting at the same time by having every device in a single device collection. What you may want to be doing is separating your workloads out into different device collections, for example you have two domain controllers in your Active Directory forest so you create 2 device collections and put one domain controller in each collection, you then configure a different maintenance window on each collection so the domain controllers are never down at the same time. You can apply the same theory to an initial test to production update plan by having a collection with your test servers in that has a maintenance window first then gradually working your way through to the production servers. Feel free to create as many device collections as you like because the trick is when it comes to deploying your update groups create an overall device collection which has Include group membership of all your other device collections then deploy your update groups to this single device collection. Its important to note the maintenance windows are global, what we mean by this is if you have a maintenance window set for a device in one collection this will apply across all collections which is why its important to choose the “Software Updates” option in the apply this schedule section from the drop down menu.
That’s all for now, hope this guidance has provided you with a few useful tips for managing your software updates with SCCM!