Top 3 Proven Patch Deployment Methods for MSPs

[et_pb_section bb_built=”1″][et_pb_row][et_pb_column type=”4_4″][et_pb_text _builder_version=”3.0.85″ background_layout=”light”]

To patch or not to patch, that is the question. No question about it, patch. And patch often. But wait, my application will not work with that new .net update! So, the struggle between security and operations continues… Many engineers would say that if it’s not broken, don’t patch it. This is a very dangerous practice as more and more security breaches are designed to harvest data or resources while not disrupting the network. While in the past, the intent was to bring the network down, cyber hackers now zero in on the company’s network resources and end users with the goal of data mining. Hackers can and will take advantage of these security flaws if patching is not done in a timely manner. As you can see, patching is extremely important, and if neglected could put your systems and your clients’ systems at risk. This post explains the best practices so you can choose the right patch deployment method for your specific requirements.

[/et_pb_text][et_pb_image _builder_version=”3.0.85″ show_in_lightbox=”off” url_new_window=”off” src=”” align=”center” always_center_on_mobile=”on” use_overlay=”off” force_fullwidth=”on” show_bottom_space=”on” animation_style=”slide” /][et_pb_text _builder_version=”3.0.85″ background_layout=”light”]

Manual Deployment

The first method is the old school way; manually deploying patches. Many small managed service providers continue to use this method today for many reasons. The main reason would be the ease of getting into the market. It has very little upfront cost and only requires labor to deliver. This method is very labor intensive and is a slow method of patching for a small managed services provider. Applying patches in this way requires accessing each endpoint and conducting updates as needed but is not a method that allows a larger managed service provider to scale to a larger size or market. However, even with a large managed services provider, there remains those “troublesome servers” that will always remain within this patching strategy. This is primarily due to custom applications and other dependencies that will make patching a challenge.

Another issue with this method is that it is pretty much “patch and pray”. You are relying on the vendor to release known good patches and that they won’t bring the network down.  As a result, labor spent on testing patches is not cost effective due to the many different systems configurations and the requirement of having those resources available for said testing. Combine that labor spent on testing with the labor spent to implement the patches and things become cost prohibitive for any managed services provider with more than just a handful of clients.  Most of your hard cost of goods will be in labor and will increase steadily as the endpoint base increases.


  1. Low to no cost for system
  2. Very customizable to accommodate specific client needs


  1. Labor intensive and requires larger workforce
  2. Time consuming when deploying patches
  3. Less scalable with limited potential for growth
  4. More risk in applying a “bad” patch

Decentralized management requiring additional resources

[/et_pb_text][et_pb_text _builder_version=”3.0.85″ background_layout=”light”]

Third Party Patching Systems

The second method would be to install a third-party patching system that would automate the installation of patches. There are several third-party patching systems to choose from, such as Microsoft SCCM, GFI LanGuard and Kaseya. However, this is a decentralized management method since administration of the system is conducted in each client’s environment without the single pane of glass to manage multiple clients.  Testing is still required for the proper patches to be installed. However, this method does eliminate the labor for applying patches individually.  Many venders will have a tiered pricing structure as additional third-party patching systems are deployed. With each new client, there will be a dramatic increase in price. Many of these third-party systems are low cost for the software however they do require network resources and still require a labor force to implement, administrator and remediate.


  1. Decrease time in deploying patches with scripted patch delivery
  2. One-time cost of software and hardware


  1. Decentralized management requiring additional resource
  2. There is no prior testing of patches before deployment
  3. Requires network resources as each client’s location

[/et_pb_text][et_pb_text _builder_version=”3.0.85″ background_layout=”light”]

Cloud-Based Patch Deployment System

The last method is to deploy a cloud-based patch deployment system. Many current managed services providers remote monitoring and management (RMM) platforms such as Labtech, Continuum and Kaseya provide this service as part of their bundle of services. Some vendors such as Kaseya just provide the centralized delivery of the patches, while other vendors such as Continuum provide additional value by performing quality testing of the patches prior to implementation. This method is a centralized method that allows a MSP to have centralized management for patch deployment policies for multiple customers. This allows a  managed services provider to maximize growth with less labor since the function is driven from one pane of glass and is well automated. The burden of testing of patches on a massive scale is shifted to the cloud-based vendor and away from the managed services provider. This reduces the  managed services provider’s labor force needed to maintain this service offering because only after the patches pass the quality assurance testing of the servicer are they deployed to the endpoints.

Like third-party patching systems, many cloud-based patch deployment systems are price based on tiers. In this method, overall costs will normally decrease as the managed services provider enters higher tiers.  In short – As the managed service provider grows and scales, the cost of this service decreases. This method will generally benefit the managed services provider with lower costs while maximizing the use of their system.


  1. Centralized management of patch deployment
  2. Many services have patch testing prior to deployment
  3. Low labor cost as a smaller workforce is needed
  4. Less time consumed in testing and deployment


  1. Higher cost and is normally a monthly expense

Less customization for specific client needs.

[/et_pb_text][et_pb_text _builder_version=”3.0.85″ background_layout=”light”]

In summary, each method does have its advantages and disadvantage.  Which method that you choose will be the method that best fits your business model.


Altaro O365 Backup for MSPs
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

Leave a comment

Your email address will not be published.