Introduction

I have been spending some time on the Configuration Manager forums on Technet lately, and questions about Software Updates (among others) frequently pops up. So I thought of creating a series of blog post explaining some of the basics of Configuration Manager or explaining some of the topics I often see being repeated as questions on the forums.

This will be the very first in such series, where I will give an example on how you can use SCCM to fully automate the patching of Windows 10. All of these examples will be based on the latest version of Configuration Manager Current Branch.

Configuration Manager

Collections

First things first. Collections are required before deploying software. That goes for Software Updates too. In this scenario I’m having a collection consisting of computers for testing (Pilot) and another for the entire environment (Production). In short, every update ever deployed are first tested for 14 days before being deployed automatically to the rest of the environment.

For this example, I have created these two collections. I suggest you do something similar. Pilots are picked on environmental criteria. These collections will be used later in this example. Both collections are created with following WQL query, where the limiting collection limits the members.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like "Microsoft Windows NT Workstation 10%"

Automatic Deployment Rule

All the automation in this example is coming from the use of an ADR (Automatic Deployment Rule). In short terms, ADRs runs on a set schedule, picks up updates (in this example Windows 10 updates) and deploys them to your computers. All of this unattended, based on your criteria. To create the required ADR used for this scenario, follow my guidelines below:

• In the Configuration Manager console, in the Software Library workspace, expand Software Updates and right click on Automatic Deployment Rules

• Name: Give the ADR a suitable name. In this example, mine is called Software Updates – Windows 10
• Collection: Select your Pilot collection
• Add to an existing Software Update Group (SUG)

• Make sure Automatically deploy all software updates found by this rule, and approve any license agreements is selected

• Configure the search criteria as shown below. You can preview the updates being picked up by the rule on Preview

• The schedule of when the rule will run is important. Most updates are released every second tuesday each month, also called Patch Tuesday. As of such, configure the schedule as following
  • Monthly
  • The second Tuesday
  • Offset with 1 day (this to account for that the second Wednesday of each month, sometimes comes before the second Tuesday)
  • Start time: Configure a time appropriate for your environment, and make sure that your Software Update Point (SUP) has synchronized updates prior to this time

• Software available time: As soon as possible (this will make the updates available as soon as the ADR has run and the client has updated its machine policies)
• Installation deadline: As soon as possible (this will install the updates as soon as the updates has been made available to the clients)

• User notification: Display in Software Center and show all notifications (I want my pilot computers to get all notifications about the deployments)
• NO suppressing of reboots (I want those updates to have effect the same day they are deployed)

• I want the clients to be able to download the updates regardless of boundary and distribution point status. Change as it fits your environment

• Either use an existing deployment package or create a new one. If you select to create a new deployment package, the package will only be created once and will be used in following schedules
  • Note: Don’t put too much into the word ‘Deployment Package’. The package has nothing to do with deployment. Its for content distribution and its where the bits are downloaded to.
    • There are different design options here. You can certainly create one deployment package to rule them all, and put all updates into the same package. Depending on the size of your environment, you might want to consider to divide them into products or have a plan for several packages during the year. In this example, I create new Deployment Packages semi-unnually (twice a year). Also, only the actual bits required by each client will be downloaded by each client – not the entire package.

• Finish the wizard through the next 3 snippets

Final step

• As a final touch, we need to add another deployment to the ADR. Right click on your newly created Automatic Deployment Rule and select Add Deployment as shown below

• This time selecting our Production collection as shown below

• Software available time: Specific time: 14 days (This will make the updates available for production 14 days after the rule was run on Patch Tuesday)
• Installation deadline: As soon as possible (This will install the updates as soon as the updates has been made available to the clients)

• User notifications: Display in Software Center and only show notifications for computer restarts (this time I only want to notify the end user about the upcoming reboot)
• NO suppressing of reboot (I’m still interested in getting these updates out there with effect as soon as possible)

• And the rest of the new deployment is finished off the same way as the inital deployment for the Pilot collection

Client Settings

No suppressing of reboot you say? Isn’t that a tad harsh?

Actually, I don’t think so. This is combined with following Client Settings and gives the end user in this scenario 8 hours to complete a reboot, where the dialog box cannot be closed the last 90 minutes. This way no one can claim they missed the notification nor did they have time to complete the reboot.

Summing up

So, what’s happening again is following:

• The ADR is automatically run every second tuesday, with an offset of 1 day
• A deployment is made available and required for the Pilot collection immediately
  • If a reboot is required, the reboot will be forced 8 hours post installation
• 14 days later the deployment for Production is automatically made active and required with a deadline as soon as possible
  • The updates will start installing for all computers in production as soon as possible
  • If a reboot is required, the reboot will be forced 8 hours post installation

Above will continue to pick up new updates each Patch Tuesday. Everything automatically and unattended, and everything will happen at the very same schedule each month.

NOTE: Above example will leave approx. 14 days for the production clients to install updates before the ADR is run once again and thus creating a new schedule. If you have many computers often being offline for extended periods, consider changing some of the timing. If the clients are offline during the available period, they will install all required updates during the next schedule and so forth.

I hope this was helpful. Please leave a comment below if any questions 🙂