Jamf Blog
Image of laptop with bullhorn.
May 19, 2023 by Anthony Darlow

Explore Declarative Device Management in Jamf School.

In a recent update, Jamf School added support for Declarative Device Management (DDM). With these new capabilities, Jamf is helping schools move from MDM for schools toward the future of Apple device management: MDM and DDM partnerships.

What is Declarative Device Management (DDM)?

Announced at WWDC 2021, Declarative Device Management (already known as DDM; Mac admins love an abbreviation) is MDM 2.0. In a nutshell, DDM will make devices smarter and reduce network chatter between a device and the MDM server. With DDM, devices will autonomously update the MDM server of its current state. Devices will also be able to evaluate their own states and apply or disable settings based on this analysis.

It’s best to point out that DDM is not a replacement for MDM. It's a framework within the MDM spec, which offers a new way to manage Apple devices that sits alongside and works with MDM.

Empower teachers, parents and students with Jamf School.

Why should we care about Declarative Device Management (DDM)?

The MDM spec as we know it today has been around for 10 years or so— a super long time in the IT world. Things change, more devices get deployed and technology gets better. Declarative Device Management is Apple’s answer to the ever-changing landscape of IT.

To understand the huge impact DDM will have, we first need to understand how MDM works today from a high level.

How MDM in education works today

Today there is a lot of back-and-forth communication between the device and the MDM server; essentially the device doesn’t do anything from a management point of view unless the MDM server tells it to. And the device doesn’t know it has to check with the server until the server tells the device it needs to check in!

Typically this is how communication between a device and its MDM takes place:

  1. The MDM server asks Apple to send a Push to Device to ask a device to check in.
  2. Apple asks the device to check in with its MDM server.
  3. The device then reaches out to the MDM server saying “I've been asked to check in.”
  4. The MDM server might then say, "Please can you tell me your state (things like OS version, passcode enabled, apps installed, etc.)?"
  5. The device then replies with the information requested.
  6. Based on this, the server might push an additional configuration for the device.
  7. The device then applies this configuration.
  8. The server then asks the device to update its state again or to confirm that it has applied that new configuration.
  9. The device then replies with the updated state.

This is a lot of network traffic between the device and the MDM server for just one exchange. Now, multiply this by many transactions per day and by hundreds or thousands of devices in your deployment. In addition, if the device changes state at any time before the MDM server again asks for check-in, the MDM server —and therefore the admin— has no idea of the change.

What's wrong with the way things are now?

Let's take an example.

We have a device that has just checked in and reported that it is secured with a passcode. As a Jamf School admin, I am able to see in the console that the device is compliant with our passcode-set policy. If the device does not have a passcode set, I will add an additional configuration that hides apps containing sensitive data, such as email clients or cloud storage apps, by sorting it into a Smart Group.

Five minutes after the device checked in, the user decides they are going to take the passcode off the device as they are tired of entering it over and over again while working in a coffee shop.

The device is no longer compliant with our policy. However, if I as a Jamf School admin check the console, it's still showing as compliant and will still show as compliant until the device checks in again.

That means that until the device checks in again, the device does not know it needs to apply the additional configuration, so those sensitive apps are still available on the device. In the meantime, the user leaves the coffee shop but forgets their iPad. Somebody else in the coffee shop picks up the device and starts browsing the emails of the user, who just happens to be a headteacher or principal at a large secondary school.

How often a device checks in is dependent on the MDM product you are using, but Jamf School's check frequency is every two hours. This means that it can take up to two hours before the device would have checked in with Jamf School, reported that it no longer had a passcode, and got sorted into a Smart Group to apply the additional configuration to hide the sensitive apps.

How will DDM improve my workflows?

  • The Status Channel: a way that devices can proactively report the current state of certain device inventory data back to a server that subscribes to that Status Channel. Devices can now autonomously report changes in status within seconds of the change.
  • Declarations enable the device to decide what configurations to apply based on its state. For instance, if we wanted to apply a VPN configuration but only if the device has a passcode, Declarations gives the device all of the information about the VPN config and the conditions that need to be met in order to apply it all in one go. Once the device meets those conditions, it autonomously applies the VPN configuration.

DDM will not only decrease the chatter between the device and an MDM server; it will also provide a much smoother user experience.

And that’s the aim: technology that supports teaching and learning without getting in the way.

I highly recommend watching the Declarative Device Management session from WWDC 2021 for a more in-depth look.

What specific support for DDM has Jamf School added?

Jamf School has added support for a number of inventory items to be provided by the Status Channel. These include model information, OS information, device identifiers and passcode status.

Full Jamf support for DDM list:

  • device.model.family
  • device.model.identifier
  • device.model.marketing-name
  • device.operating-system.build-version
  • device.operating-system.family
  • device.operating-system.marketing-name
  • device.operating-system.version
  • device.identifier.serial-number
  • device.identifier.udid
  • passcode.is-compliant
  • passcode.is-present

As a Jamf School admin, there is nothing for you to configure. Jamf School will automatically send a remote management command to enable Declarative Device Management on eligible devices.

Eligible devices require either macOS 13 or later, iOS 16.1 or iPadOS 16.1 or later, or tvOS 16 or later.

With new device inventory items of “Declarative Device Management supported” and “Declarative Device Management enabled” in the Jamf School console, it's easy to see your eligible devices and if they have DDM enabled.

For more information, read the Jamf School documentation.

Does Jamf School's support for DDM affect me today?

Over and above near-instance reporting of the inventory items above, which in itself can be useful around new OS release time, this update mainly won't affect Jamf School admins.

That being said, the fact that one of these items is the passcode does bring a nice improvement to the example I described above where the user turned off the passcode and left it in the coffee shop, exposing sensitive data.

If we now look at the situation with Status Channel support, we’ll see a much-improved experience. Since reporting if the passcode is or is not present is a channel that Jamf School subscribes to, within seconds of the user removing the passcode the device proactively and autonomously reports the passcode status to Jamf School. This is DDM at work.

Once Jamf school is informed of the change (ie it's moved from passcode is present = Yes to passcode is present = No) it has been able to recalculate the Smart Group membership of devices without a passcode, within seconds of the user removing it. Since the device is now in this Smart Group it requires the additional configuration to hide the sensitive apps and will use what I will call here “Traditional MDM” to deploy the profile.

The result is that within a few minutes (my testing shows within 30 seconds mostly) of the passcode being removed, the device then also hides the sensitive apps.

Now this is a huge improvement using just the Status Channel and then reverting to MDM and the server-side deployment. Of course, in the future, there's the possibility that this could all be done instantly and autonomously using Declarations.

The future of Jamf School DDM support

The recently-added support for DDM is really exciting! Although today, reporting inventory data via the State Channel doesn't have a huge impact on Admins, we can clearly see with the passcode example, it’s the start of the future of Apple Device Management for Jamf School.

As stated above, the Status Channel is just one part of Declarative Device Management with Apple providing more elements of the framework each year, I’m looking forward to Declarations becoming widely available.

It’s going to be a game-changer. Bring on MDM 2.0 and bring on WWDC 2023! I'm sure it’ll bring more to the table for DDM.

Photo of Anthony Darlow
Anthony Darlow
Anthony Darlow, Consulting Engineer, Education, is based in Newcastle and London.
Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.

To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.