babgond

As part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to deploy MDM configuration profiles using DDM as the delivery mechanism in place of using MDM to deliver the profiles. Jamf Pro’s Blueprints leverages this capability to support deploying printers which can use AirPrint. Let’s see how this works with an AirPrint configuration, using an AirPrint-compatible printer which is set to use the following static IP address:

10.0.1.10

For more details, please see below the jump.

The first thing we need to do is use the ippfind command line tool to discover information about the printer we want to set up and print to. This process is described as part of Apple’s documentation for AirPrint payload settings for Apple devices, available via the link below:

https://support.apple.com/guide/deployment/airprint-payload-settings-dep3b4cf515/web (see the Set up an AirPrint printer in Apple Configurator for Mac section.)

Use the procedure below to discover the information needed:

1. Open Terminal.

2. Run the following command without root privileges:

ippfind

In this example, we’re getting back the following information about the printer:

From this, we can see the following information about the printer:

• Bonjour hostname: BRN466371FFF599.local
• Port number: 631
• Resource path: /ipp/print

We can use the BRN466371FFF599.local hostname to look up what the IP address of the responding printer is, which in this example is going to be the following IP address:

10.0.1.10

The port number is 631, or the default for the IPP protocol.

The resource path is /ipp/print, which we will need for setting up the AirPrint configuration in Blueprints.

Once we have this information, we’re ready to set up the AirPrint printer settings for deployment using Blueprints.

As of Jamf Pro 11.18.0, there is not a Blueprints template available for creating blueprints which manage AirPrint settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. Give it a name when prompted and click the Create button. For this example, I’m using Reception Desk Printer Settings.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the AirPrint component.

Note: AirPrint is listed as Legacy Payload. In Blueprints, a Legacy Payload type indicates that this is an MDM configuration profile being delivered via DDM.

6. Click on the AirPrint component and drag the AirPrint component to the Declaration group section.

7. Mouse over the AirPrint component and you will see a Configure button appear. Click the Configure button.

8. At this point, you will see an Air print section without any listed printers. Click the Add New Item button.

9. To add the settings for the printer in this example, set the following entries as follows:

• IP Address:
  • 10.0.1.10
• Resource path:
  • /ipp/print
• Port Number:
  • Make no changes
• Force TLS:
  • Make no changes

Note: Because we verified earlier that this printer is using port 631, which is the default port for the IPP protocol, it is not necessary to set the port number in the example AirPrint configuration we’re creating. In the event a printer does not use port 631, it would be necessary to set the port number here in the AirPrint configuration.

Likewise, if the printer was using TLS to secure the printer connection, it may be necessary to use the Force TLS setting. In this example, TLS is not being used so it is not necessary to configure the Force TLS setting.

10. Once all the settings choices have been made and verified, click the Save button.

11. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the Open button.

For this example, I’m selecting a static group named Printer Deployment Group.

Once the desired smart and/or static groups have been set and verified for the scope, click the Save button.

12. Once everything has been configured, Jamf Pro should inform you that you have undeployed changes. Click the Deploy button to deploy the changes to the Macs you want to manage.

13. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Reception Desk Printer Settings blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a legacy profile via Blueprints, you should see a Profiles section in Device Declarations. In the Profiles section, there is a listing with a name that matches the name of the blueprint which was deployed. In the case of our example, the listing shows Reception Desk Printer Settings.

If you click on the Reception Desk Printer Settings listing, you should see the details of what is being managed.

Note: The MDM profiles delivered via Blueprints are not signed. This is mentioned in the documentation available via the link below:

https://learn.jamf.com/en-US/bundle/jamf-pro-blueprints-configuration-guide/page/Blueprint_Builder.html

One thing to be aware of is that the AirPrint printer may not appear automatically. To add it, use the following procedure:

1. Open System Settings

2. Go to the Printers & Scanners settings

3. Click the Add Printer, Scanner, or Fax… button.

4. Select the printer which is identified as being the following kind:

AirPrint Profile

5. Click the Add button.

The printer should set up and configure itself using the printer’s AirPrint settings.

As part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to deploy MDM configuration profiles using DDM as the delivery mechanism in place of using MDM to deliver the profiles. Jamf Pro’s Blueprints leverages this capability to support device restrictions.

Let’s see how this works using a device restriction configuration, using the example of setting the following Apple Intelligence management functions to false in order to block the corresponding Apple Intelligence functions on macOS:

