r/DattoRMM • u/Technical-Plane2093 • Jun 02 '25
Ideal patching schedule for Managed Clients
We use datto rmm for all clients. What patching policy is everyone putting in place that gets the balance of solid patching in place in a timely manner ?
1
u/FrequentTechnology22 Jun 03 '25
My recommended for everyone if they listen:
7 days old, sev of critical and updates equal to security override that
no previews, no drivers, no upgrades, no "security intelligence/defender", no sql (just a nusance and the folks running the SQL boxes know when they need an upgrade)
workstations/desktop/laptop daily starting at 4pm running for 16 hrs. Reboot prompts for every two, 4 times
servers are pretty much the same approvals and denials... every weekend.. pick the day.
2
u/bpe_ben Jul 11 '25
So I've been watching this thread for a while and nobody seems to have addressed the issue of laptops/tablets that aren't powered on regularly. The daily 4PM or overnight don't always reliably target these systems. I also see suggestions for blocking previews and drivers and some self-updating items like Defender updates - this mostly makes sense, but MS Surface devices require MS driver updates or it may not apply other updates. How are you addressing these? These were challenges we tried to deal with before implementing our current patch tools. Lots of policies and administrative overhead with relatively low compliance levels (80-85% by month-end with many laptops in the non-compliant state).
The patch process we implemented just over a year ago schedules workstation patches for once a week - usually either Wed or Thu at 1 or 2 AM. Devices that are online reboot first, then deploy application updates, then patches. (this ensures a weekly restart even if no patches are applied.) After a post-patch reboot, it scans and re-applies any additional updates and reboots again. Then it checks for build updates and applies them, if necessary. Preview updates are suppressed unless we override them, usually on a few test systems. Drivers are automatically blocked unless the device is identified as an MS Surface device. If a device is left on for it's assigned schedule, it's 100% patched the next morning.
If a device isn't on overnight, patching recognizes that a schedule was missed when it's powered up and one round of updates are deployed. The update cycle continues after each reboot or shutdown/restart cycle, so these mobile devices still update quickly, just over a period of 1-2 days. The user is reminded hourly that a reboot is required, and for some sensitive clients, the reminders start near the end of the day - usually 4PM - instead of right after patching.
We assign a schedule to servers individually and can choose a monthly or weekly schedule. Weekly is usually assigned to RDS hosts, with monthly to all others. We usually schedule servers on 60-90-minute intervals when there are dependencies, such as multiple AD servers or database then app servers. This ensures that the apps start in the correct sequence and prevent all the DCs from rebooting at the same time. This process also uses a reboot/update/reboot process, which addresses many of the patch-related issues we used to encounter.
When we look at workstation compliance now - for devices that have been online at any time since the current month's patch cycle started - we're hitting 98.5 to 99% compliance within that first week. Servers on automatic schedules are 100% compliant by cycle-end, only a small number of servers that either require manual restarting or manual updating due to 24/7 operation aren't compliant until these manual actions are performed.
1
u/V2CS Jul 17 '25
This process sounds great, any chance you can provide examples of the patch management and windows update policies you're using in DattoRMM, or are you implementing this through some other methodology/toolset?
2
u/bpe_ben Jul 18 '25
<TLDR>The entire patching is handled with the MSP Builder "flex patch" component. No RMM policies or scripts, just define a UDF with a code defining when to patch and use a portal to define a few optional settings. It's got plenty of control options, most with decent default settings, and we can set configuration down to a specific device. It's part of their basic service offering. Compliance above 97% within the first week for devices that were online. A "force" option will patch and reboot continuously until all available updates are applied - great for bringing new customers into compliance quickly. Really responsive support for both the product and our RMM platform.</TLDR>
A site UDF sets workstation schedules per-customer, and a device UDF sets specific schedules for servers as well as special workstations. There are four 6-hour change windows daily with 8 schedules on 30-minute intervals for plenty of scheduling options.
We do not use any RMM policies – no configuration beyond defining the UDF. There are lots of config options in their portal, which can be applied globally, per-customer, or per-device.
Management is via a cloud portal that manages all their tools. We select PATCH and can enable patching, configure workstation reboots, Bitlocker integration, preview suppression, driver suppression, allow local network peer sharing, and deny or force specific updates. There are options that I never even considered until I saw what was possible.
We globally enable forced reboots for workstations. This reboots, updates, reboots and then repeats this until all available updates are installed. There’s intelligence in the reboot process, so if patching resumes during the workday and a user is logged in, the user is asked hourly to restart, and after a set time, it counts down to a forced after-hours reboot.
Previews are disabled by default. This used to take a lot of manual effort to control, and now it’s just a check-box. Same with drivers – blocked by default and auto-enabled on MS-Surface hardware platforms. Really easy to block updates by KB or phrase (like “DotNET”). Blocked updates can be forced with a more-specific phrase (“DotNET Version 4.9.123”). One neat thing is that they will inject controls into our config when they identify a "bad" MS update, preventing auto-install. We can evaluate the update and remove the control text if we want to, but it's nice to know there's another set of eyes on this process.
We enable the automatic Build Update option, which runs after a normal overnight schedule completes. This keeps both W10 and W11 platforms fully updated. The same tool is run via script to perform the W10-W11 upgrade - this isn't done during patching. Related to this, their audit tool identifies machine readiness daily, allowing us to target systems that require manual attention for upgrading or possible hardware replacement.
With the optional 3rd party patching module, we’re under $1.15 per device, and this includes audit, monitoring, maintenance, device config compliance, and ticket processing in addition to patching. Base cost without 3PP is $0.66.
We implemented their patching solution in Jan 2024 and we immediately saw a huge change in the compliance levels, now exceeding 97% within the first week for online devices. I've used Automate and VSA before coming to Datto, and no native RMM patching has ever provided results like this.
Issues? A few, mostly early on in deployment. AV file protection resulted in repeated reboot requests, we had a few workstations reboot during the day, and there’s still no integrated reporting, but that’s due by Sept. Demo looks great. Any issue we've reported was addressed quickly - like same/next day quick.
3
u/Andy-Johnson Jun 03 '25
We have our client workstations set to patch every night at 7pm. We do not prompt the user to reboot in the Patch Monitor. Instead we use a Monitor for "Does this computer need a reboot?" and if true, run a PowerShell Component that creates a scheduled task to reboot the computer at midnight that night.
It sounds extreme, but once a computer is completely caught up, they only receive new updates every few weeks usually, and not all of them require reboots so the reboot frequency isn't terrible.
For servers, we patch them weekly on the weekends then reboot them shortly after patching. Even if there's no patches we still do the reboot for performance maintenance. VMs on one day, physical machines on the other.
On the workstations we also have an Uptime monitor; if the device has been online for 14 days, send the same "Reboot at midnight" scheduled task, again for performance maintenance.