The existing complexity of DEP, though, gives us choices. There’s no reason we couldn’t setup multiple MDMs for multiple departments within an organization, allowing central management of assets, and separate management of devices at the department levels, allowing for good competition between MDM vendors in the mid-level of the environment. Having multiple options is good, because it gives us choice, and it avoids obvious anti-trust complaints.
Read the whole thing. Complex shouldn’t be immediately pejorative. Good management can, and almost should be considered a complex task.
Hopefully by now you’re aware of Apple’s Device Enrollment Program (DEP), which allows you to specify a Mobile Device Management (MDM) server for your devices to check in with during their initial setup process. This applies not just to iOS devices, which substantially benefit from enrollment in MDMs, but also to Macs, which traditionally have had fewer benefits.
That has substantially changed in the last few months.
A month ago, the Mac Admins Podcast sat down with Erik Gomez of Pinterest to talk about using MDMs to install Mac applications – including root agents like Puppet, Chef and Munki. Erik designed a workflow — and built some tools himself — to configure those root agents and engage them in a seamless series of actions for onboarding new staff. The goal was simple: fully utilize DEP and MDM to install their management agents and software management scheme, as well as customize the device in a way that their engineers normally would ahead of deployment.
The experience of rolling out new equipment to new staff, or returning staff, can be a whole lot less hands on for IT Admins, and that’s an excited part of this.
This process is going to talk about several different important parts, and I want to lay out what you need to make this work.
DEP Account – This should go without saying, but you need a DEP Account. That involves getting a customer number from Apple, and if you’ve got a retail store near you, their business team can help with this. Please stop and read the Deployment Program Help if you have questions. Please note: It can take more than a week to get this done, so start early.
Developer Account – This process requires that you have a signing certificate that is signed by the Apple Worldwide Developer Relations Certificate Authority. There can be no substitutes, so you’ll need to join the Developer Program. It’s $99, and you should probably already have this anyway.
SimpleMDM Account – SimpleMDM is one of the few MDMs that support the InstallApplication verb in the mdmclient binary for the Mac so far(1). You can try it out for 30 days with no credit card. Devices start at $30/year.
A Web Server – You’re going to need a place to host your signed application packages and a JSON file. It’s best if it has an SSL/TLS Certificate installed and configured for use.
InstallApplications Script – You will need the InstallApplications project from Github. This is the glue that makes everything else possible. InstallApplications is the actual signed package you’ll be installing from the MDM, which will in turn reference the JSON file on your web host, and then process the packages specified therein. This is a great way to stage a bunch of useful content on the machine that can then be called in a coherent process to take the machine from fresh-from-Apple to fresh-from-your-organization.
DEPNotify – There are few things as bad as a process with no interface. Users can grow confused or impatient if expectations are not properly set. DEPNotify is a good way to message to your users what is happening with their brand new computer.
During Setup Assistant, a machine that is registered with DEP will check in with Apple’s Activation Servers, and based on the hardware model identifier and the serial number, be assigned to the MDM that corresponds with its record in the DEP portal. At that time, the MDM in charge of the situation can deploy pre-stage packages during the Setup Assistant.
That’s where this process comes in. You can create and sign the InstallApplications package with your Developer certificate, and then deploy that LaunchDaemon to the machine in a safe method without ever touching it. InstallApplications works by referencing a JSON file that is stored on the internet that provides a series of package URLs, file locations and file checksums for the packages you want to install on the machine before and after the Setup Assistant completes.
The nice thing about InstallApplications is you only need to rebuild the package if the location of the JSON file — or some of the attendant details for how it’s secured — have changed. Ideally you build it once, and then handle the rest via the JSON file. Once you have selected your pre-stage and stage 1 and 2 packages (of which there can be a number of each, you’re not limited to one package per stage), make sure to capture the appropriate checksums with the shasum -a 256 /path/to/your/cool/package.pkg and embed the values appropriately.
As part of our install, we’re dropping in the DEPNotify binary and the munkitools package into the pre-stage, since they don’t require a user session, and then a trigger for DEPNotify that performs the first login tasks during Stage 1. We’re doing our Munki configuration via SimpleMDM’s support for custom profiles, so those settings are already present when our trigger script runs after the first user logs in. Our script, a sample of which is linked here, kicks off the DEPNotify application, and begins to guide the user through what will follow.
I also wrote a second script that is installed as the last thing our Munki server doles out for install. It issues one last command to DEPNotify and then cleans up the log file. You can later create an uninstaller for DEPNotify that cleans up the application.
Sign this package with your Developer ID Certificate.
Upload this to SimpleMDM as a macOS Package and Configure it to be installed in the default group selected in DEP.
Create the referenced JSON file and place it on your Web Server making sure that the security on the directory matches what you’ve specified in step 1.(2)
Upload the packages referenced in the JSON file to your Web Server.
Check to make sure packages download okay.
Write a first-boot script that launches your software installer, and gives DEPNotify the data that it needs to get things going.(3)
Test this with a Virtual Machine(4). Test it again. And again.
And Now, A Video:
This is what it’s like to setup a machine using Simple MDM, InstallApplications, DEPNotify and Munki together in a seamless toolchain:
It took approximately one full day to set all of this up and get it working like I liked, including the creation of this entry and documentation.
(1) the others are ZuluDesk and Airwatch as of the release of this post. I’ll keep this footnote updated as I hear of more.
(2) Right now, InstallApplication.py really does not like redirections, so make sure you’ve specified the correct URL.
(3) This is going to be the part that takes the longest. Building a good post setup experience for your users is going to be an interesting experience, and I think we’re going to see a lot of different takes on it based on the different schools of thought for user-focused deployment. There’s no reason that something like DEPNotify couldn’t be used over a period of hours or days to inculcate institutional culture to new staff. Play with this, It’s going to be interesting.
(4) Testing with a Virtual Machine is easily done. Using Joe Chilcote’s vfuse, create a new VM from an AutoDMG master. Open the .vmwarevm bundle and edit the .vmx file in a text editor (I recommend BBEdit) and add your Serial Number and Model Identifier. Now start your VM and you’ve got a DEP-enabled VM!