For more details, please see below the jump.

As of Jamf Pro 11.18.0, there is not a Blueprints template available for creating blueprints which manage device restrictions so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. Give it a name when prompted and click the Create button. For this example, I’m using Restrictions Settings for macOS.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the Restrictions component.

Note: The Restrictions component is listed as being the Legacy Payload type. In Blueprints, a Legacy Payload type indicates that this is an MDM configuration profile being delivered via DDM.

6. Click on the Restrictions component and drag the Restrictions component to the Declaration group section.

7. Mouse over the Restrictions component and you will see a Configure button appear. Click the Configure button.

8. At this point, you will see all available Restrictions settings which are available for all Apple platforms. To limit to only those options available for both macOS and Apple Intelligence, you can click the filter button and then select macOS in OS Type and Apple Intelligence in Category.

9. To apply the desired settings, select the following options and set them to false:

• Allow Genmoji
• Allow Image Playground
• Allow Mail Smart Replies
• Allow manual mail summaries
• Allow writing tools

10. Once all the settings choices have been made and verified, click the Save button.

11. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the Open button.

For this example, I’m selecting a static group named Restrictions Deployment Group.

Once the desired smart and/or static groups have been set and verified for the scope, click the Save button.

12. Once everything has been configured, Jamf Pro should inform you that you have undeployed changes. Click the Deploy button to deploy the new restrictions settings to the Macs you want to manage.

13. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Restrictions Settings for macOS blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying an MDM configuration profile via Blueprints, you should see a Profiles section in Device Declarations. In the Profiles section, there is a listing with a name that matches the name of the blueprint which was deployed. In the case of our example, the listing shows Restrictions Settings for macOS.

If you click on the Restrictions Settings for macOS listing, you should see the details of what is being managed.

Note: The MDM profiles delivered via Blueprints are not signed. This is mentioned in the documentation available via the link below:

https://learn.jamf.com/en-US/bundle/jamf-pro-blueprints-configuration-guide/page/Blueprint_Builder.html

As part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to manage software updates. Jamf Pro’s Blueprints leverages this capability to support managing software updates. Let’s see how this works using the following software update configuration as an example:

• Standard users can install Apple software updates
• Logged-in users will see all software update notifications
• OS updates will be automatically downloaded
• OS updates will be automatically installed
• Security updates will be automatically installed
• Rapid Security Response updates will be installed
• Rapid Security Response updates can be removed

For more details, please see below the jump.

As of Jamf Pro 11.18.0, there is not a Blueprints template available for creating blueprints which manage software updates so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. Give it a name when prompted and click the Create button. For this example, I’m using Software Update Settings.

5. You should see an unconfigured Blueprint. Scroll down in the list on the right-hand side of the browser window to locate the Software Update Settings component.

6. Click on the Software Update Settings component and drag the Software Update Settings component to the Declaration group section.

7. Mouse over the Software Update Settings component and you will see a Configure button appear.

Click the Configure button.

8. At this point, you will see all available Software Update settings which are available for all Apple platforms. To limit to only those options available for macOS, you can click the filter button and then select macOS. Once the desired filter(s) have been selected, click the Apply button.

9. To apply the following desired settings, select the following options:

• Standard users can install Apple software updates:

Select Enable for Allow standard users to install software updates

• Logged-in users will see all software update notifications:

Select Enable for Notification preference for updates scheduled by declarations

Once those options are selected, you’ll need to configure the Install actions and Rapid Security Response sections to achieve the following desired settings:

• OS updates will be automatically downloaded
• OS updates will be automatically installed
• Security updates will be automatically installed
• Rapid Security Response updates will be installed
• Rapid Security Response updates can be removed

To access the Install actions and Rapid Security Response sections, click their associated Configure buttons.

In the Install actions section, to apply the following desired settings, select the following options:

• OS updates will be automatically downloaded:

Select Always for Automatic installs of available updates

• OS updates will be automatically installed:

Select Always for Automatic downloads of available OS updates

Note: Selecting Always for Automatic installs of available updates will also automatically set Always for Automatic downloads of available OS updates.

• Security updates will be automatically installed:

Select Always for Automatic installs of available security updates

Once all choices have been made and verified, click the Update button.

You should now see the following items set to Always:

• Automatic installs of available updates
• Automatic downloads of available OS updates
• Automatic installs of available security updates

From there, scroll down to the Rapid Security Response section and click the Configure button.

In the Rapid Security Response section, to apply the following desired settings, select the following options:

• Rapid Security Response updates will be installed:

Select Allow for Rapid Security Response installation

• Rapid Security Response updates can be removed:

Select Allow for Rapid Security Response removal

Once all choices have been made and verified, click the Update button.

You should now see the following items set to Enabled:

• Rapid Security Response installation
• Rapid Security Response removal

10. Once all the settings choices have been made and verified, click the Save button.

11. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the Open button.

For this example, I’m selecting a static group named Managed Software Update Deployment Group. Once the desired smart and/or static groups have been set and verified for the scope, click the Save button.

12. Once everything has been configured, Jamf Pro should inform you that you have undeployed changes. Click the Deploy button to deploy the changes to the Macs you want to manage.

13. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Software Update Settings blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a software update configuration via Blueprints, you should see a Global Settings listing for Software Update in the Device Declarations section.

If you click on the Global Settings listing, you should see the details of the configuration.

You can also see the details of what’s configured in System Settings: General: Software Update.

In this case, you can click on the ( i ) button next to the Automatic Updates section and see the settings which have been applied.

One way to deliver custom fonts on macOS is to deploy them via a configuration profile. In this case, you’re deploying a profile which includes a copy of the font file or files. For example, here’s how the open source Caprasimo font looks when deployed via a profile.

You can access information about the font in question using the Font Book app on macOS Sequoia.

In Font Book.app, you should see the profile-deployed font appearing in the My Fonts section. You can also access information about the font from here.

But how do you extract the font file from the profile? You can also do this using the Font Book app. For more details, see below the jump.

You can use the following procedure to export a font which was installed using a configuration profile:

1. Open Font Book.app.

2. Find the font in question and select it.

3. Under the File menu, choose the Export… option.

4. Select where you want to save the exported font file to.

5. Verify that the font file has been exported to the desired location.

One of the user interface features in macOS is what Apple refers to as Vibrancy, where the color displayed for Finder windows, menus, the Dock, the menubar and other interfaces subtly change to reflect the colors behind them. This produces a translucent visual effect for those interfaces.

This feature, first introduced in OS X 10.10 Yosemite, can come at a cost in terms of processor and GPU resources because this visual effect is being recalculated and redrawn as needed. For those who want to reclaim those resources, it’s possible to turn Vibrancy off if needed. On macOS Sequoia, this is managed via the following setting in System Settings:

System Settings: Accessibility: Display: Reduce Transparency

With the Reduce transparency setting enabled, Vibrancy is turned off and the various interface components should change from their Vibrancy-managed translucent appearance to a non-translucent gray appearance.

As of macOS Sequoia, it does not appear to be possible to manage the Reduce transparency setting using a defaults command but it is possible to manage it via a configuration profile. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.universalaccess
• Key: reduceTransparency
• Value: Boolean

Setting a boolean value of true will disable Vibrancy on macOS Sequoia. I’ve built a configuration profile with the boolean value of true set, where the profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/main/ReduceTransparency

As part of Apple’s discussion of Declarative Device Management (DDM) at WWDC 2024, Apple announced that DDM management on macOS 15 Sequoia and later now included the ability to allow or block external and network storage. You can manage the following:

• External storage devices
• Network storage

The following mount policies can be specified for both external and network storage:

• Allowed: The system can mount storage that’s read-write or read-only.
• Read-only: The system can only mount read-only storage. Storage that is read-write is not mounted read-only.
• Disallowed: The system can’t mount any external storage.

Note: The read-only options are for mounting storage which is already read-only. If macOS can detect that the storage is read-write when it tries to mount the storage in question, macOS won’t mount the storage and will display an error message.

Jamf Pro’s Blueprints supports deploying and managing these disk management controls via the Disk management policy component. Let’s see how this looks, using the following example:

Goal

Block network storage from mounting

For more details, please see below the jump.

I can set up a Blueprint in Jamf Pro to deploy this network storage management configuration using the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Open button for Install disk management settings.

4. Give it a name when prompted. For this example, I’m using Block Network Storage.

5. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Disk Management Deployment Group.

6. In the Disk Management Policy section, select the following settings:

• Click the checkbox for Network storage.
• Click the button for Disallowed.

7. Once all the information has been entered and verified to be correct, click the Save button.

Once everything has been configured, Jamf Pro should inform you that you have undeployed changes. Click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Block Network Storage Blueprint as being deployed.

On your managed devices, you can verify that the new service background task configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom. In the case of this example, you should see a Device Declarations section with a listing for Disk Management.

If you click on the Disk Management listing, it should report the following:

• Network Storage Restriction: Not Allowed

You can verify that the network storage restriction is working by running the following test:

1. Connect to a network storage server.

2. Log in using your credentials.

3. When the server presents the list of available network storage shares, select one your user account should have access to.

If the network storage restriction is working, you should receive an error when macOS tries to mount the network share. This is because the network storage restriction is acting at the time when macOS is trying to mount the network share.

Alongside macOS Tahoe being the last macOS version to support Macs with Intel processors, Apple has announced a transition timeline for macOS’s Rosetta 2 translation environment.

Apple first announced Rosetta 2 as being available for macOS Big Sur in 2020. It is an optionally installed binary translator for macOS, which allows applications written only for Macs with Intel processors to also run on Macs with Apple Silicon processors. As with the previous Rosetta, where the goal was to smooth the transition from Power PC processors to Intel processors, Rosetta 2’s goal was to likewise smooth the transition from Intel processors to Apple Silicon processors by enabling Intel-only applications to run on Apple Silicon Macs. With Intel support in macOS now having an official retirement version with macOS Tahoe, Rosetta 2 is likewise transitioning over time.

Apple has committed to making Rosetta 2 in its current form available for the next two OS releases, with macOS 26 being the first OS release and macOS 27 being the second OS release. Apple has not described what will happen with Rosetta 2 beyond macOS 27, beyond stating that they will be keeping a subset of Rosetta functionality available to support certain Intel-based frameworks. The goal of the support for these not-yet specified Intel-based frameworks is to allow older unmaintained gaming titles to run on macOS past macOS 27.

As part of Apple’s discussion of Declarative Device Management (DDM) at WWDC 2024, Apple announced that DDM management on macOS 15 Sequoia and later now included the ability to manage sets of tamper-resistant files which run tasks either on behalf of the logged-in user or which run with root privileges to provide services in the background. Running these tasks may involve any of the following:

• Executable binaries
• Scripts
• Configuration files for the tools being used

In turn, these tools are triggered by the following LaunchD items:

• Launch agents – to run the task for the logged-in user
• Launch daemons – to run the task with root privileges

Jamf Pro’s Blueprints supports deploying and managing these service background tasks via the Service background tasks component. Let’s see how this looks, using the following example:

Goal

Using a service background task to run a Jamf Pro inventory update each time the managed Mac starts up.

Tools used

• A script to run a Jamf Pro inventory update using the Jamf agent
• A LaunchDaemon to run the script when the Mac starts up.

For more details, please see below the jump.

To deploy this script and LaunchDaemon with Blueprints as a service background task, several things are needed. To start with, we need the following:

1. The script
2. The LaunchDaemon

The script is named runjamfproinventoryupdate.sh and is available below:

The LaunchDaemon file is named com.github.runjamfproinventoryupdate.plist and is available below:

One thing to note is that the LaunchDaemon is running the runjamfproinventoryupdate.sh script at the following location:

/private/var/db/ManagedConfigurationFiles/BackgroundTaskServices/Services/com.github.runjamfproinventoryupdate/runjamfproinventoryupdate.sh

/private/var/db/ManagedConfigurationFiles/BackgroundTaskServices/Services is the tamper-resistant directory where macOS is storing the executable binaries, scripts, etc. it uses to run service background tasks. The LaunchAgents and LaunchDaemons are stored in separate tamper-resistant directories within /private/var/db/ManagedConfigurationFiles/BackgroundTaskServices:

• LaunchAgents: /private/var/db/ManagedConfigurationFiles/BackgroundTaskServices/LaunchAgents
• LaunchDaemons: /private/var/db/ManagedConfigurationFiles/BackgroundTaskServices/LaunchDaemons

Meanwhile, the runjamfproinventoryupdate.sh script is itself being stored inside a com.github.runjamfproinventoryupdate directory. This directory is named to match the label of the LaunchDaemon being deployed to run this service background task: com.github.runjamfproinventoryupdate

