Skip to main content

This guide represents the synergy of the latest technologies from Apple and Jamf. It harnesses the power of the new Declarative Device Management (DDM) framework built into macOS 15 (Sequoia). This modern approach is unlocked by Jamf Pro version 11.8.0 or later, which introduces Software Update Blueprints. Critically, this entire workflow is powered by the Jamf Account SSO, which connects your instance to the cloud micro-services required for Blueprints to function, creating a truly modern administrative experience.

The guide outlines the modern, three-part strategy for managing macOS 15 and newer in Jamf Pro. It leverages DDM via Blueprints for a reliable, automated workflow and is based on enterprise best practices for both aggressive and controlled rollouts.

Prerequisites

Before you begin, ensure your environment meets these minimum requirements:

  • Jamf Pro: Version 11.18.0 or later.
  • Target Computers: macOS 15 (Sequoia) or later.
  • Device Supervision: Devices must be Supervised.
  • Administrator Authentication: Single Sign-On (SSO) must be enabled for your Jamf Pro user accounts to ensure a modern and secure administrative environment. For more information, see Jamf SSO.
  • Apple Push Notification service (APNs): A valid APNs certificate is required for all communication.

A Primer on Declarative Device Management (DDM)

It is important to understand why this new method is superior to older approaches.

  • The “Old Way” (MDM Commands & Scripts): Previously, managing updates was a “command and control” process where the Jamf Pro server sent direct push commands. This was often unreliable if devices were offline and required third-party tools and scripts to fill gaps in persistence and user experience.
  • The “New Way” (DDM & Blueprints): Declarative Device Management is a “desired state” model. The server sends a declaration to the device describing the goal (e.g., “be on the latest macOS, after a 30-day delay”). The device itself becomes responsible for achieving this state autonomously, reporting its progress back. This is more resilient, reliable, and provides richer status reporting. Blueprints are Jamf’s tool for creating and deploying these declarations.

Part 1: The “All-in-One” Policy with Jamf Pro Blueprints

For macOS 15+, Blueprints are the definitive way to manage updates. This single object contains all the rules for your fleet, eliminating the need for multiple, complex profiles.

  1. In Jamf Pro, navigate to Blueprints. For more information, see the Jamf Pro Blueprints Configuration Guide.
  2. Click Create blueprint and name it [macOS 15+] Standard Update Policy.
  3. Drag the Software Update Settings component into the builder and click Configure.
  4. Set Your Deferral Period: This is the first and most critical step, as it creates your testing window. Set your deferral days. A common enterprise policy is:
    • Major OS Deferral Days: 30
    • Minor OS Deferral Days: 14
       

      5. Configure Automatic Install Actions: Next, tell devices how to act once the deferral period is over.

    • Find the Install actions section and click its Configure button.
    • For OS Updates: Under Automatic installs of available updates, check the box and select Always.
    • For Security Updates: Under Automatic installs of available security updates, you must also check the box separately and select Always.
  1. Save the component and then Save the Blueprint.
  1. Scope the Blueprint to your macOS 15+ computer group and click Deploy.

Note: The “Software Update Settings” component contains additional options. For this core workflow, they are not essential and can be left at their default values.

 

 

 

Part 2: Monitoring and Reporting

Choose a monitoring strategy that matches your organization’s policy.

Step 2.1: Create the macOS Patch Software Title (Required for “Latest” Tracking)

This one-time setup enables robust reporting for the “latest version” strategy.

  1. Navigate to Computers > Patch Management. For more details, see Patch Management Software Titles.
  2. Click New, search for macOS, and select the relevant title (e.g., “Apple macOS Sequoia”).
  3. Save the title.

Step 2.2: Create a Compliance Smart Group

Option A: Tracking the Absolute Latest Version (Recommended)

  1. Display Name: [macOS 15+] Patch Compliance: Not on Latest OS.
  2. Criteria: Patch Reporting: Software Title > “Apple macOS Sequoia” | is not | Latest Version.
  3. Click Save.

Option B: Tracking a Specific, Approved Version (Alternative)

Use this when the latest version (e.g., 15.5) is deferred, and your goal is to enforce the previously approved version (15.4).

  1. Display Name: [macOS 15+] Compliance: Not on Approved Version (15.4).
  2. Criteria: Operating System Version | less than | 15.4.
  3. Click Save.

Part 3: Periodic Maintenance & Enforcement

This is your periodic task to enforce compliance. The enforcement action must match the Smart Group you are targeting.

  1. Navigate to Computers > Software Updates. For details, see Managed Software Updates for macOS.
  2. Select the appropriate Smart Group from Part 2.
  3. Click Update Selected.
  4. Configure the DDM action that aligns with your goal:

Choice A: Enforcing the “Latest” Version

  • Version: Keep the default: Latest version based on device eligibility.
  • Schedule Type: Force install at date and time.

Choice B: Enforcing a “Specific” Version

  • Version: Change to Specific version (e.g., 15.4).
  • Schedule Type: Force install at date and time.

After configuring, click Apply to send the enforcement command.

 

 

 

 

 Appendix: Troubleshooting Common Issues

Troubleshooting Blueprints & DDM (Part 1)

Monitoring and troubleshooting the status of DDM declarations is an advanced topic that currently relies on using the Jamf Pro API, not a graphical interface within a computer’s record.

For detailed, technical instructions, refer to the official Jamf documentation:

This guide provides the necessary API endpoints for administrators to programmatically check the status of deployed Blueprints.

Troubleshooting Managed Software Updates (Part 3)

When a manual enforcement command fails, you can use the GUI to investigate the target computer’s record.

1. Check the Command Status:

  • Go to the Management tab -> Pending Commands and Completed Commands.
  • If a command is stuck in “Pending,” the device may be offline or have APNs issues. See Troubleshooting APNs.
  • Check Failed Commands for specific error messages.

2. Check for Common Prerequisites:

  • Supervision: The device must be Supervised.
  • Bootstrap Token (Critical for Apple silicon): For an update to install without user password entry, Jamf Pro must hold a Bootstrap Token. Check its status in the computer’s inventory under Security. For more information, see Leveraging Apple’s Bootstrap Token.
  • Disk Space & Power: The device must have sufficient free storage and be connected to power or adequately charged.

Great article ​@Ninyo 

Nice write up! I would have delineated DDMU and DDMU w/ blueprints.  DDMU is natively available without blueprints (and the arguable JAMF SSO need).

So natively with Jamf Pro (without Jamf SSO), DDMU can be had via “Software Updates” section.  It does perform declarations but there’s no way to cancel them without, unfortunately, canceling them for the whole tenant.  DDMU with blueprints allows for single device removals at the **cost of integrating Jamf SSO.  

**I use the word “cost” because there’s setup time and knowledge associated with this.

Very nice wrietup!

Just enough details to launch it, with clear descriptions, steps, and helpful screenshots.

 

Many thanks!

You might also wish to clarify hosted vs on-premise Jamf Pro (yes, some of us are still a bit behind the times).

This will come in handy once we switch to Jamf Cloud. No DDM for on-prem customers. 

You might also wish to clarify hosted vs on-premise Jamf Pro (yes, some of us are still a bit behind the times).

We almost went back to on-prem to run it in a cloud redundant manner (multicloud) and a cloud based load balancer.  That outage earlier this year queued up the talks and architecting of how that’d look for us.

You might also wish to clarify hosted vs on-premise Jamf Pro (yes, some of us are still a bit behind the times).

Thank you very much for taking the time to read and pointing this out, and I understand your point.
Though as SSO is the prerequisite here, this is what I stated, along with a link to an article detailing its own prerequisites. 

Nice write up! I would have delineated DDMU and DDMU w/ blueprints.  DDMU is natively available without blueprints (and the arguable JAMF SSO need).

So natively with Jamf Pro (without Jamf SSO), DDMU can be had via “Software Updates” section.  It does perform declarations but there’s no way to cancel them without, unfortunately, canceling them for the whole tenant.  DDMU with blueprints allows for single device removals at the **cost of integrating Jamf SSO.  

**I use the word “cost” because there’s setup time and knowledge associated with this.

​@Chubs how do you cancel the declaration if you used blueprint? do you just unscope the machine from the blueprint and the declaration is canceled for that particular machine?

Nice write up! I would have delineated DDMU and DDMU w/ blueprints.  DDMU is natively available without blueprints (and the arguable JAMF SSO need).

So natively with Jamf Pro (without Jamf SSO), DDMU can be had via “Software Updates” section.  It does perform declarations but there’s no way to cancel them without, unfortunately, canceling them for the whole tenant.  DDMU with blueprints allows for single device removals at the **cost of integrating Jamf SSO.  

**I use the word “cost” because there’s setup time and knowledge associated with this.

​@Chubs how do you cancel the declaration if you used blueprint? do you just unscope the machine from the blueprint and the declaration is canceled for that particular machine?

That is what I’ve been told/read.  Once you exclude or unscope it, the declaration is canceled.  We are not currently “JAMF SSO’d” yet so I don’t have any way to test. 

Great Write Up. Love it!!

Good write up. Much appreciated!

@chubs do you have a step-by-step guide for the DDMU without a blueprint? we’re also hesitant for Jamf-sso.

Normally I Manually create a new software update 9see picture) when an update comes available, but automated is handier...

 

Maybe I’m missing something here but what is the difference if I would just push the force install date command to all computers? I need to set the date for each OS update manually anyways.

Nice write up! I would have delineated DDMU and DDMU w/ blueprints.  DDMU is natively available without blueprints (and the arguable JAMF SSO need).

So natively with Jamf Pro (without Jamf SSO), DDMU can be had via “Software Updates” section.  It does perform declarations but there’s no way to cancel them without, unfortunately, canceling them for the whole tenant.  DDMU with blueprints allows for single device removals at the **cost of integrating Jamf SSO.  

**I use the word “cost” because there’s setup time and knowledge associated with this.

​@Chubs how do you cancel the declaration if you used blueprint? do you just unscope the machine from the blueprint and the declaration is canceled for that particular machine?

That is what I’ve been told/read.  Once you exclude or unscope it, the declaration is canceled.  We are not currently “JAMF SSO’d” yet so I don’t have any way to test. 

Ok i finally got around to testing, and yes, this is accurate. if you have deployed an update to a group via blueprint, and then remove a machine from the scoped group, you will get a notification popup in jamf letting you know it will be removed from the deployment and once confirmed, you will see the update declaration removed from the machine immediately. here is a screenshot of the popup notification when you remove a machine from the scoped group.

 

Terms & ConditionsCookie settingsAccessibility statement