babgond

When searching the the unified system log on macOS using predicates, it’s often useful to use logging subsystems when searching for information. For example, as part of a previous post on finding DDM status information in the logs, I used the following command to find data logged within the last ten minutes:

This search uses the com.apple.remotemanagementd subsystem as a predicate when searching the logs. However, you can get even more granular by searching for a specific category of information within the com.apple.remotemanagementd subsystem. For example, let’s look at the data returned from running the command above:

Within the data returned by searching for the com.apple.remotemanagementd subsystem, there’s several categories included as part of the subsystem log entries:

• XPCListenerDelegate
• client
• mdmConduit

Those categories show up following the listing for the com.apple.remotemanagementd subsystem in the returned log entries like this:

If we wanted to get more granular and search the unified system log for only the logs associated with a particular category for a logging subsystem from the last ten minutes, the following command could be used to search using the following predicates:

• Subsystem: com.apple.remotemanagementd
• Category: mdmConduit

That would return only those log entries which matched both the com.apple.remotemanagementd subsystem and the mdmConduit category:

Figuring out what declarative device management (DDM) is sending to or requesting from a Mac can be a challenge. Fortunately, this is possible to figure out via the unified system logging using the right predicates when searching. For more details, please see below the jump:

To start, have your MDM server send an DDM declaration command to the device in question. If your MDM server says it sent successfully, see what shows up on the Mac’s end using the following command to get information logged within the last ten minutes:

In this case, the following process and logging subsystem are being checked for their corresponding log entries:

• Process: remotemanagementd
• Subsytem: com.apple.remotemanagementd

This will likely give you a large number of log entries, but it’s possible to filter for what you’re looking for. For example, a blank push remote command sent from a Jamf Pro MDM server will trigger a Mac to send in a DDM status report to its MDM server. This process of prompting the Mac to send in a DDM status report should include logging a line similar to this:

Since we can see that the relevant process is remotemanagementd and the string to search for includes Syncing only if needed, then if you sent a blank push within the last ten minutes you can use the following command to see if the entry appears in the returned logs:

That should pull up the relevant log entry:

To look up information specifically about DDM status item logging, using only the com.apple.remotemanagementd subsystem as a predicate when searching the logs looks like it returns this information without including additional information involving only the remotemanagementd process. For example, using the command below should get any DDM status item logging from the last ten minutes:

If no status items needed to be updated with the MDM server, you may see logging like this:

If there were status items to send to the MDM server, you may see logging like this:

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac. Among those which appear as of macOS Sequoia 15.6.0 is the Analytics screen, which asks if you want to opt-in to sending app crash and usage data to developers.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Analytics screen on macOS Sequoia using a configuration profile. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.SetupAssistant.managed
• Key: SkipSetupItems
• Value: Diagnostics

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/blob/main/SkipAppAnalyticsSetup

The good folks at Penn State have posted the session videos from Penn State MacAdmins Conference 2025. The sessions slides are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

All session videos are available via the link below:

https://youtube.com/playlist?list=PLRUboZUQxbyWkCvacoCRerV2qY1ZpL-x0&si=njjyPiZzD8me5Xit

I’ve linked my MDM and DDM 101 session here:

I’ve linked my Leveling Up – Managing admin rights in the enterprise session here:

One of the management options Jamf Pro now provides with Blueprints is sending DDM declarations to managed Macs run macOS software updates automatically. This is comparable to Jamf Pro’s managed software update functionality, which also provides the ability to send a DDM declaration to run software updates.

For those familiar with Jamf Pro’s managed software update functionality, the Blueprints software update declaration provides the following update options:

• Download and schedule to install
• Specific version

The Specific version functionality in the managed software update functionality tells the managed Mac to download and install the update for a specific macOS version, like macOS 15.6.0.

The Blueprints software update declaration option provides that same experience, where you can do the following:

• Set a date that you want to have your Macs updated by.
• Set the OS version you want to update to.

For more details, please see below the jump.

For this example, I have the goal of updating managed Macs to the following version of macOS:

• macOS 15.6.0

I want to have them all updated by Friday, August 1 2025 at 6:00 PM (18:00)

I can set up a Blueprint in Jamf Pro to deploy a software update declaration to enforce this using the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click on Update software to latest version.

4. Give it a name when prompted. For this example, I’m using Update to macOS 15.6.

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

6. In the Software Updates section, I’m choosing the following settings:

• Date and time of the update:
• 08/01/2025, 18:00
• Target OS version:
• 15.6

Note: The options available via Blueprints for software declarations are the ones Apple has specified for software update declarations. For more information about this topic, please see the following link:

https://support.apple.com/guide/deployment/software-update-declarative-configuration-depca14ecd4d/web

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 Update to macOS 15.6 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 Software Update.

If you click on that listing, you should see the details of the software update declaration.

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 14 minutes 42 seconds.

A common issue faced by Mac admins is that users can have multiple copies of an application on their system. This can be the result of users having standard user rights and running applications out of the home directories, or users reorganizing the Applications directory in a way that makes more sense to them for their needs. Meanwhile, when Mac admins need to report on whether the apps on the fleet are up to date, these additional or reorganized apps may not be patched but do show up in the software reporting as being out of date.

When you run into these situations, how to handle them? The first step is finding where the duplicates are and reporting on them. To do this, you can use the mdfind command line tool, using the kMDItemCFBundleIdentifier metadata attribute. This metadata attribute reports on the bundle identifier used by an application, so it should pick up all copies of an app which are using that unique identifier for that app. For more details, please see below the jump.

As an example case, I’m going to use the following scenario:

1. I need to locate all copies of the BBEdit app installed on a particular Mac
2. The user in question has three copies of BBEdit installed.

• In /Applications
• In a user-created BBEdit directory inside of /Applications.
• In a user-created Applications directory inside of their home folder.

BBEdit’s bundle identifier is com.barebones.bbedit, so I can use the following mdfind command to find all copies of BBEdit.app:

In the scenario described above, that should provide output similar to what’s shown below:

However, you may not necessarily want to know about /Applications/BBEdit.app as that may be the only version you want installed. To exclude /Applications/BBEdit.app from your results, you can use the grep command line tool’s -v inverse match and -E regular expression options to exclude /Applications/BBEdit.app from the list of results:

If you needed to exclude additional directories (for example, you must exclude searching the user’s home folder for privacy reasons), you can add additional regular expressions to the grep command to exclude additional undesired results. Here’s an example where you’re excluding results from /Users and for /Applications/BBEdit.app:

For our scenario, here’s a script that should identify all installed copies of BBEdit on a Mac and display a list of all copies except for /Applications/BBEdit.app:

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

• PDF: https://tinyurl.com/PSUMacAdmin2025pdf
• Keynote: https://tinyurl.com/PSUMacAdmin2025key

For those who wanted a copy of my talk on MDM and DDM at Penn State MacAdmins 2025, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/PSUMac2025PDF
• Keynote: https://tinyurl.com/PSUMac2025Keynote

Payload-Free Package Creator.app, an Automator application that allows the selection of an existing script and then creates a payload-free package that runs the selected script, has been updated to version 2.5.

The user experience and operations of the app have not changed from previous versions of Payload-Free Package Creator.app. The changes to Payload-Free Package Creator 2.5 are the following:

• Payload-Free Package Creator.app creates distribution installer packages using productbuild in place of the previous method, which used pkgbuild to create component installer packages.
• Payload-Free Package Creator.app is signed with current Developer ID: Application certificate.
• Payload-Free Package Creator.app is notarized.
• Installer package is now signed with current Developer ID: Installer certificate.
• Installer package is notarized.

Payload-Free Package Creator 2.5, along with all components and scripts, is available on GitHub via the link below:

https://github.com/rtrouton/Payload-Free-Package-Creator

You can download the Payload-Free Package Creator 2.5 installer via the GitHub release page for Payload-Free Package Creator 2.5:

https://github.com/rtrouton/Payload-Free-Package-Creator/releases/tag/2.5

As part of the release notes for Jamf Pro 11.18.0, it was mentioned that the Self Service+ app could now be deployed by default in place of the Self Service app (also referred to as Self Service classic.)

Choosing to deploy the Self Service+ app by default in place of the Self Service classic app will result in the following changes taking place on all macOS 13 Ventura and later Macs which are managed by that Jamf Pro server:

• Existing installations of the Self Service classic app are removed from managed Macs running macOS 13 or later.
• The Self Service+ app is installed on managed Macs running macOS 13 or later as part of a managed Mac’s next check-in with Jamf Pro
• The Self Service+ app is installed on managed Macs running macOS 13 or later following enrollment.
• The Self Service+ app is automatically updated to the latest version of Self Service+ as new Self Service+ updates are released.

Managed Macs running macOS 12 Monterey or earlier will not have these changes occur. These Macs will continue to use the Self Service classic app.

For more details, please see below the jump.

To enable the Self Service+ app for default deployment to managed Macs running macOS 13 Ventura and later, please use the following procedure:

1. Log into Jamf Pro with an administrator account.

2. Go to Settings: Jamf Apps

3. Select Self Service+

4. In the Self Service+ settings, select the checkbox for Use Self Service+ as the default end user application.

5. Verify the setting is set as desired. Once verified, click the Save button.

Note: Once this option is enabled, all managed Macs running macOS 13 or later will use only the Self Service+ app. It will not be possible to run both the Self Service+ app and the Self Service classic app on the same computer.

Once enabled, you should expect to see the following:

• The Self Service+ app be deployed to all macOS 13 Ventura and later Macs which are managed by that Jamf Pro server.
• The Self Service classic app be removed from all macOS 13 Ventura and later Macs which are managed by that Jamf Pro server.

For those who want to test the Self Service+ app while continuing to use the Self Service classic app, please see the documentation linked below:

Deploying Self Service+ to End User Devices Using a Policy:

https://learn.jamf.com/en-US/bundle/self-service-plus-documentation/page/Self_Service_Installation.html