Once you have the script and the LaunchDaemon available, the following items are needed:

1. A zip file which contains both the directory and file structure of the script in question.

The script is stored in a directory named com.github.runjamfproinventoryupdate and the file is named runjamfproinventoryupdate.sh, so a zip file containing a directory named com.github.runjamfproinventoryupdate, with the script set to be executable and named runjamfproinventoryupdate.sh inside the com.github.runjamfproinventoryupdate directory, is needed for this.

For this example, we’ll name the zip file as com.github.runjamfproinventoryupdate.zip.

2. The SHA-256 hash of the zip file.

You can use the sha256sum command line tool to get the SHA-256 hash of the zip file, so using a command similar to the one shown below should provide that information:

Assuming our SHA-256 hash is 48fa6c5e25590536970e71ae4bdf02c5153dbcb12ae5a3c2c7682ac94e065582, you should see output like this when you run the command above:

3. The SHA-256 hash of the LaunchDaemon file

Assuming our SHA-256 hash is d913416e04862a8dfa5d58ba9ca045bc8527da7e40b9cdee608d4dcbd4104183, you should see output like this when you run the command above:

4. A place to download the zip and LaunchDaemon files from, which allows downloading without authentication.

For this example, I’ve set up an S3 bucket in Amazon Web Services named 75d831079efb4d02ada44eed4f8ae093 and uploaded the .zip and LaunchDaemon files. Once uploaded, the following files were set to be publicly accessible from that S3 bucket:

• com.github.runjamfproinventoryupdate.zip
• com.github.runjamfproinventoryupdate.plist

Once I have all the above available, I can set up a Blueprint in Jamf Pro to deploy the sudo configuration file as a Service configuration file.

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Open button for Service background tasks.

4. Give it a name when prompted. For this example, I’m using Run Jamf Pro Inventory at Startup.

5. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Service Background Task Deployment Group.

6. Provide the necessary information to download the com.github.runjamfproinventoryupdate.zip and com.github.runjamfproinventoryupdate.plist files.

Task Type:

The name provided here must exactly match the label of the LaunchDaemon being deployed to run this service background task. In this case, this means that the name used here is the following:

com.github.runjamfproinventoryupdate

Description:

This is optional, you may fill this in or not as desired.

Executable asset:

This is the zip file with the runjamfproinventoryupdate.sh script inside. For this example, the following information is being used:

• Data URL: https://75d831079efb4d02ada44eed4f8ae093.s3.us-east-1.amazonaws.com/com.github.runjamfproinventoryupdate.zip
• SHA-256 Hash: 48fa6c5e25590536970e71ae4bdf02c5153dbcb12ae5a3c2c7682ac94e065582
• Content type: application/zip

Launchd asset #1:

This is the com.github.runjamfproinventoryupdate.plist LaunchDaemon which is triggering the runjamfproinventoryupdate.sh script to run. For this example, the following information is being used:

• Data URL: https://75d831079efb4d02ada44eed4f8ae093.s3.us-east-1.amazonaws.com/com.github.runjamfproinventoryupdate.plist
• SHA-256 Hash: d913416e04862a8dfa5d58ba9ca045bc8527da7e40b9cdee608d4dcbd4104183
• Content type: application/xml

Important Note

Wherever you’re downloading the LaunchDaemon file from, it’s important that the content headers being provided for that file match what is set for the content type in the service background task’s configuration. Otherwise, what will occur is that the service configuration task will not install on your managed Macs.

While testing this on my end, I initially could not get the configuration to work and couldn’t figure out why until I checked the headers I was getting from Amazon’s S3 service. Those headers looked similar to this:

The Content-Type header was reporting the following:

Content-Type: binary/octet-stream

Fortunately, I was able to change the content type by using the AWS CLI tool to run the following command to force the content-header I wanted for the com.github.runjamfproinventoryupdate.plist LaunchDaemon file:

Note: S3_BUCKET_HERE is a placeholder for the name of the actual S3 bucket being used.

Once that was done, the headers now looked like this:

Now that the Content-Type header was reporting the following to match the application/xml content type set for my configuration, the configuration applied successfully:

Content-Type: application/xml

Returning to our example, once all the information has been entered and verified to be correct, click the Save button.

Once everything has been configured, Jamf Pro should inform you that you have undeployed changes. Click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Run Jamf Pro Inventory at Startup blueprint as being deployed.

