WWDC 2021 Wish List
Apple Geek Christmas is just a few hours away, and it’s not just developers that are both anxious and excited. Folks who manage large fleets of macOS and/or iOS devices will soon learn the changes ahead that will affect how they will configure, deploy, and manage devices in the future.
Apple’s yearly OS update cadence has most definitely stressed the admin community, both with significant changes to how things must be accomplished, as well as crippling bugs. Often times, the implementation of new features has been done in ways that make sense in a consumer model, yet do not scale well in the enterprise world.
Let’s address macOS and iOS:
macOS
If you’ve been paying attention, one can see over the last 5 years that Apple has been playing chess, getting the pieces in position for a big move. That culminated with last summer’s announcement of Apple Silicon, and shipping macOS Big Sur and the M1 Macs last November.
The M1 Macs are truly great computers — high performance, low power consumption/long battery life, near-silent, with upgraded webcams and microphones/audio. Releasing these systems in a world where, due to the global pandemic, many people have been working from home for the past year or more, and may continue to work from home/wherever, either periodically or permanently, seems like a “right place, right time” moment for the company. From my perspective, the sooner Apple can replace the Intel 16” MacBook Pro (my org’s most prevalent model) with an Apple Silicon version, the better. Every time the fans go nuts on my Intel 16”, usually thanks to problematic security tools, I curse the absence of an Apple Silicon model.
The changes revolving around M1 Macs and Big Sur regarding the end of kernel extensions (unless you jump through a lot of hoops) and their system/network extension replacements have probably been the most painful, for both developers and admins alike. Despite macOS 11 shipping in November, it seems like many of the security tool vendors have only recently shipped M1-compatible or M1-native tools. This has led to a number of organizations that have simply held off on supporting or deploying macOS 11 and these new systems. I’m not sure how much of an effect the pandemic had on this transition, but it’s been extremely painful.
More than anything, the Mac admin community needs a break — an OS release that focuses mainly on fixing bugs and improving workflows, without dramatic changes. This is why I hope Apple’s macOS 12 release is, effectively, Snow Big Sur.
No, it will hopefully not be named that (Monterey?). It refers to, after Apple released macOS 10.5 “Leopard” with many significant changes, the 10.6 release was named “Snow Leopard”. It had virtually no significant changes other than bug fixes and slight improvements, and it was a rock solid release. Apple tried this same approach with macOS 10.12 Sierra, followed by macOS 10.13 High Sierra, but there were more significant changes (approving kernel extensions, the new Apple File System, and the end of imaging) that most definitely gave admins headaches with High Sierra.
Hopefully macOS 12 does not contain significant changes from macOS 11. There are a few other things I’d like to see on Apple’s roadmap; perhaps not in macOS 12, but, hopefully soon. Things that would make admins’ life better:
1. Improvements to Mobile Device Management OS update and upgrade workflows. The irony that Apple is known for great user experiences, and yet the user experience when admins attempt to use MDM commands to either update (i.e. macOS 11.3.x->11.4) or upgrade (i.e. macOS 10.15.x->macOS 11) is not awesome. Coupled with macOS Big Sur on M1 Macs precluding the use of the softwareupdate command in scripts/workflows, without prompting the user for credentials (due to volume ownership requirements on M1 Macs) means enforcing OS updates on macOS has become more difficult. For further reading: https://www.alansiu.net/2021/04/28/why-dont-mac-admins-use-mdm-for-apple-software-updates/
2. Improvements to Provisioning Workflows. Auto-Advance in macOS Big Sur is great in reducing the number of prompts when setting up a new device. But there are still prompts (to enroll the device in an MDM requires confirmation). Would love the ability to suppress even that, and just enroll the device.
3. Improvements to Reprovisioning Workflows. iOS and Apple Configurator is pretty easy to simply Restore an iOS device with a fresh OS. For macOS, this process is much more convoluted — must have the correct cable, plugged into specific USB-C ports, and hold down the correct sequence of keys, etc. Alternatives include booting into Recovery, and either using Erase Mac, or authenticating at the Recovery Assistant then erasing the volume and reinstalling the OS. It sure would be nice if macOS included an equivalent of “Erase All Content and Settings” like iOS has, where you can trust the signed, read-only OS partition, but simply erase the user volume, so the device will effectively reset itself to factory defaults. Coupled with removing the remaining prompts, this would make it far easier and faster to return a macOS device to service.
4. One significant pain point with System and Network extensions on macOS 10.15/11 is the inability to programmatically remove them (without prompting the user for credentials, or booting into Recovery, which clearly does not scale with hundreds or thousands of deployed Macs). This seems like a huge design oversight that requires Apple’s attention.
5. Improvements to managing Security & Privacy. These are some of Apple’s strong points/areas of emphasis. However, one of the pain points for admins has been the inability to, for institutionally-owned, supervised devices, the inability to pre-approve applications for the Screen Recording and Accessibility features, typically required by video conferencing applications like Webex, Microsoft Teams, Skype, et. al. Generally, most of these apps need Camera, Microphone, Screen Recording, and Accessibility access enabled to work properly; the first two are logical and most users understand this. The last two? Not so much. You can lead the users to documentation, but you cannot force them to read it. The fact that admins can’t pre-approve these settings for their remote conferencing tools, in the time of a pandemic when people are working remotely, has been very painful. Admins need the ability to pre-approve these latter two functions. I will die on this hill.
6. This leads to a bigger conversation regarding the MDM protocol. It’s now old enough to become a teenager this year, developed first for iOS and then ported to macOS for 10.7 Lion. As designed, it has a number of deficiencies that can only be addressed by refactoring it. They include:
a. Lack of confirmation that MDM commands have been properly received. The whole process is a bit of a black hole. Some admins have taken to calling it “Maybe Device Management”.
b. Inability to “prestage” settings that apply only to new OS, on a previous OS version, and have these settings evaluated post-upgrade. This would prevent a lot of prompts/pain when users upgrade their system, before their MDM recognizes the upgrade and pushes down the appropriate profiles for the new OS.
c. Still miss the “set once” option from Workgroup Manager. Usually when a profile is deployed, it prevents changes from the GUI/disables it. Most admins would like to use profiles to establish some default settings (i.e. Dock, Energy Saver, etc) and yet let users adjust/tweak those settings as they need. That’s not currently possible with profiles today.
d. Profiles need to be expanded to (optionally) allow configuration state management. If a profile is deployed to a device that enables or disables a service (i.e. firewall, ssh), there should be some intelligence that if that service state is changed, MDM can enforce the setting and turn the service back on or off, as applicable.
e. The GUI for most MDMs effectively replicates the functionality of the old Profile Manager in macOS Server. While it’s possible to manage a lot of things via custom profiles, at least on macOS — https://boberito.medium.com/config-profile-and-manage-all-the-things-just-about-cafea8627d4b — there’s no default GUI in most products for this. Integrating third-party tools like ProfileCreator with your MDM can also be painful.
iOS/iPadOS
While not new to iOS management, in my current environment, the number of iOS devices I am responsible for is many times the number of macOS devices. I find these to be some of the pain points with managing iOS devices at scale:
1. Enterprise Management functionality for OS updates/versions. I share many of these concerns with macOS, but iOS, coupled with MDM, lacks the ability to ensure that a consistent OS version is deployed fleet-wide. The security model for most OS vendors has changed, for security/vulnerability reasons. When an OS update is released, there are often many critical vulnerabilities patched. Some of these may be actively be exploited “in-the-wild”, and yet there’s no easy way to enforce that iOS (or macOS) devices must be upgraded to a specific version by a specific date. A great GUI for the end user experience to allow for messaging, deferrals, and enforcement is sorely needed. Some of these things can be done via custom apps or scripting, but, since this is functionality that literally every admin requires, it needs to be far easier. This is on both Apple and the MDM vendors.
2. Increased manageability of custom settings. I’ve got some specific iOS device workflows that require a pages-long checklist to adjust/control various settings that are currently not manageable via MDM. The irony that Apple has settings in the GUI to control iOS automatic downloads and automatic updates, but that these are not manageable via MDM. So, too, is the irony that Apple has a very powerful Shortcuts app/functionality on iOS, but there is zero ability to utilize MDM to deploy these shortcuts across a number of devices.
3. I’d personally love it if the ability to defer OS updates could be moved to a separate profile from Restrictions. I’m torn between not wanting folks to update to a new OS version right away, at least until after it’s been vetted, versus the requirement to get OSes updated to address those critical security vulnerabilities. Perhaps a model where the *user* does not see an update advertised for x number of days, but the admin can push/enforce the update, regardless of the update deferral time, would be advantageous.
4. From a Security and Privacy perspective, the fact that there is no ability to control settings for the built-in iOS Mail app, to default to blocking external image loading (preventing the use of spy/tracking pixels, which is widespread), seems inexcusable.
5. Managed Apple ID’s, which are a requirement for user-based enrollment (i.e. personally-owned devices) into an MDM, are very, very inflexible. First, Apple only supports integration with Azure AD and not other cloud identity providers. Secondly, organizations have no global dashboard to enable or disable functionality (i.e. turn off iCloud Drive for these users or groups, but enable e-commerce functionality in the accounts).
Realistically I do not anticipate that most of these asks will be addressed with macOS 12 and iOS/iPadOS 15. If you agree with any of these requests, I strongly suggest talking to your Apple SE, filing Feedback, and, if you have AppleCare Enterprise, creating tickets, along with impact data (ie how many affected systems, or how many more systems that you might buy if you had these features). Oh, I’d love it if Apple’s methods of listening to customers about bugs and features (both missing and/or implementation improvements) was improved, too, so that things didn’t sometimes seem to disappear into a black hole.
