babgond

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

A number of session videos (including mine) have been posted from MacAD.UK 2025. For those interested, the videos are available on YouTube via the link below:

https://youtube.com/playlist?list=PLmBOyWhgnnx91uGb6YiCfJ0Nhhxs3Lxqr&si=kPCWKS5Ubddze3x7

For convenience, I’ve linked my session here.

Sometimes as part of troubleshooting mobile device management (MDM) problems, you need to look at the list of installed profiles to make sure the profile you need is actually installed. On macOS Sequoia, the list of installed profiles appears in System Settings: General: Device Management.

But where do you go to look for declarative device management (DDM) settings that have been deployed to your Mac? Those can also be looked up via System Settings: General: Device Management, by 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. That’s where you’ll be able to see what DDM-deployed settings have been applied to your Mac. For example, if you’re deploying configurations for the sudo command line tool, you should see a Device Declarations section, with a listing for Configuration Files: com.apple.sudo.

If you click on the Configuration Files: com.apple.sudo listing, it should provide the path to the tamper-resistant directory where it stored the DDM-deployed configuration file for the sudo command line tool. This should be the following location:

/private/var/db/ManagedConfigurationFiles/com.apple.sudo

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.

As part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to manage sets of tamper-resistant system configuration files for different system services. As of this date, the following services built into macOS can be managed this way:

• sshd
• sudo
• PAM
• CUPS
• Apache httpd
• bash
• zsh

Jamf Pro’s Blueprints supports managing these services via the Service configuration files component. Let’s see how this looks, using management of the sudo command line tool‘s configuration as an example. For more details, please see below the jump.

By default, macOS 15.5.0 ships with a sudo configuration file that looks like this:

We’re going to change the following line:

To now read as follows:

What this change does is remove the ability for all users of the admin group to use all available privileges for the sudo tool. In its place, now only a user account with the account shortname of otheruser has all available privileges for the sudo tool.

To deploy this change with Blueprints, three things are needed.

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

The sudo configuration file is stored in the /etc directory and the file is named sudoers, so a zip file containing a directory named etc, with a file inside the etc directory named sudoers, is needed for this.

For this example, we’ll name the zip file as sudoers_configuration.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 a0bac25baf21f3e507120940d65d6ff856472baf6d1b778aafe7c076023cd9d0, you should see output like this when you run the command above:

3. A place to download the zip file from which allows downloading without authentication.

For this example, I’ve set up an S3 bucket in Amazon Web Services named 75d831079efb4d02ada44eed4f8ae093 and set the sudoers_configuration.zip file to be publicly accessible from that S3 bucket.

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 using the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Open button for Service configuration.

4. Give it a name when prompted. For this example, I’m using Sudo Configuration.

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

6. Provide the necessary information to download the sudoers_configuration.zip file. For this example, the following information is being used:

• Data URL: https://75d831079efb4d02ada44eed4f8ae093.s3.us-east-1.amazonaws.com/sudoers_configuration.zip
• SHA-256 Hash: a0bac25baf21f3e507120940d65d6ff856472baf6d1b778aafe7c076023cd9d0
• Service definition: sudo

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

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Sudo Configuration Blueprint as being deployed.

On your managed devices, you can verify that the new sudo configuration has been deployed by clicking on the MDM enrollment profile, then scrolling to the bottom of the screen. You should see a Device Declarations section, with a listing for Configuration Files: com.apple.sudo.

If you click on the Configuration Files: com.apple.sudo listing, it should provide the path to the tamper-resistant directory where it stored the new sudo configuration file. This should be the following location:

/private/var/db/ManagedConfigurationFiles/com.apple.sudo

Inside that directory will be the etc directory containing the sudoers file you configured for the Blueprint’s zip file. The complete file path to the new sudo configuration should be the following:

/private/var/db/ManagedConfigurationFiles/com.apple.sudo/etc/sudoers

You will not be able to write to this location, as it is protected by System Integrity Protection (SIP), but you should be able to read from the file and verify the contents are what’s expected.

You should also be able to verify that only the otheruser user account can use the sudo command line tool.

For those who wanted a copy of my talk on managing admin rights in the enterprise at the MacAD.UK 2025 conference, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/macaduk2025pdf
• Keynote: https://tinyurl.com/macaduk2025key