On your managed devices, you can verify that the new service background task configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom.

In the case of this example, you should see a Device Declarations section with a listing for Background Tasks: com.github.runjamfproinventoryupdate.

If you click on the Background Tasks: com.github.runjamfproinventoryupdate listing, it should report the following:

• It has an executable file – this is the runjamfproinventoryupdate.sh script
• The count of Daemon plist files – This reflects that only the com.github.runjamfproinventoryupdate.plist LaunchDaemon was deployed.
• The count of Agent plist files – This reflects that no LaunchAgents were deployed.

In January 2006, Apple released the first generation of Macs which used Intel processors in place of the previous line of Power PC processors. These Macs, running a special Intel-only build of Mac OS X Tiger 10.4.4, marked the second time Apple had switched processor architectures.

In 2020, Apple announced a similar third transition from Intel processors to Apple-designed Apple Silicon processors. Beginning in November 2020, Apple has steadily released new Mac models which used Apple Silicon processors and phased out Mac models which used Intel processors. The final Mac model to transition to Apple Silicon was the Mac Pro in 2023.

With Apple no longer selling any Mac models which use Intel processors, it was just a matter of time before Apple announced that, like it had done for previous processor transitions, that a particular macOS release would be the final one to support Macs using Intel processors. Apple made that announcement today at WWDC 2025, as part of the Platform State of the Union session video.

For macOS Tahoe, the following Intel Mac models are supported:

• 2019 16-inch MacBook Pro
• 2020 13-inch MacBook Pro with four Thunderbolt 3 ports
• 2020 iMac
• 2019 Mac Pro

One of the management options Jamf Pro provides is sending MDM commands or DDM declarations to managed Macs run macOS software updates automatically. For Macs, Jamf Pro includes this functionality in the Software Updates section under Computers. If you have not previously used the Software Updates functionality, by default it is turned off and needs to be enabled.

Once enabled, you should see a list of the smart and static computer groups set up on your Jamf Pro server. To set up a software update plan for one of those groups, click the desired group and then click Update 1 Selected.

Note: It’s possible to select multiple groups at once and set the same software plan for all selected groups.

Once the groups have been selected for update, you’ll be provided with the various options available. Four of these options use MDM commands and one will use a DDM declaration:

MDM commands:

• Download only
• Download and install
• Download, install and allow deferral
• Download, install, and restart

DDM declaration:

• Download and schedule to install

One reason it is important to know which use MDM commands and which use DDM declarations is that the MDM command method is supported on the following versions of macOS:

• macOS 10.11 and later

The DDM declaration method is supported on the following versions of macOS:

• macOS 14 and later

Note: The DDM declaration method works for Jamf Pro instances hosted in Jamf Cloud and does not work for on-premise Jamf Pro installations. If you are using an on-premise Jamf Pro installation, the Download and schedule to install option is grayed out and there is a note explaining that this method is only supported for Jamf Cloud-hosted environments.

You will also get various update options:

• Latest version based on device eligibility – This will download and install the latest version of macOS that the managed device can run.
• Latest major version – This will download and install the latest major version of macOS, like macOS 14.0 or macOS 15.0, if the managed device is running an earlier major version of macOS.
• Latest minor version – This will download and install the latest update to the major version macOS that the managed device is using, like updating a macOS 15.14.1 device to macOS 15.5
• Specific version – This will download and install the update for a specific macOS version, like macOS 15.4.1.

Note: The Specific version setting assumes that the version in question is still available from Apple’s software update feed. If it is not, then that version will not be downloaded or installed.

Managed software update plan behavior:

Something important to know about managed software update plans is that they were built to act like Jamf Pro’s functionality for sending out MDM commands via a mass action. You select the devices you wanted to apply the mass action to (or in this case, the software update plan) and Jamf Pro would send the commands out. When choosing a smart or static group and setting up a software update plan, the commands for that software update plan will be sent to only the devices in that group at that point in time.

If a device subsequently enters the smart group or static group in question, it will not receive the commands which had been previously sent out. Please note that this also means that leaving the smart or static group will not remove a previously applied software update plan.

For more details, please see below the jump.

Setting up managed software update plans:

For how this works, let’s run through an example workflow. For this example workflow, the following assumptions are being made:

1. The Jamf Pro instance sending the software update plan is hosted in Jamf Cloud.
2. The DDM declaration method is being used.
3. One Mac is being updated.
4. The Mac receiving the software update plan is running macOS Sequoia 15.4.1 and updating to the latest OS version the device can support (which in this case should be 15.5.0.)
5. The software update plan is being run at a time prior to May 24, 2025.

With these assumptions, my first step is selecting a group to apply the software update plan to. For this example, I’ve set up a static group named Managed Software Update Deployment Group and assigned one device to it.

1. From the list of groups in the Software Updates window, select the Managed Software Update Deployment Group static group.

2. Click the Update 1 Selected button.

3. Select the following option to choose the available DDM declaration method:

• Download and schedule to install

4. Choose a date by which the software update should apply.

5. Choose the OS version update option.

In this example, I am choosing the Latest version based on device eligibility option.

6. Once all choices have been made, verify that they are what is desired. Once verified, click the Apply button.

7. You should be notified how many devices have received the software update plan.

Once the software update plan has been deployed, you should be able to check in the computer inventory record for the device(s) and verify that they have received the software update plan.

For details, you can click the View event store link in the computer inventory record.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a software update plan via DDM, you should see a listing for that software update plan in the Device Declarations section.

If you click on that listing, you should see the details of the plan.

From the user’s perspective, they should see a Notifications center notification appear with two available options:

• Details
• Update

When you click the Details button, you should see behavior similar to what’s shown below:

When you click the Update button, you should see behavior similar to what’s shown below:

Note: The video above has been edited to artificially reduce the amount of time the OS update took to run. Run time of the pre-edited video was 27 minutes 32 seconds.

Once the update has completed, you should be able to check in the computer inventory record for the device(s) and verify that they do not have an active software update plan.

You should also be able to check the history and verify whether the software update was successful or not. For details about the process, click the Details button.

Something that is important to know about the reporting is that when Jamf Pro deploys a software update plan which uses DDM declarations, it is doing two things:

1. Providing the software update plan to the managed devices.
2. Listening to what is reported back by the Mac.

Any reported errors which show up in Jamf Pro are coming back from macOS, so if macOS reports a failure on its end, that’s what Jamf Pro also reports. When Jamf Pro gets a failure message from a managed Mac, it stops listening at that point and does not pick up on any subsequent activity from that managed device for that software update plan. However, on the managed device side, macOS may retry running the software update process and subsequently succeed. This may lead to some results which seem paradoxical, where the managed device reports that the software update plan failed, but the managed device is separately reporting that it’s running the desired version of macOS.

The reporting that Jamf Pro gets back from the managed Mac may also not include a lot of information about the software update process. For example, here’s a report I received from a macOS VM which updated from 15.4.1 to 15.5.0. It does not include a lot of information about the update process itself but the report does include a VerificationResultEvent item, which tells Jamf Pro that the overall DDM software update process was successful.

Clearing existing managed software update plans:

As mentioned previously, managed software update plans function in a similar way to mass actions, where the commands for that software update plan will be sent to only the devices in that group at that point in time. Since it can be a challenge to track which devices may be affected once that plan has been deployed, it may be easiest to cancel all current software update plans and set up new ones when needed. To do this, use the procedure shown below:

1. Go to the Software Updates section.

2. Click the Use new feature toggle to turn the managed software update function off.

3. Jamf Pro will confirm that you want to turn the managed software update function off, along with a count of the devices that have software update plans currently applied. Click the Disable button to confirm.

4. Jamf Pro will clear all existing software update plans from managed devices.

5. The managed software update function will be turned off.

6. To turn the managed software update function back on, click the Enable button.

7. Jamf Pro will confirm that you want to turn the managed software update function on, along with a count of the devices that have software update plans currently applied. Click the Enable button to confirm.

8. The Software Updates section will again show a list of the smart and static computer groups set up on your Jamf Pro server.

Note: Turning the Software Updates functionality off and back on will clear all previously existing records of software update plans or those plans’ results. Jamf Pro will have no records of any previous software update plans at this point.

For more information on using Jamf Pro’s managed software updates, please see the documentation linked below:

• Updating macOS Using Managed Software Updates: https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/Updating_macOS_Using_Managed_Software_Updates.html
• Troubleshooting Managed Software Updates in Jamf Pro: https://learn.jamf.com/en-US/bundle/technical-articles/page/Troubleshooting_Managed_Software_Updates_in_Jamf_Pro.html