Patching devices, whether you’re an internal IT team or an MSP, is something that takes time, costs money, and honestly isn’t a particularly pleasant job. Different products do different jobs at patching, but no matter what you use, you should always make sure you patch in a timely manner. If we go back ten years, it used to take upwards of 30 days for people to exploit security vulnerabilities, but in recent years, we’ve seen that decrease to 15 days. Because of this, it’s critical that you do a good job at patching your end devices.
With people working remotely, the chip shortage, and a range of other factors, patching hasn’t got any easier. I thought in this post I’d look at some of the best practices for patching that should apply regardless of which platform or tools you use.
It’s important to note that in this article I’ll focus on workstation/laptop patching. If there is some interest, I’ll be happy to write one on server best practices.
1. How often should you patch?
First and foremost, let’s discuss how often you should patch. In my opinion, everyone should be patching weekly. This helps in case you miss a patching window, or if you have failed patches. Some people do still work on a monthly patching schedule, but I feel this puts your business or your customers’ businesses at a higher risk than I would want to tolerate. So weekly is my usual recommendation.
2. What time should you patch?
The other question I get asked frequently is what time should you be looking to run patches? The answer to this depends on the patch management tool you use. Some tools automatically force a reboot during the install window and, if that is the case, then you likely want to patch outside hours (on workstations), but you’ll likely get mixed results at this time with laptops since most people won’t have their laptops opened at night unless they are working or they forgot to shut it down.
Most platforms nowadays have the option to ‘’patch later if you miss your window’’, which will allow you to patch a device the next time it is online. If your end users have recent computers, that’s an option I would definitely recommend.
As far as when to reboot? Let’s first think about why it’s so important to reboot. Some people don’t realize that updates are not technically installed until you actually reboot your computer. This is because files are in memory, some are in use and will be replaced on next boot, etc. Therefore, my recommendation is to give the end user flexibility and have a popup to request a reboot. Based on end-user tolerance, you can either force a reboot, have a popup and ask them to reboot at their own convenience until they do, have a popup that counts down to the reboot time, or follow a mix of those methods. Realistically, this is up to you, but I tend to like to warn the end user and offer them the opportunity to reboot during a preset window, to ensure everyone gets rebooted in a timely manner.
3. When should you approve patches for install?
The next part of the scheduling equation is when to approve patches for install. Some tools will have the option to auto-approve on a delay. If your tool has this, it’s definitely the preferred behavior from my point of view. You can set it to auto-approve all new patches based on severity after five or seven days. This allows the early adopters to find potential issues and then you can decline the patch before it gets installed if you want. If you don’t have that option, I’d recommend you manually approve patches or schedule install to allow a five-day delay on install.
4. How should you schedule patches?
Now that we’ve settled when to patch and when to reboot, let’s discuss the next part: What updates should you install? I believe every update should be installed as long as you follow some simple best practices. For example, anything security-related or critical to stability should be installed early in the process. The decision often becomes trickier when it comes to drivers, feature packs, and other low-priority updates. In my opinion, those need to be installed, but it’s just a matter of deciding when. For drivers, I typically recommend you follow the same rule as you do for regular patches, so delay a week or so. For feature packs or the large semi-annual updates that come out, those can be pushed a bit, but usually after a month or two, those should be rolled out to maintain supportability.
The takeaway here should be to patch often, to be deliberate about it, and to follow some best practices.
One thing that I could also recommend would be to come to one of our patching best practices courses. We do one for N-central and one for RMM. It’s definitely worth the time investment to come and see how people do patching in those platforms to learn how things can be simple and work well for you, especially if you’re having some issues.
I hope this was a bit helpful. I’ll do more in this ‘’best practice’’ series in the future, and if you have any feedback or suggestions, reach out to me directly: [email protected].
Marc-Andre Tanguay is head automation nerd at N-able. You can follow him on Twitter at @automation_nerd. Read more N-able guest blogs here. Regularly contributed guest blogs are part of ChannelE2E’s sponsorship program.
