by Dan Newton
Previously on L.A. Law In my last post I talked about the overall patching process with SCCM 2012. In today’s post I’d like to dig into one key part of the patching “machine” – Maintenance Windows.
Maintenance Windows (MWs) in SCCM
When patching (servers in particular) we recommend the use of Maintenance Windows (MWs). In SCCM Maintenance Windows are configuration “timers” that control the deployment of software and software updates. A given SCCM client can have multiple MWs and each are evaluated when a deployment is run on a given client. The goal of using MWs is to lock down servers to only install updates at the precise time dictated by the server owners. Most enterprises we work with have an agreed upon schedule for when a group of servers are allowed to be patched. This schedule should be translated into an SCCM Maintenance Window.
Unlike the ADRs “Deployment Schedule” parameters, Maintenance Windows don’t have an additive calculation to add days/hours from Patch Tuesday (see Part 1). So you’ll need to make sure that you schedule you setup matches what is desired. For example, let’s assume the our policy is to patch “pilot” servers at 12AM on the Saturday after Patch Tuesday and “production” two Saturdays after Patch Tuesday. We can’t just use the “Second Saturday” and leave it for each month. Look at the month of April 2015. The first day of April 2015 is Wednesday and so the “Second Saturday” does NOT follow the “Second Tuesday”. What this means is that you’ll need to manually setup the Maintenance Windows for each month to ensure that each Window is set appropriate for the given month.
Create Patch-Specific Collections of MWs
The other key item with MWs is that they must be applied to a SCCM collection. We generally recommend creating patch-specific collections and that these collections should align with the organizations outage windows. In addition it is recommended to split up large groups of servers so that you can stagger the deployments to avoid all servers rebooting at the same time. An odd/even collection separation works will for this.
As mentioned in Part 1 of this post, a pilot should be considered MANDATORY for all your server patching. The pilot group should be a representative sample of the production environment and should at least one type of each key server role (Domain Controller, Exchange Server, SQL, etc.). This will mean more work for the initial setup of the MWs and collections. But as my dad would say, “If it worth doing, it’s worth doing right”.
In review here’s what we recommend for SCCM patching and Maintenance Windows:
- Create patch specific collections for Pilot/Testing and for Production
- Use queries to create the collections to ensure that as new systems are introduced – they get added automatically to the appropriate patch collection
- Use a MW that has a deployment date years in the future as a “No Patch” collection for those systems that must be patched manually
- Set MWs for “All Deployments” – we’ve seen issues with multiple MWs linked to a client with different MWs types
- Manually set the MWs to ensure the right timing each month – you can also leverage PowerShell to create these
- When using MWs – the ADR’s “Deployment Schedule” can be set to “As Soon Possible” and let the MW control the deployment time
Now that you have a better understand how all dominos in the Software Update – Rube Goldberg machine line up, go out there and patch with confidence…
Set ‘em and knock ‘em down!