As part of Jamf Pro 10.48.0, Jamf changed the behavior of the Send Blank Push MDM command to send a DeclarativeManagementRequest MDM command (aka DeclarativeManagement) in place of the previous blank push MDM command, which was a blank push notification via APNS to the device to prompt the device to check in the Apple Push Notification Service (APNS). Changing the behavior to now send a DeclarativeManagement MDM command allows a DDM status report to be sent to the MDM server along with the APNS check-in.

However, I’ve observed that sending a blank push command does not always cause a DeclarativeManagement command to be queued up for Jamf Pro-managed devices if a previous DeclarativeManagement command was recently sent. If you want to make sure a DeclarativeManagement MDM command is being sent to your Jamf Pro-managed device, the declarative-device-management endpoint for the Jamf Pro API can be used to force a DDM status report to be sent to your Jamf Pro server. For more details, please see below the jump.

Update: June 6, 2025 – For those who want to use least privileged permissions for running this API command, here’s the permissions needed:

API client permissions:

• View MDM command information in Jamf Pro API
• Send Declarative Management Command

User account permissions:

Jamf Pro Server Actions:

• View MDM command information in Jamf Pro API
• Send Declarative Management Command

The declarative-device-management endpoint uses what’s referred to as the client management ID to identify the managed device in question. The client management ID is included as part of the computer inventory record. If you have the Jamf Pro ID of the Mac in question, you can get the client management ID using the following API command:

That should produce output which looks similar to this, where the output is the client management ID:

Once you have the client management ID, you should be able to use it to force a DDM sync and cause a DeclarativeManagement MDM command to be sent to your managed device:

Once sent, the DeclarativeManagement MDM command should appear in the device’s inventory record as part of the management history.

Once the device has sent in an updated DDM status report, you can also use the Jamf Pro API to query the status report’s information. For more information about doing that, please see the link shown below for a previous post on this topic:

https://derflounder.wordpress.com/2025/03/27/using-the-jamf-pro-api-to-query-ddm-status-information-for-macos/

As part of the release of macOS Sequoia 15.5.0, Apple has announced the following:

• The Apple Filing Protocol (AFP) client has been deprecated as of macOS 15.5.0
• The Apple Filing Protocol (AFP) client will be removed in a future version of macOS

This announcement is providing a end-of-the-road notification for AFP, which has been included in Apple’s operating systems for the Mac since System 6 in 1988. The ability to run an AFP server was removed from macOS as part of macOS Big Sur and it is not possible to host AFP shares from APFS formatted drives, so the AFP client has been the final functional part of AFP left as of macOS Sequoia.

This deprecation will affect the AFP functionality available via the Finder and via the mount_afp command line tool, with the mount_afp man page also noting that the AFP client is being deprecated.

A while back, I wrote about how you could use the Jamf Pro API to download installer packages from a JCDS2 distribution point. 

However, installer packages are not the only items which may be stored on a JCDS2 distribution point. The IPA files used by in-house iOS, iPadOS and tvOS devices may also be stored for distribution on a JCDS2 distribution point. IPA files stored on a JCDS2 distribution point can be accessed for download in the same way that installer packages can.

For those who want to use this capability, I’ve written a script which uses the Jamf Pro Classic API and Jamf Pro API to get the list of IPA files on a Jamf Pro server, retrieve the associated download links and download the IPA files to a directory on my Mac. For more details, please see below the jump.

Pre-requisites:

If setting up a specific Jamf Pro user account for this purpose with limited rights, here are the required API privileges for the account on the Jamf Pro server:

Jamf Pro Server Objects:

• Mobile Device Apps: Read
• Jamf Content Distribution Server Files: Read

For authentication, the script can accept manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file. The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

To store the account username in the plist file:

To store the account password in the plist file:

Usage: 

/path/to/Jamf_Pro_JCDS_Mobile_InHouseIPA_Download.sh

The script takes the following actions:

1. Creates a download directory if none has been specified in the script.
2. Uses the Jamf Pro Classic API to download the list of mobile device applications from the Jamf Pro server.
3. Gets the Jamf Pro ID numbers for the individual IPA files.
4. Uses the Jamf Pro Classic API to get the names of the individual IPA files.
5. Uses the Jamf Pro API to get the MD5 hash of the individual IPA files.
6. Checks to see if a file with a matching name and MD5 hash exists in the download directory.
7. If a file with a matching name and MD5 hash exists in the download directory, display a message that the file exists in the download directory.
8. If a file with a matching name and MD5 hash does not exist in the download directory, use the Jamf Pro API to query the JCDS2 distribution point for the download URL of the IPA file and download the IPA file.

The script should provide output similar to this:

Downloading new copies of the IPA files where no copies currently exist:

Verifying existing copies of the IPA files exist and have MD5 hashes that match the IPA files stored in Jamf Pro:

Verifying existing copies of the IPA files exist and detecting copies that do not have MD5 hashes that match the IPA files stored in Jamf Pro:

This script is available from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Mobile_InHouseIPA_Download/user_account_authentication

A version which uses API client authentication is available from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Mobile_InHouseIPA_Download/API_client_authentication

Both scripts can be accessed via the following link:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Mobile_InHouseIPA_Download

On macOS, the logging used by the OS leverages the unified logging system. First introduced as part of macOS 10.12 Sierra, this logging system replaced various individual system log files stored in the /var/log directory and replaced them with a central system log that various subsystems send their logging to. This central system log can then be read using a couple of tools included with macOS:

• Console.app
• The log command line tool

But what subsystems in macOS are currently configured to send logging to the unified system log and how are those subsystem configured? For more details, please see below the jump.

For the subsystems included with macOS, their logging configurations are stored in the following directory:

/System/Library/Preferences/Logging/Subsystems

As of macOS 15.4.1, here’s the names of the subsystems, their identifiers, and where their configuration files are located:

To generate a similar list yourselves, you can use the script shown below to generate a CSV file similar to the one shown above:

Being able to reference these configurations and what logging levels they are set to can be valuable as some subsystems are set to log in DEBUG mode by default and some are not. A good example is the configuration for Time Machine‘s logging as of macOS 15.4.1:

• Name: TimeMachine
• Identifier: com.apple.TimeMachine
• Location: /System/Library/Preferences/Logging/Subsystems/com.apple.TimeMachine.plist

In contrast, defaults‘s logging configuration is set to log in INFO mode by default as of macOS 15.4.1:

• Name: defaults
• Identifier: com.apple.defaults
• Location: /System/Library/Preferences/Logging/Subsystems/com.apple.defaults.plist

When it comes to figuring out what is happening on an Apple device, creating a sysdiagnose file is usually the way to go. Sysdiagnose files are the final outcome of your Apple device running almost every performance and problem tracing tool available, then taking the resulting logs and bundling them all together into one compressed file. However, because these logs are intended for use and analysis by Apple’s engineers, they can almost overwhelm with information.

One way to manage this flood of data is to use the system_logs.logarchive file included with every sysdiagnose file. The system_logs.logarchive file is a snapshot of the unified system log as of the time that the sysdiagnose was created, so it has a large amount of information about what was happening on that Apple device at the time.

Accessing the information in the system_logs.logarchive file can be accomplished using the following process:

1. Get the desired sysdiagnose file
2. Uncompress it.
3. In the resulting directory, locate the system_logs.logarchive file.

You can work with the system_logs.logarchive file using a couple of tools included with macOS:

• Console.app
• The log command line tool

For more information, please see below the jump.

Using Console.app

To access the system_logs.logarchive file using Console.app, double-click on the system_logs.logarchive file. It should then open the Console app if needed and display a window showing the logs from the system_logs.logarchive file.

From there, you can use the Console app’s search functionality to find what you’re looking for.

Using the log command line tool

If viewing logs using the log command line tool, you can use the log tool’s show function to specify that you want to reference from the system_logs.logarchive file. For example, you can use a command like the one shown below to access the information in the system_logs.logarchive file:

This will likely result in a huge amount of data flying quickly through your Terminal window. It will likely make sense to provide additional filters to get back just the data you want.

For example, if you want to get only information on mobile device management traffic which was captured by the system log, you can use a command like the one shown below to add predicates which can be used by the log command line tool:

That should display only the information defined by the predicates, which are:

• Information logged from the mdmclient process
• Information logged from the com.apple.ManagedClient subsystem
• Information logged within the HTTPUtil logging category

This should produce a much smaller and more focused stream of information.

Depending on how recently the sysdiagnose was created, you may be able to narrow down the returned data even further by specifying a timeframe. For example, if you wanted to check for only information logged from midnight of April 28th, 2025 to midnight of April 29th, 2025, you could use a command like the one shown below:

If you wanted to check for a relative timeframe like the past two days from the time you’re running the command, you could use a command like the one shown below: