Jamf School blueprints bring Declarative Device Management to school

Photo by Vitaly Gariev

Introducing blueprints for schools managing Apple devices

At JNUC 2024 Jamf announced a new feature: blueprints. Although first announced in the main keynote, blueprints also made an appearance in the Education State of the Union. This is because the blueprints technology is not tied to any one of our MDM products; it is its own stand-alone service that our MDM solutions hook into.

This is very exciting news for Jamf and its customers. It means that blueprints, and their capabilities, can be worked on independent from the MDM's release cycles. Meaning that, in theory, if Apple released a new management capability today admins could have it in Jamf School tomorrow without having to wait for a release or update of Jamf School itself.

But that's not the only reason that the release of blueprints is so exciting. Blueprints are helping schools to push toward the future of Apple device management.

What are blueprints?

Blueprints are a delivery system for Apple's new device management framework: Declarative Device Management, or DDM.

What is Apple's Declarative Device Management?

Announced at WWDC 2021, DDM is MDM 2.0.

In a nutshell, DDM makes devices smarter and reduces network chatter between a device and the MDM server. With DDM, devices autonomously update the MDM server with their current state. Devices can 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.

In order to really see why we should care about DDM, and to see why it's exciting for the future, we first need to look backward at what MDM has been for the last 10+ years. 10+ years in the IT world is a century. Things change, more devices get deployed and technology gets better.

Declarative Device Management is Apple's response to the ever-changing landscape of IT.

How Apple 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 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, asking 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.

>> Read more about DDM and see a real-life example of MDM commands.

Autonomous and proactive

DDM is made of multiple components and in fact, the first: the Status Channel, has been available in Jamf School for a number of years!

The Status Channel

One way that devices can proactively report the current state of certain device inventory data back to a server is using one that subscribes to the Status Channel. Devices can now autonomously report changes in status within seconds of the change. Not only does this reduce the amount of chatter or back and forth as described above, it also doesn't depend on a device check-in for information to be up to date.

The second component to talk about here is a declaration.

Declarations

Declarations themselves also have a number of components to them. These boil down to a configuration and the ability of 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 give the device 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 and then, via the status channel, reports this state back to the MDM server.

If DDM is new to you and you want a more in-depth look, I highly recommend watching the Declarative Device Management sessions from WWDC 2021 and WWDC 2022.

Enter blueprints

Since declarations are unlike profiles and can co-exist with them, we needed a different way to configure and deliver profiles to the device using blueprints.

As we know, DDM was announced by Apple at WWDC 2021. However, they have continued to build more into this paradigm each year since, bringing with it additional status channels to subscribe to and more declarations to configure. This is also the approach that we are taking with blueprints at Jamf. Although Apple may have made a number of declarations available, with Jamf School we are starting with managed software updates and MathSettings declarations.

Apple has been clear that it will focus on a new feature using DDM, as well as stating that DDM will not replace MDM as we know it today- but will continue to power it up.

Admin Single Sign On for Jamf services

Admins will have noticed in the weeks prior to the release of blueprints that their login experience with Jamf School has changed. Now, instead of displaying a dedicated Jamf School log-in screen, there is a much cleaner window asking admins to sign in with their Jamf IDs.

For Admins who use Jamf Safe Internet, macOS security portals, or who use Jamf Nation/Jamf Account already, this is a familiar log-in experience and is the same across these portals, now including Jamf School.

As previously stated, blueprints aren't a part of Jamf School, but instead a stand-alone service that Jamf School hooks into. It might not be a surprise then to hear that one of the reasons for this new login experience is related to blueprints and displaying your blueprint configurations.

This is not the only thing to shout about!

Should you create a Jamf Account, you can use that same account—the username and password—to access all Jamf services that use Jamf Account to access, including the amazing Jamf Nation community and the wealth of support that brings.

The goodness does not stop there either; Jamf Account can be configured to use an external idP such as Entra. This means that the username and password are not just the same across your Jamf services, they're also the same credentials that admins use across other services managed by that idP.

Getting started with blueprints

Once you are logged into Jamf School you will notice a new menu item called Blueprints. Selecting Blueprints takes you to the new blueprints page. Remember, everything that you see here is related to the configuration and deployment of declarations, which is part of DDM and a reason why it's not within the usual menu item you'd use to configure devices: Profiles.

