tl;dr: If you choose option “3 – Auto download and notify for install” for your WSUS Group Policy, you can take any advanced Task Scheduler like PDQ Deploy in combination with ABC-Update to install Windows Updates scheduled the way YOU want it to be!
Prologue, where is my problem?
First let’s take a look at the options Microsoft offers us and why I refuse to rely on those. If I’m not completely mistaken the only Policy to choose when to patch Windows Updates has been “Configure Automatic Updates” since ever:
There are 4 options with the ADMX files from Windows 10 1607:
| 2 – Notify for download and auto install | No option, you have no influence about the when |
| 3 – Auto download and notify for install | No option, the files would be cached by the Server but never installed |
| 4 – Auto download and schedule the install | That looks promising, the server downloads and install when you want |
| 5 – Allow local admin to choose setting | No option, as soon as you administrate 10+ servers you will loose track |
So if you choose option 4, you can take control of the day and hour:
But whats what? You can only plan on a weekly base. No monthly option. Mh ok. And what if you need to stagger updates? Maybe your SQL Server needs to reboot before the Application Server? Then you either have to build different Organizational Units (OUs) in your Active Directory, each with a different GPO attached with a different time defined, or you link several GPOs to the same OU and work with Advanced Delegation.
For me, this is absolutely no option! I personally think that this is way to complicated and error-prone.
Act 2: A promising utility
What I needed was a way to trigger Windows Updates by an external utility without the need to use the built in GUI. And an advanced Task Scheduler, but I guess the Windows Server Task Scheduler could also work.
We already have such an advanced Task Scheduler, as we use PDQ Deploy to patch nearly every runtime and application on our Workstations and Server. (i. e. Java, Flash, Notepad++, FileZilla, WinScp, …)
I already knew about BatchPatch as a way to control Windows Update via command line, but it just didn’t fit me. (But you could of course take a look!)
But I discovered another tool which fitted perfect: ABC-Update
- It’s free!
- No install needed, just copy and paste
- It’s command line based and has an awesome syntax
- It can install -> reboot -> search for updates -> install -> reboot -> search for updates -> and so on until there are no updates left, all with one command!
- I writes beautiful log-files
- It can report to you via E-Mail
With ABC-Update you get the updates exactly when you want them, and can also define max reboots, use filtering options to select updates based on patch dates, KB Articles and update categories.
The tool has a GUI and a command line version and this enable you to script update operations also if you have that need. Because you can also call the tool from a command line it is well fitted to be used with software distribution tools like ABC-Deploy, MS SCCM and others.You are in control. No more waiting for Automatic updates.
Tested OK from Windows XP/2003 and upThis gap between what Microsoft is offering out of the box, and what many admins really wants is what the ABC-Update tool is made to fill.
Suddenly everything fitted together. So enough with the talking, on to the real-life examples!
Solution, I no longer have a problem!
First of all I built two ABC-Update.exe command line strings which fit all my needs:
%WINDIR%\ABC-Update.exe /A:Install /S:WSUS /R:10 /T:Software /Q:IsInstalled=0 AND IsHidden=0 /Log_Append:c:\WSUS.log /Exit:Restart %WINDIR%\ABC-Update.exe /A:Install /S:MSUpdate /R:10 /T:Software /Q:IsInstalled=0 AND IsHidden=0 /Log_Append:c:\WSUS.log /Exit:Restart
%WINDIR%\ABC-Update.exe |
Call the binery from a path you placed it beforehand |
/A:Install |
We choose Install as the Action |
/S:WSUS || /S:MSUpdate |
We choose WSUS or Microsoft as the Source |
/R:10 |
Should we continue after a Reboot and if true how often |
/T:Software |
We only install updates from the Type Software, no driver |
/Q:IsInstalled=0 AND IsHidden=0 |
The search Query, only non-installed and non-hidden software |
/Log_Append:c:\WSUS.log |
Write a Log and keep it forever, no overwrite |
/Exit:Restart |
Make sure there always happens a reboot when the program Exits, so we keep the boot order of our Windows Servers |
Second, the GPO. As we don’t want Microsoft to take control, we set the following GPOs at least. This is extremely important, as this settings dictate the Windows Server to always cache, but never install Updates. And this is what we want, cause taking back control over Windows Update is our goal.
| Allow Automatic Updates immediate installation | Disabled |
| Always automatically restart at the scheduled time | Disabled |
| Configure Automatic Updates Configure automatic updating: |
Enabled 3 – Auto download and notify for install |
| Specify intranet Microsoft update service location Set the intranet update service for detecting updates: Set the intranet statistics server: |
Enabled http://wsus.int.corp.de:8530 http://wsus.int.corp.de:8530 |
| Enable client-side targeting Target group name for this computer |
Enabled WinServer |
Third, the Task Scheduler. As Microsoft Group Policy didn’t offer me what I needed we switched to PDQ Deploy, but as I said, any Task Scheduler should do it. For us, two things were really important:
- We want to patch AND reboot every Windows Server in each customer Domain once per month
- The Server has to reboot in the correct order, to result in a working configuration
DC -> SQL -> Fileserver -> Application Server -> XenApp -> etc
This resulted in the following:
I hope I could give someone an inspiration about how to deal with Windows Updates beyond the possibilities Microsoft offers us. If you have any questions, please leave me a comment.
