I’ve been working with a lot of partners remotely in recent months. Patching is one of the topics I’ve heard partners express the most interest in lately. It seems people want to get better at patching—which I’m all for. I get a lot of questions about automating patching, so I’ve been working on creating a patching bootcamp. While that’s in the works, I’d like to discuss patch scheduling with you.
A common struggle I see with patching and scheduling involves the numerous moving parts which must be scheduled in a logical manner. Depending on your remote monitoring and management (RMM) solution, you may have to schedule the following tasks:
- patch scan/detection
- pre-downloading (caching)
- approving patches (manually or automatically)
- installing patches
- rebooting after patching
I’ll cover the first two in this article and the last three in my next blog.
No matter which RMM you use (or even if you install patches manually by logging in to each device) you’ll need to perform at least some of those tasks.
This is something IT professionals schedule in a variety of ways based on needs and concerns. I remember patching on Windows 7 and earlier was strenuous on computers. In some cases it made the OS slow and nearly unresponsive. This concern is mainly a thing of the past now due to improvements in Windows 8, 10, and Windows Server. The Windows update engine is much more optimized and performant. This means you can schedule patching detection daily (or more often if required) without too much risk of performance issues.
You may think weekly or monthly patching is enough and wonder why you should consider daily or even twice-daily patches. There are three main reasons to increase the frequency.
- Visibility—it’s nice to know what is needed in near real time whenever the customer calls.
- Emergency patching—like we saw in January 2020 and some patches had to be installed outside of the regular schedule.
- Built-in Microsoft AV—they release updates very frequently. If your customers use this solution, you should install the updates as they come out. Otherwise, it would be like avoiding updating third-party AV products, which is generally a bad idea.
I recommend scanning twice a day whenever devices are online. And while I agree twice per day is overkill, I do like that it allows you to catch different people working on different shifts. If you detect at 10 a.m. every morning, but someone’s offline at that time since they work the afternoon or evening shift, then you won’t catch them. For this reason, I typically recommend you detect at 10 a.m. and 2 p.m. on all devices (including servers, workstations, and laptops).
The second task, if supported by your RMM product, is to pre-download or cache patches. Again, depending on your RMM product, you may or may not be able to do this. You also may or may not be able to schedule it at night as the device typically needs to be online to trigger the caching process. If that’s the case, I usually recommend scheduling pre-caching close to lunch time to avoid potential spikes in network traffic around mid-day. For workstations and laptops, 11 a.m. tends to be a good time. Since servers are usually online 24/7, you can schedule them for some time at night like 11 p.m. or 1 a.m. (as long as you avoid stacking it on top of other bandwidth-intensive tasks like backing up to the cloud and remote site syncs.
In my next blog, I’ll cover the remaining tasks, including patch approval, patch installation, and rebooting after patching.
If you have thoughts or suggestions about this post, please reach out to me directly at [email protected] or on twitter at @automation_nerd.
Automatically monitoring for the Vollgar Miner malware
I’d like to quickly showcase an automation policy/monitoring service we built on the recommendation of our Head Security Nerd, Gill Langston.
The Vollgar Miner malware is a malware targeting SQL servers, which can be on some of your customers’ devices without your knowledge. We built a detection script you can set up as a custom service. You can deploy and use it on all your customers’ SQL servers and monitor in case any gets infected. Here is the link to the policy:
If you have 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 look in the Automation Cookbook 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.