Patch Management – DattoRMM

Patch Management – DattoRMM

Patch management in DattoRMM can keep the operating systems on your managed Workstations and Servers up to date. This is likely one of the core tasks of your MSP, and something that often gets overlooked.

A couple assumptions

When designing your Patch Management Policies, there are a couple assumptions that you need to keep in mind.

Never forcefully reboot a workstation. There is always that user who keeps a dozen documents open and will raise a stink if he/she has to open them again. This person is vocal and always introduces the type of work that distracts you from getting real work done. As a result, I make it a rule to not forcefully reboot a workstation. This by itself will result in a bunch of workstations not getting updated, so I rely on Nag messages. I would recommend talking to your legal professional every now and then to ensure that its enough to keep the liability on the users. I expect that at some time in the near future it will cross a line where the risk of a user losing some work is less risky than not forcing reboots after updates.

How long to wait after an update is released. I currently wait a week, but you may require less or more. Check for any compliance requirements.

Feature Updates. Should you force them before you are required. Users hate change, but change is inevitable. You will have to have that conversation with the user either way, so you are only delaying the inevitable if you put if off too long.

Driver updates? For Dell, Lenovo, Microsoft Surface and HP workstations, you can install the driver and firmware updates right from your patching policy.

If you have neglected patching for some time and are catching up, you will likely loose %1 of them. Sometimes patches cause the operating system to fail to boot. Easiest way to get them back to your standard is to go run through the Workstation Wipe/Reload, Workstation Deploy, and User Workstation Setup SOPs. It is some work now, to save plenty work in the future.


Servers will have to be rebooted from time to time, and never let a client tell you otherwise. We get some control over when patching reboots happen. With that in mind, you will likely want to spread this out over the course of the month in case a patch has adverse effects on a server. For this reason, I split my servers into 4 groups, each patching on subsequent weeks. Microsoft releases patches on “Patch Tuesday”, the second Tuesday of the month. I run Server Patch Group 1 on the 3rd Tuesday. If there is going to be a surprise outage caused by a patch, Wednesday seems like a good day for that. I do force reboots on servers because most clients prefer server reboots to happen after hours. If you have a large enough service window, rebooting servers before patching will reduce failed patches and other issues.

Should you install driver updates on servers? If your goal is to patch security flaws, then yes. If you want to dip your toes in the water before you jump in, approve drivers for just Server Group 1 for a while before rolling it out to all server groups.

To Be Continued…

Next – Setup Workstation Patching Policy