Tuesday, 2 December 2014

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.



19 comments:

  1. Can you share the PowerShell scripts that you use to configure this?

    ReplyDelete
    Replies
    1. This is a great place to start
      http://www.dexterposh.com/2014/06/powershell-sccm-2012-automate-patching.html

      Delete
  2. So here is a stupid question and I have been hitting my head to explain to a customer. The client read on a blog that under filters for software updates to select Required and Yes. Why would one do this? After all, how do the clients and the site server even know if they are required if the patch just was released on Tuesday? Is there any justification for this? I never select that filter and not sure why people want to.

    ReplyDelete
  3. I don't choose "required" when filtering for SUGs Kristopher. The client will decide what it needs.

    ReplyDelete
  4. Hi Gerry,

    Fantastic site,

    We have a heavily governed environment (financial services) and have different install/reboot times for different types of servers, ie: 4am for a remote site, 5:30am for normal servers, 1pm for
    backup servers and 7pm for the payment system servers,

    Would you use separate SUG's for these different groups of server and a collection that changes membership regularly, these server are 2008 R2 and 2003 R2

    I appreciate your thoughts,

    Thanks in advance,

    ReplyDelete
    Replies
    1. I try to use the minimum number of SUGs. You just have to be careful that there are no more than 1000 updates in any SUG. You will need seperate collections to correspond to each maintenance window. I don't see why the collection membership would change regularly. As you said the structure is already defined.

      Delete
  5. Thanks for your response Gerry

    ReplyDelete
  6. Hi Gerry,

    1. Is it possible to Deploy one software update group on multiple device collections simultaneously?

    2. Also is it possible that whenever new device came to SCCM and it will get automatically to some existing device collection based on some rule...

    Thanks

    ReplyDelete
    Replies
    1. 1. Yes, it is. Most environments I know work like that. SUG is deployed to a test collection and then to production 1 week later (for example).
      2. Sure. If you create dynamic collections (based on OS for example) the device will get all the updates deployed to that collection.

      Delete
  7. Thanks for the great info Gerry. Can you give me more detail on creating a SUG and deployment for out of band updates?

    ReplyDelete
    Replies
    1. You just need to create a new SUG or add the updates to an existing SUG.

      Delete
  8. Hi Gerry - thanks for your blog. Without maintenance windows, how do you handle machines that have been offline for months andhave missing patches? We have a requirement to not have machines apply and reboot during the business hours. I could instruct (or script business hours) but setting maintenance windows seems the better route. What are your suggest to have machines in compliance but not to have any imapact on the end user's work day?

    ReplyDelete
    Replies
    1. I handle that differently. I normally don't use MWs for workstations. I deploy updates with a deadline of 1 week in advance. This deadline is during working hours. Users are prompted for a week to install updates. If they don't the updates are forcibly installed after a week. I don't want computers on the network that aren't patched.

      Delete
  9. Hi Gerry,

    Thank you for this excellent blog.

    You say it's ok to use a single Deployment Package, is that really a best practice? We currently do all of the software update deployment process manually. Each month we create a Deployment Package and a Software Update Group. But, I would like to implement an ADR as you've suggested here. What do you recommend as far as Deployment Package usage?

    Kind regards,
    Greg

    ReplyDelete
    Replies
    1. I guess it really depends on what you are doing. Are you patching all versions of servers from 2003 to 2012R2, for example? That's a lot of updates. You could use a single deployment package but it can also sometimes be a good idea to have a Server Deployment package and a Desktop Deployment Package.

      Delete
  10. This might be a silly question but if you deploy windows 7 updates to a collection that also has windows 8 machines in it (and vice versa) will it cause any issues?

    ReplyDelete
    Replies
    1. There are no silly questions if you don't know the answer Dale. There will be no adverse effect. Only the updates that apply will be installed.

      Delete
  11. Hey Gerry,

    I'm not sure I understand this part of the documentation: Each ADR is configured to create a new SUG each month and to deploy with a deadline of 3 days in the future. How would I configured the ADR to accomplish that?

    ReplyDelete
    Replies
    1. When you are creating the ADR check the box to create a new SUG each time and choose and installation deadline 3 days in the future.

      Delete