As you’ve probably heard, Declarative Device Management (or, for less of a mouthful, DDM) is making significant changes to the way in which managed devices go about their business in some key ways - most notably how managed software updates work. We’re going to take a look at this in detail, as it’s been a particularly hot topic in the Apple Admin community over the last couple of years.
Firstly, it’s not a typo of ‘MDM’! In a nutshell, gone is the notion that the MDM server needs to constantly check-up on how a device is getting on with a certain command it’s been asked to do; instead, the device has much more independence and tells the MDM server when something has been done. This majorly cuts down on the stream of commands issued to devices (particularly when performing remote software updates, which we’ll loop back to shortly) and means that a growing number of attributes, such as OS version, can be updated on the MDM without an inventory update command being sent. In time, it may very well be the case that inventory updates become totally unnecessary, with devices instead sending real-time data back to the MDM as things change.
Of course, Jamf Pro and Jamf School have support for DDM, so your organisation is already primed to take advantage of it. Being so new, however, Apple are regularly adding to DDM’s capabilities with every major OS release, so it’s important to keep eligible devices updated to ensure full support of the latest features.
You can learn much more about the latest updates to the DDM specification on Apple’s WWDC video.
Much has been made in the Apple Admin community about how remotely updating devices - Apple Silicon Macs in particular - hasn’t been a smooth ride lately. There are solid reasons for this, mainly around the concept of volume ownership in macOS on the latest Macs, which are grounded in security and that is fundamentally a good thing. However, we do need the ability to easily keep our Apple estates updated so that we can stay secure and enjoy the latest software features (plus, the main reason we all update - new emoji!).
Handily, Apple saw fit to overhaul the managed software update workflow across all their operating systems and tie it into DDM. This puts the emphasis on the device to perform the update when instructed, and to report back to the MDM server once it’s been done. While that may sound like a small change, it makes a world of difference to the reliability of macOS updates and the amount of strain on the MDM server, since it doesn’t have to ‘babysit’ the Mac and check-up on it every 15 minutes. It also offers a new option to set an installation deadline, a point in time at which the Mac will forcibly update itself by if the user hasn’t accepted the numerous prompts to do so beforehand (very handy in both lab and 1:1 environments).
These changes are the same across iOS and iPadOS too, and here we can see a screenshot of what that looks like to the end-user, side-by-side before and after the download:
Note the prompt to install on both pictures, empowering the user to run the update at their convenience but ensuring a safety net deadline that will force the update for them at that time. This opens up a great new workflow for updating Apple devices overnight as a failsafe mechanism if the user maybe forgets to run the update during their break. It’s important to note, though that a network connection is required at the point of installation, otherwise users will see this:
As you can see, the user is advised that they have a managed software update pending and, as we chose the Schedule option in Jamf Pro, the installation deadline is shown too. The user will also receive periodic notifications that prompt them to perform the update earlier, increasing in regularity as the deadline looms larger (particularly in the hour before installation). Again, this user experience is exactly the same on macOS.
A logical question is, ‘What happens if a device is offline at the scheduled time?’. In this scenario, the device would simply update within the next hour of being online and the user would again receive full prompting throughout that time. This may be an issue if your users sleep their MacBooks overnight, so the pre-existing Deferral software update method may be a better alternative in that situation (whereby the user can delay the update a set number of times before it being forcibly applied). Personally, I really like scheduled for lab desktops and mobile devices, as these have a more predictable uptime compared to laptops, but every organisation is different and it’s important to decide which works best for you from the options available. See Apple’s Platform Deployment guide for more info regarding deferral behavior, etc.
Well, the workflow is exactly the same if you’ve been using Jamf’s new software update experience (currently in beta, but can be enabled in your instance under Computers (or Devices) > Software Updates). Simply pick a group (or groups) of devices, click ‘Update’ in the top-right, and you’re done!
However, you will need a few things:
As you can see, the UI in Jamf Pro 11 makes it really clear to identify the groups you’re updating and the update method you’re applying to them.
One of my favourite updates to macOS 14 and iOS/iPadOS has been this update to, well, updates! I’ve not experienced anything other than perfect results with this in my testing across Macs and iPads, and it’s a real comfort to have greater confidence in the remote update workflow on macOS, as well as providing additional options to users in the form of scheduling OS updates to occur.
Give it a try in your environment and, based on the results, consider potentially different workflows and processes for different types of device - maybe use scheduling for mobile devices and lab Macs, with deferrals for MacBooks. Jamf and Apple have given us the tools to offer more flexibility here for an improved user experience, and that’s something we should definitely celebrate and take full advantage of.