For various reasons, my company has decided to standardize on macOS High Sierra 10.13.2. But given all of the latest issues we and others have seen with High Sierra, we wanted to take a somewhat conservative deployment strategy:
In Part 8, I outlined my thoughts on why InstallApplications was written and why it’s my preferred way to orchestrate custom DEP enrollments.
On November 27th, 2016, my current employer and AirWatch decided to go down the route of collaborating on custom DEP. Almost fourteen months later, I’m realizing just how important this decision was, both to my professional career and my company’s worldwide macOS deployment. With the release of macOS 10.13.2/User Approved MDM enrollment and changes to how SecureToken operates in FileVault environments, many macadmins have felt the pressure to quickly implement some form of MDM. It’s an ugly, reactionary situation.
Three months to the day I announced that AirWatch had released custom DEP in AirWatch 9.1. This was a limited release due to a few outstanding issues with
mdmclient, especially in regard to the
InstallApplication command. With macOS 10.12.6, Apple has now resolved these bugs and AirWatch feels comfortable with releasing this to all AirWatch customers.
On June 19th, Apple released a document describing how loading secure kernel extensions (.kext) would change with High Sierra and how this would impact enterprise customers.
At my current employer, we have been moving from a traditional MDM to a hybrid approach, with a focus on dynamic configuration management and desired state using Chef as the primary mechanism.