Patching Automation Best Practices—Part 2

If you missed the first part of this series, I recommend you go read it here.

Here’s a quick recap: this is a two-part series on patching best practices. It will cover all aspects of patch configuration and discuss best practices along the way, as well as what other MSPs do. It will not cover how to do this in RMM, as we will be releasing courses for SolarWinds® RMM and N-central® soon on patching best practices that will also cover how-to do that.

In part 1, we talked about:

  • Finding new patches
  • Approving patches for install
  • Downloading the patches

In part 2, we will look at:

  • Installing the patches
  • Rebooting the computer

Installing patches

How you install patches is quite straightforward. Here is a short list of what I see partners do:

  • Install patches at the same time once a week
  • Install patches at the same time daily
  • Set up groups and install patches at different times
  • Install patches manually
  • Install patches monthly or quarterly

On workstations/laptops, the vast majority of partners I talk to do patch installs weekly, either one evening during the week or over the weekend. Some will do multiple schedules to catch devices that are not often online. On non-server devices, our recommendation is to do it at least weekly on a fixed schedule. On devices where installs fail often, you should consider setting up on a more aggressive install schedule if needed.

On servers, we typically see a weekly or monthly schedule and some partners will go further and set up install groups (patch group A, B, C, etc.) and install patches Friday night, Saturday night, or separate by a few hours. Our recommendation would typically be to patch weekly if you can, or at least monthly if your customer doesn’t allow you to do it weekly. We would also advise you use groups for networks with multiple servers with similar roles, like domain controllers, SQL servers on a cluster, etc. You don’t need to do them on separate days but we would recommend you at least separate them by a few hours, if possible.

Rebooting endpoint devices

Rebooting is perhaps one of the most ignored parts of patching. However, rebooting devices is critical for a variety of reasons. One of them is a situation I have lived through in the past. Back when I used to maintain servers, I remember we had one running for months without ever being rebooted because the updates to software or OS never needed a reboot. However, at some point it needed a reboot and people were terrified of doing it because they were worried it might not come back up. In the end, it did freeze up and needed some minimal troubleshooting (we got lucky), but this could have been avoided by rebooting the device more often. Updates, even if they don’t require reboots, should still recommend a reboot (they usually recommend it, but don’t enforce it).

My recommendation is therefore to force a reboot after each patch window, whether the device needs it or not. Yes, this creates some minimal downtime on the device. However, if the device does not come back up you typically know the issue happened since the last reboot, and if that reboot was one week ago you have far less troubleshooting to do than if it was six months ago.

Since lots of patches don’t require a reboot anymore, I recommend setting up a scheduled reboot vs. a patch reboot, if your RMM has the option for it.

If you want to learn more about patching, and I hope you do, please make sure to join the patching course that will be offered as a live event early in Q3 2020.

If you’ve created an automation policy and would like to share it with the community, please feel free to email me at [email protected]

As always, don’t forget to go look in the automation cookbook at if you’re interested in other automation policies, script checks, and custom services.

Marc-Andre Tanguay is head automation nerd. You can follow him on Twitter at @automation_nerd

Want to stay up to date?

Get the latest MSP tips, tricks, and ideas sent to your inbox each week.

Loading form....

If the form does not load in a few seconds, it is probably because your browser is using Tracking Protection. This is either an Ad Blocker plug-in or your browser is in private mode. Please allow tracking on this page to request a trial.

Note: Firefox users may see a shield icon to the left of the URL in the address bar. Click on this to disable tracking protection for this session/site