If this is your first time visiting this page or you have not created a Blueprint yet, you will be presented with the Quick Start templates. These templates are the declarations currently offered by Jamf School: 'Update software to latest version' and 'MathSettings.'

If you have already created a blueprint, or once you have, when you select the blueprints menu you will be presented with My Blueprints. These are the blueprints that have been created and are ready to be deployed.

Configuring blueprints

To configure a blueprint, choose a template from the Quick Start. For this example, we will use Update software to latest version, and will continue using this example as we continue to step through the process. Although blueprints configure DDM rather than traditional profiles, we will scope our blueprints to device groups that an admin may have already created to target certain devices or create new device groups as you have always done.

Since in this example we are going use the managed software updates declaration, I am going to create two simple device groups: one that captures all iOS devices in my fleet and one that captures all macOS devices in my fleet.

If you already have these groups or only want to target a sub-section of your fleet, feel free to amend your scoping criteria or use a device group you already have.

Creating device groups to scope to

1. Navigate to Devices -> Device Groups and select + Add Group.
2. In the name box, give the group a suitable name. For example: All iOS devices not on latest OS.
3. Select Smart Group.
4. Select Members and + Add Filter.
5. From the first dropdown box, select Operating System.
6. Ensure the middle dropdown box is 'equals.'
7. In the third dropdown box, select iOS.
8. Finally, in the max box, enter the version one less than the current iOS version, which at the time of writing was 18.3.0.

This will then capture any iOS device that does not have the latest version of iOS. This is a very simple group, and in production, you may need to use both the min and max boxes to filter out devices you know cannot update to the latest OS.

Repeat this process replacing iOS with macOS and n-1 in the max box of the group criteria—at the time of writing, this was macOS 15.3.

Create a blueprint

Now that we have the target devices, we are ready to create a blueprint.

1. Navigate to Blueprints -> Quick Start.
2. Select open in the Update software to latest version template.
3. In the name box, input a name for the blueprint, for example: iOS 18.3.1 updates.
4. It's also advised to add a description to the blueprint. This is particularly useful if you have a team of admins.
5. Select Next.

From this pane, you can see all the groups created in Jamf School. You can select the tabs across the top to choose All, Smart or Static groups, as well as use the search bar for quick access to specific groups. It's worth noting that a blueprint can be scoped to many groups, depending on the need of the declaration you are configuring.

1. Find the group All iOS devices not on latest OS, or the target group of your choosing.
2. Check the box next to the group.
3. Select Next.

This next pane is where an Admin configures a declaration. Depending on the template shown, this pane will look different. Think of this as building a profile and selecting the restrictions payload, which will have different options from the WiFi payload.

Since in our example we are creating a software update blueprint, we will configure date and time and target OS version.

1. Select the box under Date and time of update.
2. Using the calendar, select a date and time that the update must be enforced by.
3. In the Target OS Verson box, enter the iOS version you want your targeted device to update to. For example, at the time of writing I would enter 18.3.1.
4. Select Save.

Blueprint preparation

As I mentioned before, you can also prepare edits to your blueprints without deploying them right away.

Let's say we called our blueprint 'iOS Updates' rather than naming a specific OS version in the name of the blueprint. For now, I configure the target OS for iOS 18.3.1. But I have my ear to the ground and BETA test, so I am aware that 18.3.2 is coming very soon.

I could make the edit to the blueprint and change the target OS version to 18.3.2 without hitting deploy. This saves the amendment but doesn't deploy the edited blueprint. Then, when the new iOS version is released a few days later, I can simply hit deploy. All devices will get the new version of the declaration which targets 18.3.2.

Note that in our example, the targeted Smart Group criteria would need to change as well. But I wanted to highlight the flexibility of amending and editing blueprints and choosing when to deploy them.

In my example, I also created a 'macOS 15.3.1 updates' blueprint that I had not yet deployed. From the My Blueprints menu, you can see all the blueprints that have been created. You can also see if they have been deployed, never deployed, or if a change has been made since its last deployment.

Deploy a blueprint

To deploy a blueprint, simply select the deploy button in the top righthand corner. The declaration will then be deployed to devices that are in the selected Smart Groups.

If a device that becomes part of or falls out of scope of a group targeted by a blueprint, the declaration is added or removed accordingly.

In our example, if an iOS device OS is less than iOS 18.3, it will be part of our 'All iOS devices not on latest OS' group that our iOS 18.3.1 updates blueprint is scoped to.

Therefore, the iOS device will receive the software update declaration and go about updating the OS. Once the device is updated to iOS 18.3.1, it will fall out of scope for our 'All iOS devices not on latest OS group' and out of scope of the blueprint. The declaration will be removed from the device.

Alternatively, look at this through the lens of MathSettings.

Unlike software updates that you tend to deliver just once with each version, the MathSettings declaration—which prevents the use of MathSettings in the Calculator app—may need to be added and removed from the device multiple times in a week, depending on lesson needs. Creating a device group where devices can be added or removed as and when the MathSettings declaration is needed means that once the blueprint is configured with the required setting and targeting the desired group, changing the group membership is all you need to worry about.

The blueprint is essentially set and forget.

I've deployed a blueprint; now what?

So far, we've looked at the background of blueprints—or more so DDM—and how this differs from traditional MDM. We've looked at the admin workflow for creating a blueprint in Jamf School.

The question now is: What does this mean for the end user and how does this impact the usage of the iPad in the classroom?

Impact of blueprints on iPad in the classroom

Once again, there are a few things to point out.

First, Apple has been clear that new features and capabilities will favor DDM. Second, DDM makes the device more proactive and autonomous. Third, blueprints enable two declarations in this first release: a declaration that will fit with each of these use cases.

Starting with the new capability in iOS18, Apple released MathSettings as part of the Apple Intelligence suit of capabilities. This feature enables students to use this to create mathematical equations in the Calculator app.

Although this can be a great tool for students when the focus is less on execution and more on finding the correct equation, there will be times when a teacher wants to test the students understanding of how to solve the equation.

Apple provides a way to effectively turn off this feature if required in an educational setting. There's no real difference on the device in terms of how it acts from using a traditional profile and restrictions payload to disable, say, Siri. But it was a new feature. Therefore, when Apple released the ability for an admin to control the use of MathSettings, it was through a declaration rather than a typical restriction. As blueprints are the mechanism for configuring and deploying declarations, admins will now be able to enable and disable this feature as required in their environments.

The second point was making the device more proactive and autonomous. We will pick back up with our example of software updates to explain the end-user experience, the impact in the classroom and the benefits to the admin.

Managed software updates

Managing software updates on macOS or iOS devices is not new. It has been available to admins for a long time. Therefore, managing software updates via a declaration is not about being able to do something you've not before; it's about making it easier, more efficient and much more reliable.

It would be fair to say that in the past, pushing software updates has been hit and miss- which has lead to the creation of some macAdmin community tools to help with the user experience on macOS and little more, in some cases, than a fingers-crossed approach on iOS.

Without going into granular detail, the overall problem with the software update experience via traditional MDM was that the experience was very intrusive. Users were interrupted mid-task without any warning and left waiting while their devices updated, or the user had multiple ways of delaying the update for long periods of time. This resulted in a mixture of OS versions across a fleet, making them harder to manage and higher risk. Managed software updates using DDM via blueprints aims to solve both issues, giving the end user a much better experience while ensuring an admin delivers that vital update.

The admin experience

Let's remind ourselves of the items that we configured with the software update declaration. We added a date and time that the device must update by, and we chose a target OS. Notice that the date and time is the deadline for the update, not the exact time the update will take place.

When the declaration is sent to an iOS device, users can navigate to Settings -> General -> VPN & Device Management -> and select the Mobile Device Management profile. From here, you can see a new menu item called Configurations; this is where you can view declaration settings on the device.

You can then select a setting to see further details. For the software update settings, you should see the date and time deadline for the update and the target OS.

Once the blueprint is on the device, the admin's job is done; it's now up to the device to install the update by the given time. The device itself will still need enough storage space to download the update and enough charge to perform the update.

The update will start to install onto the device in the background, so caching the server is recommended if you're performing updates onsite/delivering blueprints on site, and will encourage the user to update their device manually using the settings app at a time that is convenient for them prior to the software update enforcement date.

If a device is off for a period of time, which includes the date and time added to the blueprint setting—perhaps somebody hasn't charged the device for a while, or it's off and in a drawer because it's the weekend—the device will update the next time it is on and has enough charge.

