What if you could run a single command on a PC and all the apps would always be patched? It sounds like a pipe dream, but you might be able to get close if you organize your packages the right way. This guide will cover design principles for optimal organization and utilization of package-based systems.
DRY is a programming concept, and it's rather simple: if you wrote code for something, don't write duplicate code that does the same thing. The idea holds true in package management – if you need to push out a software agent (EDR, DNS filtering, etc.) that has a client-specific install token, should you create one package per client, or a single package that takes a parameter for the token? Obviously, the package with the token is the optimal choice.
This can pay huge dividends when bad circumstances arise. Remember the CrowdStrike bug that was bricking workstations? If you have a single package with the installer, all you need to do is update that single item, push it to your repository, and tell your devices to update. That takes ~10 minutes, but it would be 10 minutes per client if the package didn't accept the parameter (not the type of time you want to spend in a crisis).
If you've ever shopped online, you know that the big box that gets delivered will likely contain several smaller boxes. Structuring software packages in the same way can help with efficiency. Let's look at an example.
Let's say A+ MSP has a client named Acme, Inc. that needs the following software installed: Google Chrome, Foxit PDF Reader, Office 365, and Google Drive. Let's also assume that the MSP is a Dell distributor and likes to install 7-Zip and PowerShell Core for additional scripting. You could run the following command:
thirdpatch install googlechrome fixitreader office365business googledrive 7zip dellcommandupdate powershell-coreThat would deploy all the software, and you could move on to your next ticket. However, you could make it reusable and more powerful with what we call meta-packages.
If you split the MSP tools into a package called aplusmsp-base and the client software into a package called acmeinc-base that contains aplusmsp-base, you can accomplish a couple of things:
acmeinc-base meta-package and tell thirdpatch to upgrade the package.aplusmsp-base should update it across all devices everywhere if they use their meta-package across all their clients.We have a template for packages (and meta packages), and you can find them here: [TODO: link].
Pro Tip: if you deploy ThirdPatch via an RMM and you followed the /quick-start guide, then you can use the custom install option to run thirdpatch install $env:deviceIdentifier1-<slug> to install the meta-package for a particular client.
Just like a physical box can hold a variety of items, so too can a package hold a variety of things. Remember, it runs a PowerShell script and can contain additional files, so it could: