MSP Third-Party Patching: packages are the way of the future

 

For MSPs, third-party patching is a task commonly performed, but it’s typically not a point of emphasis. This is due to some poor tooling and the fact that it’s usually a peripheral task. Most MSPs have bigger fish to fry, and don’t spend a lot of time proactively policing versions of Adobe Reader.

This leads to patching tools for MSPs that aren’t great fits. MSPs typically have a lot of edge cases (such as workstations that control old equipment, which require older versions of apps for legacy compatibility), and it can be challenging to use a patching tool coherently when different clients have conflicting requirements.

Likewise, since third-party patching isn’t a main selling point for MSPs, the vendor tooling isn’t stellar. It is typically an RMM integration that has a limited application library, or yet-another-agent to install on workstations, and an additional configuration process.

Here at ThirdPartyPatching.com, we’re creating a better way for MSPs to do third-party patching.

What is package management?

Think about IKEA furniture – how does it work? You receive the parts, hardware, and assembly instructions – all bundled together in a box labeled with the contents and model information. It can be transported anywhere, consistently assembled, and it’s repeatable – getting another box with the same markings will result in the same output.

Software packaging is very similar. All the needed components (installers, configuration files, install scripts, etc.) are bundled together, uploaded to a central location, and then installed on end devices. The version information is tracked and can be checked against the central repository to determine if an update is available. The software can then be installed, upgraded, or removed in a repeatable manner.

This model can be a big win for MSPs.

Why do MSPs need package management?

Most MSPs have multiple methods of managing software deployments. Common applications, such as browsers or PDF readers, are typically part of an existing integration, while LoB applications are usually handled elsewhere. This creates disjointed processes, where a PC requires the automated setup to be run on it, followed by manually triggered actions before the device is ready – akin to an IKEA product that requires you to buy screws separately to complete the assembly.

Using a package management framework for third-party patching enables MSPs to deliver all updates through a single mechanism and organize them in a logical manner. For example, an architecture firm will have normal office workers, along with architects who need drafting software. In a package management system, you could have two packages – the office worker package and the architect package (which would contain the office worker package, since architects also need browsers, office suites, and PDF readers). Then, with a single CLI command (from any RMM tool), all the associated software for that role would be installed on the endpoint.

 

As in the example above, packages can be nested within other packages – much like online shopping orders, which contain smaller product boxes placed inside a larger shipping box. MSPs can deploy the large shipping box with the smaller packages inside, but updates to the individual software packages (like AutoCAD) can be managed individually after the initial deployment. This means that a browser delivered in the base software package can be updated independently of the other software in the base package by the package management system.

This level of granularity is particularly helpful for MSPs, who often need to manage a wide range of edge cases. Packages can be pinned at specific versions, allowing updates to be paused if it’s known that the latest version of an application has issues. Likewise, in integrated scenarios, it’s possible to package an application, its browser extensions, and helper software together.

How can MSPs move to the next level?

Aiming to build a better mousetrap, we’ve created ThirdPatch: an end-to-end solution for package management for MSPs. Our offering includes a package client, deployment automation tools, a package ecosystem, repositories, and MSP-focused consulting and support.

Out of the box, ThirdPatch supports over 10,000 applications, and the Pro and Enterprise tiers allow for custom packages (either new applications or meta-packages for deployment automation as discussed above). Likewise, our deployment automation is designed to integrate with MSP tools and enable one-time deployment with zero-touch, ongoing patching thereafter.

We specialize in the MSP industry, offering consulting services to help jump-start your onboarding process and assist with RMM configuration. Start a trial today, and experience the difference for yourself!