Over the holiday break, I have been enrolling devices into our Remote Monitoring & Management (RMM) tooling and seeing what quick wins could be realised.
One of the first things we do after installing the RMM agent across an environment is to allow the ‘Detect Only‘ patch management task to run. This task runs twice a day and scans both Microsoft Update but also a huge array of third party application providers such as the common applications that get installed and seldom maintained thereafter.
The danger is that a third party application may have a security vulnerability identified and require urgent attention that otherwise wouldn’t be part of the monthly Windows Update process.
The above image shows a sample Windows Server suggesting a new version of Oracle JRE and Adobe Acrobat DC is needed. The far right hand column saying ‘No Approval‘ is because we are in ‘Detect Only‘ mode.
After a short while, a report can be generated within the RMM tool which will show a list sorted by server the recommended updates across various categories:
- Applications (yep, it can push out applications too!)
- Critical Updates
- Definition Updates for Microsoft Defender
- Drivers
- Feature Updates
- Security Updates
- Third Party Updates
- Tools
- Update Rollups
- Updates
- Upgrades
At this point we know how far out we are, or rather how deep a hole we have to fill in with updates.
By default, everything is categorised as ‘Ring 1’, we can tweak this on a per device basis within the RMM tool to be Ring 0 (earlier), Ring 2 (later), Ring Daytime (Backup server, to reboot in the day rather than the night), or Ring Manual (those which need manual help with their updates). This is as simple as adjusting a drop down menu to split application member roles between rings, identifying those systems which may be canary builds, or making sure that backup servers are aligned to day time patching.
Once the assets are updated to the various rings, we can remove the environment from the ‘Detect Only‘ rule and assign them to each of the ‘Ring’ updates. We assign each environment to each of the rings so that new servers can be added to each ring without having to touch the overall patching management configuration.
Once this is done, the servers will refresh their configuration and follow the defined configuration(s).
| Window Name | Frequency | Description |
| Patch Detection Window | Twice a day | Twice a day is probably often enough to check for updates, this could be more frequent if desired. |
| Patch Download Window | As soon as a patch is released | We have this configured to automatically download when it detects it needs a patch, this is good because it saves the system waiting around to download it when the ‘install time’ comes along – but of course could also just as easily say ‘wait until 4pm each day’ |
| Patch Installation Window | Evenings (every, or specific) | This is where we say ‘when’ it can kick off the install, for endpoints something like 3pm is good, for servers of course later on in the evening. Worth noting here we can break down the installation window to say ‘well if its critical just do it’ but if its anything else ‘wait until 3pm’ Important to remember this is scoped to groups (Rings) too so ‘just do it’ means just to those devices not the whole estate. Really good way to smoke test MS updates before bad things happen! |
| Patch Reboot Window | Evenings (every, or specific) | This is when we say when it’s allowed to reboot a device, we typically provide a 3-4 hour countdown that can be postponed by the user so it doesn’t ruin their day but still gets the job done. |
This looks like the below:
On a device by device basis it is possible to see a a break down of patches needed to be installed and an overview:
The last part of the setup is to configure reports to be sent each morning (and then reduce to weekly/monthly if desired) showing a missing patch summary to see that servers are updating properly.