If a device has a passcode and the update is past due, the next time the user enters their passcode they will be required to perform the update. We will see this shortly in the user experience section what this looks like. If the user decides to just lock the device again, it will reboot and perform the update after a few minutes despite being locked.

You can also replicate this flow on macOS as long as the device has a bootstrap token.

Selecting an appropriate enforcement date and time

With the above in mind, it's worth thinking about the best period to set the enforce-by date and time.

This is a critical element to keep in mind. IT should work in tandem with curriculum leadership to avoid causing any learning disruptions.

But that's the beauty of DDM; it allows IT admins to roll out their settings, without forcing an immediate update. This can have a huge impact on productivity and efficiency for IT.

Since users are encouraged to download and install updates, they can update their devices at any time, but the device will be forced to update after the deadline with the next passcode unlock.

Here are a few examples of what to consider.

1:1 devices that go home
Deploying a blueprint might be better done during the evening so that the OS is cached to the device on the home network, reducing unnecessary stress on the school network. Since the device is also at home, the user may select to update the device overnight when it's not being used. It would also be wise to select an enforce-by time that is during the evening, as this doesn't impact on the classroom. You would be unpopular with teachers if student devices suddenly needed updating during lesson time.

Device with passcodes
Remember that if the enforce-by date and time is overdue and the device has a passcode, it will not update until the next time the user enters their passcode. Selecting an enforce-by date over the weekend might seem like a seem like a sensible idea until you realize that the devices don't get used over the weekend. Then, when educators and students come to use the devices on Monday morning, suddenly an entire class or even school can't use their iPad devices for the first 10-20 minutes of the lesson.

Devices in a shared cart
Often, these devices do not have a passcode. The idea for many devices is that any person at any time can pick up the device and start to use it. In this situation, setting an enforce-by date and time for the weekend would be good as without a passcode, the update will occur on the deadline. This way, an admin can be safe in the knowledge that come Monday morning, the devices will be ready for use and updated as required.

The user experience

Now that we've covered the admin experience and we understand how, when and why a device updates once it hits the enforce-by deadline, let's consider the user experience.

As noted above, software updates via DDM greatly improve a user's experience. In the past, with traditional MDM updates, the user may have received as little as a 60-second warning before the device reboots and performs an update with no regard to what the user was doing.

With blueprints and DDM, once a software update declaration lands on the device—in this example, an OS device—the user will get a notification explaining that an admin requires an update by a certain date and time. This notification will show on the lock screen of the device.

Depending on the length of time left before the update must occur, this will either show a date or the time in hours/mins. From there, as we saw before, if the user wants more detail about this update they can navigate to Settings -> General -> VPN & Device Management -> and select the Mobile Device Management profile -> Configurations.

This notification will update as time counts down, informing the user along the way.

If the device is in use when the declaration lands on the device, the user will see a notification that will enable them to download and install the update immediately or to view details of the update.

If it's been a while since the device was used, the software update may have already cached on the device. In that case, instead of Download and Install and Details, the student would be presented with Install Now and Details.

If the device needs to download the update and the user selects Download and Install, once the update is available on the device the student will get another notification asking if they want to install now or try later that night.

If the user selects Details, they will be taken to the Software Update panel of the settings app. Again, depending on the status of the software update, they will be presented with a loading bar or an install button along with the release notes for the update.

At this point, they are not required to install the update immediately. It is available to them for installation at any time that is convenient for them up until the enforcement date and time. If the student decides not to install the update there, the device will continue to notify about the impending due date with more regular frequency as the date and time approaches.

This gives the student plenty of time and notice to ensure that they are not mid-task or at a critical moment in a project when the update is due to take place. Once the enforce-by date and time is due or past due, the student will get another notification explaining that the update is due and that the device will perform the update automatically within the next hour.

If the student uses the device, they are presented with a notification which can only be dismissed by selecting Install Now and the only option is to update or lock the device again at which point the device will update. This is the same experience the user will face if the update is past due and there is a passcode present or the device was off/not charged during the enforce-by period.

Blueprints with Jamf School

The availability of blueprints in Jamf School brings with it DDM: specifically the ability to configure and deliver declarations to your fleet. With the two declarations available at release, admins will get the first glimpse into this new way of delivering device management. It's one that enables features previously unavailable, offers a better user experience, delivers the core functionality admins need, and displays the power of a proactive and autonomous device.

Blueprints will be a phased release to customers globally starting in April.