SCCM 2012 R2 - Possible Software Updates strategy

Back to ConfigMgr main menu

There is no absolutely correct way to implement a software updates strategy in your organization. Each organization is different and the correct way is the way that works for you. However, after several attempts at trying different approaches, I've decided on a method that delivers a robust solution and is easy to understand and manage. I've included some details below. I hope it makes sense.

Collections:
 
This can be based on customer requirements but the collections are generally desktop and server collections (rather than collections per product). Additionally larger customer sometimes want collections per Business Divisions.

There are ALWAYS pre-production and production collections.

Software Update Goups:
 
The first thing I do when I'm implementing a solution for a new customer is to create a "line-in-the sand".
There are then three phases to the process:

1. Updates released prior to that point-in-time (eg December 2014) are regarded as historical updates.
2. Monthly patch cycles afterwards are regarded as BAU (Business as Usual). 
3. Annual maintenance of Software Update Groups

1. It is important to note that there is a hard limit of 1000 updates per software update group (SUG). This makes it impossible to include all historical updates in a single SUG (eg Windows 7 currently has almost 700 updates). In this phase I create Software Update Groups as required.

A typical strategy may include the following SUGs:

Desktop
Windows 7 SUG
Windows 8 & 8.1 SUG
All Office updates SUG

Server
Windows 2003 SUG
Windows 2008 & 2008R2 SUG
Windows 2012 & Windows 2012R2 SUG

As we have drawn a "line-in-the-sand" these update groups are static and will never change. The desktop SUGs are then deployed to the desktop collections (pre-production and production) and ditto for the servers (see below for deadlines and maintenance windows). These deployments remain in place indefinitely (even after the updates have been installed). In this way new desktops and servers that are added to the environment can be fully patched very quickly.

2. A Desktop Automatic Deployment Rule (ADR) downloads all desktop updates released in the last month and deploys them to the pre-production desktop collection.
A Server Automatic Deployment Rule (ADR) downloads all server updates released in the last month and deploys them to the pre-production desktop collection. 
I schedule the ADRs to run on the 3rd Sunday of every month. As you will know Microsoft normally release updates on the 2nd Tuesday of every month. I delay my ADRs by almost a week to allow Microsoft to withdraw any updates that may have caused problems in customer environments. Each ADR is configured to create a new SUG each month and to deploy with a deadline of 3 days in the future (the newly created SUG has to be renamed to something sensible). After a period of pre-production testing the SUGs are then deployed to production.

3. Annual Maintenance: At the end of each year the 12 monthly SUGs are consolidated into an annual SUG - and the process starts again.

Deadlines and Maintenance Windows:

I do not use maintenance windows for desktops (unless under specific circumstances). When I deploy SUGs to desktop collections I normally schedule the deadline to be 3 or 4 days in the future (and show all notifications). I find that the default notification and restart settings are more than suitable.
Servers require maintenance windows. It could be that you split your server estate into multiple collections so that you can define different maintenance windows. This structure will always be driven by customer requirements.

Out-of-Band updates:

Microsoft sometimes release very critical updates out of band (ie not on patch Tuesday). I create an Out-of-Band SUG which is deployed to each pre-production and production collection. The deployment deadline is in the past so that the updates are installed almost immediately. Server restarts will be controlled by the maintenance windows.

Other items worth a mention:

• Don't choose all products in Software Update properties (unless, of course, you need them all - which is doubtful).
• It's quite valid to deploy a Windows 2012 Server update to a Windows 2008 Server for example. The update will not be downloaded or installed and will not create any issue.
• SUG deployments should remain in place. Don't remove them.
• Note that you can use a single deployment package for all updates (the 1000 update rule only applies to SUGs).
• If you get into the habit of configuring this solution with PowerShell you will be able to re-create it quickly time and time again.

I hope all this has been helpful. It works for me.