A few days ago I tweeted a very vague picture from System Preferences, showing an unsigned, MDM installed profile. At the time, no one really picked up on the importance of it, but today I would like to introduce you to the concept of C-MDM. My vision for C-MDM is a middleware tool, that can aggregate data locally on a device, analyze what settings it needs to manage and then ship that over to your MDM of choice for installation and/or removal.
Recently, Chris Collins wrote an awesome blog post around some shortcut keys to get a Terminal window during the SetupAssistant. In the comments, Matthew Lavine wrote something that caught my attention:
With Apple releasing their deprecation notice for macOS Server functionality, several macadmins have been asking what they can do to continue to manage services like Imagr, Munki and Reposado.
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.