- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
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
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
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
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 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.
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
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
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
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
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
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?
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?
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=-
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. 🙂
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?
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.
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’.
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.