Note: The product group has implemented offset scheduling into Current Branch 1802 for ADRs only. For reasons I don’t yet understand they did not include the same for the catalog sync despite this being included in the Technical Preview for the same amount of time.
Too many words. Just give me the scripts.
Back in 2003 Microsoft standardized on releasing security patches on the second Tuesday of every month at roughly 10 AM Pacific Time. In doing so they gave birth to Patch Tuesday. In the years since they’ve tried a few times to suggest that Patch Tuesday isn’t a thing anymore but they clearly haven’t given up on it. Just a year ago, Michael Niehaus’ post clarifying the new cumulative update model referred to Tuesday 15 times. So it’s understandable that businesses worldwide have aligned their patching cycles around this most glorious day of the month.
The Problem
From the start, the poor Aussies and a few other countries where screwed. You see … by the time Microsoft has released patches it’s already Wednesday in certain places of the world. You might think to just invent Patch Wednesday and align yourself to the second Wednesday of the month. The problem there is, the second Wednesday doesn’t always come after the second Tuesday. Go ahead … open a calendar and see for yourself. Only last year did Microsoft throw them a bone and release a script to work around this issue: Scheduling Software Updates to Run on Patch Tuesday. Further, there isn’t a single weekday that will always have its second instance occur after the second Tuesday.
Who Cares? USA! USA! USA! We’re #1!
Easy there .. settle down Tex. In the past it was rare for Microsoft to stray from the regular schedule. Doing so was usually the result of an out-of-band patch or just coming in late that morning. With the move to cumulative patching however this has become rather frequent. In particular, the cumulative updates for Office 365 and Windows 10 are not reliably released on Patch Tuesday. This isn’t just for some timezone on the other side of the world either … it’s not even Tuesday in Redmond when some poor soul is pulling an all-nighter to get updates out the door. If you don’t believe me, go look at the released dates in Configuration Manager:
At this point you might think it’s not a big deal and you can just release them next month. Assuming that’s approved by your security department then great. However, if you’re following Microsoft’s operational best practices for software updates you’re creating a new software update group each month. This has led most organization to deploy the patches released in the last month or maybe the last week or two. The last month filter for the ADR simply subtracts one from the current date’s month. For example, Patch Tuesday for November 2017 is the 14th making one month of updates evaluate to October 14th which was four days after that month’s Patch Tuesday. Any patches released between October 10 and October 14th would not be deployed if one month of updates was selected in the ADR. Given the release timings for Office 365 shown above it will miss the Office 365 Semi-Annual Channel updates released the Wenesday morning after Patch Tuesday at 7:27 and 7:30 AM Pacific Time.
Fine. OK. Stop Talking. How Do I Fix This?
There’s a few strategies for avoiding the problems above. Which you choose will depend on your particular situation.
Patch Tuesday: Rest in Peace
The first option is to just admit the death of Patch Tuesday, work through the five stages of grief, and move on with the rest of your life. Run your synchronizations and ADRs weekly or even daily and just continually roll out patches. This solves all the problems I outline above. If your organization isn’t really testing patches beyond ringed deployments then you should seriously consider this option. Otherwise, you might need to significantly rework your organization’s patch testing strategy since an update can come at any time … maybe even just a day after the last round of testing. Apart from that the only downside is that the more synchronization and ADR running you do the higher the chances are that the law of averages bites you and one of them fails. Not a deal-breaker but you certainly need to closely monitor these on a more frequent basis.
Forget It, I’ll Just Do It Myself
Another option is to just skip all that fancy scheduling stuff and go run the synchronization and ADRs yourself. After all, it should only take a few minutes every month. Beyond just a general distaste we should all share for manual and repetitive tasks there’s another issue here. If the availability and deadline dates of your software update deployments matter to you then you must run your ADRs at precise times without fail. If you don’t then you’re stuck modifying deployments to fix the timing issues. I don’t trust myself let alone my organization’s administrators to have that kind of discipline.
If you go this route you will want to make sure your ADRs are configured to grab two months worth of updates to avoid the selection issue I described above.
Patch Wednesday: It’s alive. IT’S ALIVE!
The last option is to make Patch Wednesday, or any offset from Patch Tuesday, a reality. This isn’t a new or radical idea. Jason Sandy’s has stated that he made a Desired Change Request for this over 7 years ago now. A UserVoice item posted in July 2015 is currently in 26th place at the time of writing with 285 votes: Software Update Patch Tuesday Scheduling. Please, go vote for it. Lastly, I submitted this for the MMSMoa 2017 hackathon and it absolutely crushed it in the Twitter polls:
The final list of projects for #MMSHackathon at #MMSMoa this week. Which of these #SCCM projects would you like to see him coded and demoed?
— david james (@djammmer) May 15, 2017
Which of team @CoretechGlobal's other #MMSHackathon projects would you like to see? #configmgr #SCCM #MMSMOA @agerlund @JakobGSvendsen
— david james (@djammmer) May 15, 2017
Despite the enthusiasm and even a Twitter follow up from our dear leader confirming that this would get some love … it hasn’t. As of Configuration Manager Current Branch 1706 there’s no such feature or ability. And really, the logic here just isn’t that hard. And I’m not just saying that … I know this because I wrote exactly that logic and have released the resulting scripts on the TechNet Gallery:
Run these scripts with the WeekofPatchTuesday parameter and they will only execute when ran within 7 days after the current month’s Patch Tuesday. That allows you to run these scripts weekly via Task Scheduler. If you go this route you will want to make sure your ADRs are configured to grab two months worth of updates to avoid the selection issue I described above.
Here’s what that looks like in my environment:
Name: Invoke-SoftwareUpdatePointSync
Trigger: Weekly at 7:00 PM every Wednesday of every week, starting 1/1/2017
Action: Start a Program
Program/Script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add arguments: -executionpolicy bypass -noninteractive -File “\\#PATH TO SCRIPT#\Invoke-SoftwareUpdatePointSync.ps1” -WeekOfPatchTuesday
Name: Invoke-AutomaticDeploymentRules – Workstations
Trigger: Weekly at 11:00 PM every Wednesday of every week, starting 1/1/2017
Action: Start a Program
Program/Script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Add arguments: -executionpolicy bypass -noninteractive -File “\\#PATH TO SCRIPT#\Invoke-AutomaticDeploymentRules.ps1” -WeekOfPatchTuesday -Name “Windows Workstations Patches”
There’s a mistake in both example scheduled tasks.
For the SUP sync task:
“\\#PATH TO SCRIPT#\Invoke-SoftwareUpdatePointSync.ps1”
Should read:
“\\#PATH TO SCRIPT#\Invoke-DGASoftwareUpdatePointSync.ps1”
And for the ADR task:
“\\#PATH TO SCRIPT#\Invoke-AutomaticDeploymentRules.ps1”
Should read:
“\\#PATH TO SCRIPT#\Invoke-DGAAutomaticDeploymentRules.ps1”