Best Practices in 2015: Modular Deployment & Patch Management

Whether you have already deployed Macs in your organisation or you are trying to work out how to do it, one of our recommendations is to adopt a solid deployment and patch management approach from the start.
This topic breaks into a number of smaller methodologies described in one of our earlier blogs.
When you are starting to look at refining your deployment processes, there are a few things to take into account:

  • To get the Macs initially setup and useable you will need the ability to deploy your line of business apps
  • You will need to be able to patch this line of business apps and other parts of the system

It is worth pointing out that the time or money invested in improving these systems is often relative to the size of organization.  If you are a startup with 1 or 2 employees you probably aren’t going to rush into setting up a deployment system, but as your business grows, the time lost manually setting up machines and the risks associated with not patching them will grow.
Deploying line of business apps
The first recommendation is to set up a system that can deploy apps from a central point to each of your organisations Macs.  There are lots of different tools available and setting one up will mean you don’t have to touch each computer when you want to deploy new apps.
The key idea is to add the app installers to the deployment server and then “enroll” each computer so they can receive the packages.  You can then choose whether the deployment happens automatically or if they are presented to the user in a self service interface.
What tools can you use?munki guide
There are lots of options on the server side to accomplish this including Munki, Casper, Bushel, Absolute Manage & FileWave to name a few.  Our preference is either Munki or the Casper Suite.
The choice of one over the other will depend on budget, and the technical level of the operator (Casper has a slightly easier learning curve and being a commercial product, is backed by a thorough training programme).
For both of these tools and other programmes, the basic concept involves packaging each of your apps, adding them to the server and then configuring them to be deployed to the Macs.    The level of difficulty will really depend on the app you are packaging.
In some cases, if you don’t need any customisations made to the app, you can just drop in the installer straight from the vendor.  In other cases, strange licensing / activation processes, per user customisations and additional settings can make the packaging more complex.
volume purchase programme
A Note About The Mac App Store
Getting apps from the Mac App Store is a little different.  Many of you will have used the App Store to purchase individual apps and while you can still do that with your business computers, it can be more efficient to sign-up for a VPP account from Apple and use a deployment tool.
There are two methods we have been using recently to get the apps from the app store and onto the Macs.  The first is to re-package the app into an Apple installer file and distribute with a deployment server like Munki or Casper.
The main benefit is a zero-touch process for the end-users.  You can silently push the apps to the devices without user interaction, removing the need to manually configure each machine.  The downside is that updates for these apps are tied to the original Apple ID so you will need to look after the patching as well.jamf software
The second app store technique involves the Casper Suite from JAMF Software.  They have a neat feature that allows you to deploy Mac App Store apps in their self service portal.
The process is much easier than repackaging, although it does require a little more user interaction.  It has the added benefit of presenting all available apps (including non-app store apps) to the user in a single interface.
Patching and software updates
A lot of people consider the ongoing patch management of Mac OS X and the deployed apps even more important than the initial deployment.  The logic could be a little off as without the core business apps the Macs aren’t really much use, but I would agree that just focusing on getting the apps out without considering how you will keep things up to date is a bad idea.
If you ignore all updates, as well as being vulnerable to all sorts of attacks, you are putting off the inevitable.  The task of updating just keeps growing until it becomes a major project.
The tools and techniques used for patching Mac OS X, and your business apps go hand in hand with the initial deployment, with a few additions.  The goal is to be able to deploy updates to the base OS and third party apps with the minimum of fuss.
For apps like Firefox, there is no delta installer, you will just be deploying the whole thing, in which case you would add it to your deployment server just as if you were deploying it for the first time (note: make sure you aren’t deleting user settings such as bookmarks in the process).
The same applies for lots of other delta updates like the Microsoft Office patches; the only difference is the requirement for the original program to be on the machine before the update is run.
For Apple updates, a traditional Software Update Server still works best.  You can set this up with a Mac running the server app, or if you are feeling more adventurous (or would rather run the service on non-apple hardware), you could use Reposado.
A Software Update Server lets you enable new updates to the base OS and Apple apps once you have tested them, avoiding deploying a potentially harmful update from disrupting the Macs.
The final option to streamline the patching process is to use AutoPKG.  This service lets you setup automatic workflows for a lot of your third party apps so the new versions can download and add themselves to your deployment system.  The project started out working with Munki but has been extended to also work with Casper (AutoPKGr).
It is important to note that if you set up this service to automatically download and deploy the updates, you are putting your trust in unknown parties.
We would recommend setting it up, so new updates go into a “quarantine” group and only deployed to test machines.  If you are more security conscious, or are bound by strict security compliance regulations AutoPKG may not be for you, in which case you would need to use a more manual process.
Read “Best Practices in 2015: Managing Settings in Mac OS X and iOS” next
If you are thinking about deploying a new fleet of Macs or iOS devices and require Apple consultancy or advice, please contact our expert team today. Call 0208 660 9999 or email