In our final part of the Unifying SCCM and WSUS series, we will cover maintenance windows for update installation, monitoring update groups, and troubleshooting failed deployments.

Joseph Moody

Joseph Moody is a network admin for a public school system and helps manage 5,500 PCs. He is a Microsoft Most Valuable Professional (MVP) in Cloud and Datacenter Management and blogs at DeployHappiness.com.

By leveraging a well-designed collection hierarchy, we can design an update scheme that automatically patches our machines within specified windows. Do you have certain servers that can only be restarted at certain times? How about a group of machines that need to reboot in certain order? Maintenance windows allow you to overcome both problems by allowing you to granularly schedule update installations and reboots.

Managing SCCM maintenance windows ^

We created software update collections based on the client operating system in Part 1 of this series. When you configure a custom maintenance window, you can apply the schedule to one of these collections.

Software update collections based on server operating systems

Software update collections based on server operating systems

Depending on your environment, you might also want to create additional collections for certain server roles. For example, you might create a collection for each Hyper-V server or domain controller at each of your physical sites. This would allow you to stagger installation and reboot times so that services never become unavailable.

Once you decide what servers should restart and when they should be available for patching, you can create your first maintenance window. Right-click your collection and select Properties – Maintenance Windows.

Creating a maintenance window for 2008 R2 servers.

Creating a maintenance window for 2008 R2 servers

Click Add and name your maintenance window. If you want your maintenance window to start at a later date, change the effective date to reflect that. The default maintenance window opening is for three hours (1:00 AM to 4:00 AM). If you change this, be sure to leave a window large enough to install patches, applications, and so on.

Finally, choose a recurrence schedule and a recurrence date. In the screenshot above, this collection will have a maintenance window every Saturday from 1:00 AM to 4:00 AM. This maintenance window is applied only to software updates. Click OK to see your maintenance window listed.

Two maintenance windows applied to my server collection.

Two maintenance windows applied to my server collection

In the screenshot above, I have two maintenance windows applied to my collection. The first is for Saturday, and the second is for Sunday. If your maintenance windows overlap, the SCCM client will merge the times together. For simplicity, avoid overlapping windows.

Monitoring software updates with SCCM ^

Two client actions determine how and when updates are processed. The first is the Software Updates Deployment Evaluation Cycle action. This action checks the machine for software update compliance and determines what updates are applied. By using this action, you can test software deployments and targeting without having to wait on an update schedule.

Client actions control the software update installation.

Client actions that control the software update installation

The second one is the Software Updates Scan Cycle action. This action checks each software update installation for completion and notifies the machine if a reboot is required to finish the installation.

Updates waiting to be installed.

Update waiting to be installed

Like other deployments, automatic deployment rules can be viewed in the Monitoring/Deployment windows in the Configuration Manager console. By examining a deployment status, you can see compliant machines, failures, and machines that still have not reported. In the screenshot below, all of the 2012 R2 machines are compliant with a Baseline update. If you have run any of your automatic deployment rules, you would see those deployments now.

Deployment status of our baseline deployment for 2012 R2 updates

Deployment status of our baseline deployment for 2012 R2 updates

Troubleshooting SCCM software updates ^

Several things can go wrong with software update deployments. First, the software update might not be deployed to a client. Ensure that the client is a member of the collection, the deployment is linked to the collection, and the deployment is scheduled to install.

A deployment applied to a collection

A deployment applied to a collection

Ensure that the content has been distributed to a distribution point. This can be checked under Monitoring/Distribution Status/Content Status. You can select your Software Update Package to check on the distribution status.

Successful distribution of Windows Server 2012 R2 content

Successful distribution of Windows Server 2012 R2 content

If you still have issues with software updates, head to C:\Windows\CCM\Logs on your client. Launch WUAHandler.log. You will need to download the Configuration Manager Toolkit to use the Trace Log Tool pictured below.

Windows updates recorded in the WUAHandler.log

Windows updates recorded in the WUAHandler.log

Are you an IT pro? Apply for membership!

0
Share
8 Comments
  1. Lonnie Gaither 5 years ago

    I have come across a situation where new updates have shown up in the windows updates list, but are not included in an ADR or a baseline. Do I need to manually add those to the existing groups/packages?

    0

  2. Author
    Joseph Moody 5 years ago

    To me, it sounds like the ADR didn't run or the ADR filter didn't catch the update. Can you manually run the ADR and see if the updates are added?

    0

  3. Lonnie Gaither 5 years ago

    Thanks Joseph, I will check that out. I'm not totally clear on how this all works in the background, so I was wondering in general how totally new updates would get added anyway. The ADR takes care of pulling in new updates then?

    Part of this is because I had to limit my Windows 7 Baseline deployment because one of the updates (which I could not determine the exact one) kept causing the entire deployment to fail. So, I sorted All Updates down to Windows 7, but manually only selected the Critical Updates in the list for the baseline and then the deployment went through without an error. Do I need to go back and do anything to make sure Updates and Security Updates are not skipped in the baseline or ADR?

    Thanks again for this site! I have fixed several of my SCCM errors from your info!!!!

    -=Lon=-

    0

  4. Author
    Joseph Moody 5 years ago

    Yep - the ADR should run regularly and add it new updates to your update group (or create a new update group). This depends on your setting.

    I would have every applicable update being applied.

    And no problem - but thank Michael Pietroforte - he created this resource. 🙂

    0

  5. Doug 5 years ago

    Thanks for the guide, Joseph. You talk about having a baseline for each OS, but don't mention software updates. Is it best practice to include, say Office, updates in each OS baseline or is it better to have an update group for software?

    0

  6. Author
    Joseph Moody 5 years ago

    I prefer a software update group for each specific application (Office 2013, Office 2010, System Center products, etc).

    If I deploy the application with SCCM, I have the ADR set to deploy updates to that same collection. If the application is baked into the image task sequence, I will create a collection that queries for the application and deploy to that.

    0

  7. Doug 5 years ago

    Great, thanks for the insight. Query driven update deployment sounds like the way forward for us as we only use SCCM to roll out certain apps and have the rest either manually installed or as you put it 'baked into the deployed image'.

    0

  8. Tom 3 years ago

    Baking application into Images is not ideally best practice, you should create a software update group and apply it to the collection you need it to apply updates from during the task sequence.

     

    I would not recommend having many apps into the .WIM file as it creates a headache when you try doing testing and something starts to fail.

     

    Offcourse everyone has there own point of view but it is just an advise i have been in conjunction with for a while now.

    0

Leave a reply to Joseph Moody Click here to cancel the reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2019

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account