Just two weeks ago, we announced the second generation of Kandji’s Managed OS, which rebuilt the core architecture of Managed OS to optimize performance and reliability. We were—and are—justifiably proud of that announcement. Today, we’re taking it to the next level by announcing support for our use of Apple’s declarative device management (DDM) framework to make updates for macOS Sonoma and iOS/iPadOS 17 even more reliable for admins and more transparent to users.
Managed OS: MDM vs. DDM
Managed OS is our umbrella term for the Library Items that admins use to manage operating system updates on their Apple endpoints. Those Library Items let admins decide which versions of those operating systems will be installed on which devices and when. There’s a separate Library Item for each version of Apple’s operating systems that we support.
The Library Items for macOS Ventura (and earlier) and for iOS/iPadOS 16 (and earlier) will still use the Managed OS v.2 architecture. But those for Apple’s most recent OSes (macOS Sonoma and iOS/iPadOS 17) have been updated to take advantage of DDM.
Declarative device management (announced at WWDC 2021) shifts much of the responsibility for management to the device itself. It allows MDM solutions to generate declarations for some management tasks—including scheduling and managing operating system updates—for those devices; the declarations then take care of those chores on their own.
In previous iterations of Managed OS, much of the responsibility for operating system updates resided in the Kandji Agent. Now that intelligence is shared between the Kandji server and the device itself.
Here, for example, is the flow that exists now with Managed OS v.2:
You’ll note that all steps in the process—from scanning for available updates to implementing the update itself—are initiated by the Kandji server. The process relies on MDM commands to install updates and receives feedback on the state of those updates only when the server polls devices.
Here, by contrast, is how that same process looks with DDM:
Here, the server says it has a new declaration for the device. Once that declaration is downloaded, the device can manage the process, proactively communicating with the Kandji server only when it needs something or when it has new information to provide (via status reports).
This shift should give administrators more control over the update process and, at the same time, provide more information to users about what’s happening. The result: Updates can happen in a more timely, less disruptive fashion.
Managed OS Experience for Admins, Users
From a practical standpoint, not much will change: The Managed OS UI is much the same for the latest OSes as it is for earlier ones. The choices available are much the same; admins can still determine how one of the new OSes should be installed and enforced.
The one significant change in the UI is a new option for setting the time when updates will need to be completed. Previously, the time zone for the scheduled enforcement was based on the server time; the Library Item had a time zone selector to determine when to send the enforcement.
With the new DDM-based Library Item, admins can just enter the time of the day when they want updates to happen, and the OS will enforce that deadline in the device’s local time zone. This has been a frequent feature request from admins, who had to find some kind of best-fit accommodation for all their devices and users (unless the devices they managed were all in the same time zone). Now they can just set a time—end of the day, say—and know that updates will happen then, regardless of where the device is.
Another change will be more apparent to users. Previously, the Kandji Agent notified those users that an OS update was happening. Now, users will see OS-native notifications telling them what they need to do:
In the latest updates to Managed OS, we worked hard to improve the fallback experience, which users see when an OS update fails for some reason; they must then go into System Settings (or Preferences) to help it along. That fallback experience is no longer necessary for macOS Sonoma and iOS/iPadOS 17 because the Kandji Agent is no longer involved. If something doesn't work, the operating system itself prompts them to remediate it, not the Kandji Agent.
More importantly, this changes the way users will defer OS updates. The admin will still set a deadline for the update, but users won’t be able to postpone them quite as much as they could when the Kandji Agent was running the show. The Agent allowed users to defer updates an hour at a time for up to an additional 24 hours past the enforcement date to accommodate any last-minute, business-critical tasks.
Now, with DDM, they’ll have to follow the operating system’s rules for updates: The OS will notify the user extensively leading up to the deadline, and users will be given the choice of installing the update immediately or trying later that night (or any night leading up to the enforcement deadline). Once the enforcement deadline is reached, the update proceeds with no ability to defer it further. If a device is offline or asleep when the enforcement deadline passes, the user is given a one-hour grace period before the update is enforced.
These are just the latest steps in Kandji’s continuing support for DDM. As we’ve said before, we think this framework will revolutionize the way Apple admins manage their endpoints. We were the first to market with a solution to actively manage supervised devices via DDM, and we’ve continued to turn it on for all eligible devices since then. And we will continue to aggressively adopt Apple’s new framework as it evolves in the future.
About Kandji
Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.