There are plenty of great blog posts and walkthroughs for setting up munki, the indispensable tool for admins looking to deploy and update applications on macOS. I plan to eventually write up my own guide for setting up and securing munki, but this isn’t that. Instead, this is what I hope is a very clear explanation of how the different parts of a munki set-up work together. Many people, myself included, seem to have problems wrapping their heads around munki, understanding how it works, and how the different pieces fit together. Ideally, this is the post I wish I’d read before starting to work with munki for the first time.
In my previous post, I explained the what, who, and why of InstallApplications and how its various components work together to provide a custom DEP enrollment. In this post, I will demonstrate how to set up and use IAs with SimpleMDM to achieve a custom DEP enrollment and bootstrap experience for your users.
With the Shakespearian tragedy that is The Death of Imaging finally coming to an end with across-the-board T2 chips, there is a growing need for alternate workflows for bootstrapping machines. Apple’s answer for this problem is DEP and MDM. While this workflow isn’t ideal for every situation, it is possible for administrators to leverage these tools to provide a smooth and effective enrollment experience, whether using Internet Recovery or deploying brand new Macs.
Back in March, SimpleMDM (of which I am a big fan) announced they were adding webhooks to their Mobile Device Manager. These allow you to send an HTTP POST to the URL(s) of your choosing when certain events occur in your SimpleMDM account. Following this announcement, I built an AWS Lambda function for responding to these events, partly as a learning. This function is designed to allow for more sophisticated response whenever a device is enrolled or unenrolled in SimpleMDM.