introduction
in previous article we have discussed how to MANUALLY deploy software update , which require administrative efforts
in this article we will see how to Create Automatic Deployment Rule in SCCM
. You typically use this method of deployment for your monthly software updates (generally known as Patch Tuesday) and for managing definition updates.
When the rule runs, software updates are removed from the software update group (if using an existing group),
the software updates that meet a specified criteria (for example, all security software updates released in the last week) are added to a software update group,
the content files for the software updates are downloaded and copied to distribution points,
and the software updates are deployed to client computers in the target collection.
ADR Automatic Deployment Rule
ADR (abbreviation for Automatic Deployment Rule) have been a great feature that was released by Microsoft with SCCM . They allow to control update download and deployments
Use an automatic deployment rule (ADR) rather than adding new updates to an existing software update group.
Typically, you use ADRs to deploy monthly software updates (also known as “Patch Tuesday” updates) and for managing Endpoint Protection definition updates
Create Automatic Deployment Rule
Text
Software Update Recommendation
Subscribes to news site about updates and security
It is important to be aware about the last updates (often the second Tuesday of the month) but also the last security issue.
Sometime an emergency update is released by Microsoft to fix a vulnerability so it is necessary to patch quickly and to reduce the risk to be attacked
Create standard baselines
All your system should be set on the same way to ease management
That means systems should be based on the same image installation, same Operating System (as much as possible) and application version and so on.
Same baseline should be gathered in the same SCCM collection to ease software updates.
Create a pre-production to validate updates
Updates should be tested before the installation on production environment.
Make sure to have a pre-production environment reflect the production environment.
That means that pre-production environment contains every operating system and applications that you have on production.
So when Tuesday patches are released, first update pre-production environment and test that everything is ok for one or two weeks.
Create packages with pre-determined criteria
To ease the management of update packages, create them with pre-determined criteria such as products, languages, classification and release date.
This avoids to reconfigure update packages every month.
Create collections for each Operating System version
Organize collections by operating system ease update packages management.
In this way make an update package containing every update for the related operating system and apply it to the collection.
So every month, update this update package with new updates
Reuse update packages when possible
To limit the number of update packages and so ease management :
you should reuse deployment packages most of the time.
So in a perfect world, you should have one update package per operating system version (including service pack), and one per application (example: SQL Server, System Center DPM etc.).
Create an emergency procedure
Sometime Microsoft releases a security update outside of Tuesday patch process because a 0-day vulnerability has been discovered for example
. That happens one or two times per year.
A process to make an emergency patching for this case should exist.
Usually the emergency update should take a short time such as 10 to 15 days for pre-production and production environment patching.
Enforce a deadline to install updates
We [Networks Pioneers ] recommend to enforce install updates when the deadline is reached.
However we don’t suggest to force servers restart.
