Getting started with ThirdPatch

ThirdPatch is an RMM-neutral solution for MSP third-party patching with flat-rate pricing and support for custom applications. In this blog, we’ll look at what that means and how to get started with ThirdPatch.

What is the big deal about ThirdPatch?

ThirdPatch is a package-based solution for software management. We’ve talked about this in other blog posts, but the idea is that instead of deploying applications individually, they go into a single shipping box and are delivered as a unit. Packages stack inside other packages, so your client-specific package can include your MSP baseline software – and one command will deploy everything.

ThirdPatch is designed for MSPs. It’s RMM-neutral, so it can integrate with any MSP toolset (ConnectWise, Kaseya, Ninja, etc.). Likewise, it has flat-rate pricing, so at some point (depending on agent count), it offers the best value compared to any competing solution. ThirdPatch also supports over 10,000 applications, sporting one of the largest libraries among its peers.

How to get started with ThirdPatch

If ThirdPatch sounds appealing, the first step is to register for a trial. The tiers are as follows:

Key aspects: This is for basic application deployment only. This is best for MSPs who just need to deploy a wide range of applications without any customization.

Advantage: This is application deployment with custom apps, the ability to nest packages, customize deployment automation, and create reusable logic. This is what most MSPs would want.

Enterprise: This is everything in Pro, plus a reporting portal, API access, and package creation services (where our team creates custom packages for you). This is currently in development, but it is a good option for large MSPs who need reporting beyond what their RMM offers for security and compliance.

Installing ThirdPatch

Once the trial registration process is complete, you’ll receive an email with a tenant URL and a link to the documentation (along with repository access credentials for the Pro and Enterprise tiers). The subdomain of the URL is considered the “slug,” and it’s used in the install command. The install command is PowerShell, and the options vary based on tier. Let’s look at a basic example for ThirdPatch Pro, and cover some high points.
$params = "-clientSlug '<yourMSPName>' -discoverApplications `$true -runCustom `$true";Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://thrdpt.ch/install'));iex "& { $(Invoke-WebRequest -Uri https://thrdpt.ch/pro -UseBasicParsing) } $params"

You’ll notice the slug, along with some basic options. The most important options are “-discoverApplications” and “-runCustom” since they unlock most of the automation MSPs will want. This code block will go into a script inside of your RMM and should be run on all devices you want to manage third-party patching for.

We like to say that “Most MSPs just want to look at a workstation and have its third-party apps update.” While our products aren’t telepathic (yet), the -discoverApplications switch is the next best thing. It compares installed applications against a list of packages, and then adds the application to the list of managed packages. From that point forward, ThridPatch will track the version and install updates when they come out.

The -runCustom switch is a truly powerful option , although that might not be obvious at first glance. This option allows an MSP to run a PowerShell script (custom.ps1 in the repository) during the ThirdPatch deployment. This enables the deployment of global baseline packages, client-specific deployment options, and other configuration settings. For example, if the deployment script sets an environment variable with the RMM client’s name, a package with that name could be installed automatically, simplifying the deployment of standard software: simply upload a package to the repository and run the installation script through the RMM.

A custom.ps1 file that adds a repository, installs custom baselines, and configures the machine to apply patches at startup.

Helpful Tips from ThirdPatch

ThirdPatch can be heavily customized to meet a variety of MSP needs, and as a result, there are a couple of deployment options that will make ThirdPatch much more powerful. The following items can be configured in the custom.ps1 script for the best experience with ThirdPatch.

Automating updates

ThirdPatch is a client, not an agent. What does that mean? Simply put, it only upgrades applications when you tell it to; by default, there’s no automatic deployment. Since most MSPs will want applications to update automatically, we have a package that creates a scheduled task to run upgrades when a machine boots up. To take advantage of this, we’d recommend adding this package to the custom.ps1 script:

thirdpatch upgrade thirdpatch-upgrade-on-boot
With that task in place, Third-party updates will install when a machine reboots for Windows Update, creating a seamless experience for both the user and the MSP.

Adding custom repositories

ThirdPatch installs software from repositories, and MSPs can create their own repositories for custom applications and baselines (see below). ThirdPatch needs the URL of the repository configured as a source so it knows how to find the custom software. Adding the following line to the install script saves the repositories for future use:

thirdpatch source add -n="MSP Client Packages" -s="https://<MSP>.thirdpatch.com/repository/client-specific/"

Installing baseline packages

If your MSP has a package with software/configs/etc. that should be installed on every device, adding it to the custom.ps1 install script is the ideal way to ensure seamless deployment across devices. A simple install command looks like this:

Just make sure the repository for the custom package is configured (see above), and it will work correctly. What’s especially powerful is that if there is ever a future change, updating the package in the repository is all that’s needed – all devices will receive the changes the next time ThirdPatch performs an upgrade.

There lots more

ThirdPatch can do a lot more, but hopefully this is enough to get you started! Please don’t hesitate to contact us if you have any questions!

Picture of Jeremy Oaks

Jeremy Oaks

Jeremy is the founder of Automation Theory. He is passionate about all things technology, specifically in developing creative solutions. He received his bachelor's degree in Computer Science from the University of Wisconsin-Superior, and is also a certified MySQL DBA and penetration tester

ThirdPartyPatching.com is an Automation Theory brand.