It has been much discussed how imaging Macs is basically dead. Monolithic imaging just isn’t viable anymore (thanks, iMac Pro) and modular imaging unfortunately won’t automatically get you things like User Approved MDM (UAMDM). Check out Armin Briegel’s post on the death of imaging.
At the end of the day however, the goal of deploying a machine as quickly and efficiently as possible all while having to manually touch or configure little to nothing remains unchanged. So how might you do this with a DEP workflow?
This post is meant to be an overview to our new workflow, acknowledging the pitfalls, various hurdles, and acknowledging other methods as well in the hopes of getting your creative juices flowing if you, too, are considering a shift from more traditional imaging workflows to DEP. While we use Jamf Pro, this write up is meant to be MDM-agnostic.
I will write up a more granular series of posts with all our Jamf Pro policies and configurations at a later time once we’ve fully rolled out this larger workflow over the summer months.
How do you ensure regardless of a user being logged in a given Mac that your machines are connected to your Wi-Fi network?
If you are an environment that uses Active Directory, or another network account system, you need to make sure that your Macs are always online so users can login. Windows computers have the benefit of being able to utilize machine authentication, but this functionality unfortunately isn’t natively available on Macs.
Rather than having to implement a Microsoft CA and have each Mac request a cert in order to connect, our environment has developed a solution that achieves the end goal of machine-based authentication for a bound Mac using the following:
A .mobileconfig profile containing a Wi-Fi payload with a placeholder username and password copied to the local machine.
A script that gets the AD computer object name & password from the System.keychain, adds it to the .mobileconfig profile, and then installs the profile on the machine.
While I myself did not come up with this solution, I’ve developed a more streamlined process for deploying our template .mobileconfig profile and script as a postinstall script in an installer PKG.
There are already great guides for how to configure reposado & margarita (the reposado web front-end) on Ubuntu and on Mac. However, neither of these setups gave me everything I wanted in my environment.
Justifications for Docker on a Mac:
Too many web servers: Despite wanting this to run on a Linux server, I couldn’t justify spinning up yet another dedicated web server in our small environment.
Available Hardware & Storage: Unless you are going to manage which individual Apple Software Update catalogs is mirrored by reposado, you’re going to need at least 1TB of storage, as completing a full repo_sync of all available catalogs (as of this writing) takes up a whopping 462GB of storage. Luckily (or unluckily, depending on your POV), we had a severely underutilized Mac Mini that was being used solely as our internal Apple Service Toolkit (AST) NetBoot server and a spare 2TB external USB3 hard drive.
Operating System: Because the Mac Mini I had available was several macOS versions back and I wanted to avoid having to upgrade the OS all the way to High Sierra (this is due to the fact the currently available macOS Server app – 5.6.1 – requires 10.13.4 to run), I wasn’t able to get pip or flask installed (required for margarita) due to errors resulting from using TLSV1 when attempting to download this software.
Nginx: While I haven’t worked too much with Nginx up to this point, the performance benefits when under heavy loads are notably better than Apache.