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

• 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

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:

1. Launch Safari if needed.

2. Click the address bar

3. Click the padlock icon on the left side of the address.

4. Click the View Certificate button.

You should see a window with the SSL certificate details.

In Safari 18.4 and later, this process has changed. The details are described in the release notes for Safari 18.4:

Added the ability to view certificate detail from Page Menu > more > Connection Security Details on iOS, iPadOS, and in visionOS, or Safari > Connection Security Details… on macOS. (139300381)

For more details, please see below the jump.

For Safari 18.4 and later for macOS, the process now looks like this:

1. Launch Safari if needed.

2. Click the Safari menu.

3. Select Connection Security Details….

4. Click the View Certificate button.

You should see a window with the SSL certificate details.

For Safari 18.4 and later for iOS, the process now looks like this:

1. Launch Safari if needed.

2. Click the Reader icon.

3. Click on the ellipsis menu.

4. Click on Connection Security Details.

You should see a window with the SSL certificate details.

However, there’s also a second Tips app located elsewhere in macOS, in /System/Applications/Tips.app.

Why this is important is in the context of blocking Notification Center notifications from the Tips app, as a colleague was asked to do for their workplace and then shared their story of what they needed to do.

When blocking Notification Center notifications, you need the bundle identifier of the app in question. Each Tips app has a different bundle identifier:

• App location: /System/Library/CoreServices/Tips.app
• Bundle identifier: com.apple.tips

• App location: /System/Applications/Tips.app
• Bundle identifier: com.apple.helpviewer

Even more interesting is that only the Tips app located at /System/Applications/Tips.app has a CFBundleDisplayName identifier of Tips.

The CFBundleDisplayName identifier for the Tips app located at /System/Library/CoreServices/Tips.app is TipsSpotlightHandler.

Apple is using Finder localization to make the Tips app located at /System/Library/CoreServices/Tips.app appear to have the name of Tips, in place of TipsSpotlightHandler.

Going back to my earlier post about using a URL to open the Tips app, when you call the URL, what’s getting launched? In my testing, it’s the Tips app located at /System/Applications/Tips.app. So that app’s com.apple.helpviewer bundle identifier is the one you need to block the notifications, right?

Nope, the bundle identifier you need to use to block notifications is the com.apple.tips bundle identifier for the Tips app located at /System/Library/CoreServices/Tips.app, otherwise known as /System/Library/CoreServices/TipsSpotlightHandler.app:

• App location: /System/Library/CoreServices/Tips.app
• Bundle identifier: com.apple.tips

Why is it this way? Honestly, no idea. If someone does know, please let me know in the comments. But for those who need to block Notification Center notifications for the Tips app, now you have the right bundle identifier to use.

What this has meant for macOS is that it has been shipping with a version of rsync which was last updated in 2006. While Apple has been updating the rsync 2.6.9 command line tool it shipped with macOS as needed in response to security issues and other problems, the fact remains that Apple’s version of rsync up until macOS Sequoia was almost twenty years old and did not include any of the new features introduced in rsync versions which came after version 2.6.9.

Now with macOS Sequoia, Apple has replaced rsync 2.6.9 with openrsync, an implementation of rsync which is not using any version of the GPL open source license. Instead, openrsync is licensed under the BSD family of licenses, specifically the ISC license. The ISC license is a permissive license, which means it places minimal restrictions on on how the licensed software can be used, modified and distributed, which means Apple decided it is able to comply with the terms of the license for openrsync where it decided it could not comply with the terms of GPLv3 license with regards to rsync 3.x.

So I’ve spent a bunch of time talking about licenses. Why does this change matter? It matters in two ways:

1. Apple can ship updated versions of openrsync going forward without having to be concerned as to whether or not Apple can comply with the GPL open source license for rsync.
2. The openrsync command line tool is compatible with rsync, but as noted in the documentation openrsync accepts only a subset of rsync’s command line arguments.

Item number 2 is important for Mac admins because it may mean that rsync functionality that worked on older versions of macOS may not be working now on macOS Sequoia because that functionality is not available as part of the openrsync command line tool included with macOS Sequoia. For more information about what functionality is supported in the openrsync command line tool on macOS Sequoia, please see the link below:

https://manp.gs/mac/1/openrsync

As of macOS 15.4, the openrsync tool is linked to /usr/bin/rsync so you can run the the openrsync command line tool like you have been the rsync command line tool. For version information about the openrsync command line tool, run the command shown below:

You should see output similar to that shown below:

1. The device becomes a managed device.
2. The local user account which installs the MDM enrollment profile becomes a managed user.

There’s additional details on what it means to be a managed user, but one of the most important is that in this context, being a managed user means that the local user account can be managed via user-level MDM profiles. Other local accounts on the Mac cannot be managed by user level MDM profiles.

Note: Network users (for example, Active Directory mobile user accounts) who log in to the device can become managed users on login, so that a Mac can have multiple managed users. However, when only dealing with local accounts, you would just have one managed user in the context of being managed by the MDM service.

It’s not obvious from the Mac’s end to see which local user account is the MDM managed user, but it is possible to use the mdmclient command line tool to get this information. For more details, please see below the jump.

To get information on the MDM management status of the device, including information on the managed user, the following command can be run with root privileges:

Running this command should provide output similar that shown below:

From this output, this should provide information on the managed user:

In place of the account’s username, the account’s assigned UUID identifier (also referred to as a GeneratedUID) is listed. To get just that UUID, the following command can be run with root privileges:

Running this command should provide output similar that shown below:

To get the account username, run the following command with the UUID identifier in the appropriate place:

Running this command should provide output similar that shown below:

Using this information, see below for an example script showing how you can get the account’s assigned UUID identifier and then use it to identify the managed user’s username::

Running the example script with root privileges should provide output similar that shown below:

One thing to be aware of is that if you’re already managing the Software Update settings using a profile, this screen doesn’t actually change any settings.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Update Your Mac Automatically 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: SoftwareUpdate

The profile is available on GitHub via the link below:

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

As of macOS 15.4, management options are available for the following Apple Intelligence functionality:

• Genmoji
• Image Playground
• Writing Tools
• Summarizing emails
• Enabling Siri to connect to third party cloud-based intelligence services
• Managing non-anonymous login to third party cloud-based intelligence services
• Allowing third party cloud-based intelligence service workspace IDs
• Notes transcription summaries
• Managing Apple Intelligence reports
• Mail smart replies
• Summarizing Safari content

The relevant key values are below:

It’s important to note that while all of the settings listed above work on macOS Sequoia 15.4, not all work on earlier versions of macOS Sequoia. Here’s the compatibility list:

macOS 15.0 and later:

• allowGenmoji
• allowImagePlayground
• allowWritingTools

macOS 15.1 and later:

• allowMailSummary

macOS 15.2 and later:

• allowExternalIntelligenceIntegrations
• allowExternalIntelligenceIntegrationsSignIn

macOS 15.3 and later:

• allowedExternalIntelligenceWorkspaceIDs
• allowNotesTranscriptionSummary

macOS 15.4 and later:

• allowAppleIntelligenceReport
• allowMailSmartReplies
• allowSafariSummary

Most of these settings can be managed by a configuration profile, where setting a boolean value of false will disable the Apple Intelligence feature in question. The one exception at this point is the one for managing workspace IDs for allowed external intelligence integrations, which uses a string value. An example profile which allows one workspace ID is available below:

If you need to allow the use of multiple workspace IDs, an example profile which allows multiple workspace IDs is available below:

Please see below for example profiles. The example profiles are also available via the following links:

Note: If you’re planning to use the example profiles with Jamf Pro, it will need to be signed before it can be uploaded to Jamf Pro. If you’re not familiar with how to sign profiles, the post linked below is a good guide to how that process works:

https://macblog.org/sign-configuration-profiles/

• Genmoji: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableGenmoji
• Image Playground: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableImagePlayground
• Writing Tools: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableWritingTools
• Summarize emails: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableMailSummary
• Block Siri from connecting to third party cloud-based intelligence services: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableExternalIntelligenceIntegrations
• Disable non-anonymous login to third party cloud-based intelligence services: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableExternalIntelligenceLogins
• Allow external intelligence workspace IDs: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceAllowExternalIntelligenceWorkspaceID
• Notes transcription summaries: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableNotesTranscriptionSummary
• Managing Apple Intelligence reports: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableAppleIntelligenceReports
• Mail smart replies: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableMailSmartReplies
• Summarizing Safari content: https://github.com/rtrouton/profiles/tree/main/AppleIntelligenceDisableSafariSummary

Genmoji:

Image Playground:

Writing Tools:

Summarize emails: 

Block Siri from connecting to third party cloud-based intelligence services:

Disable non-anonymous login to third party cloud-based intelligence services:

Allow external intelligence workspace IDs:

Notes transcription summaries:

Managing Apple Intelligence reports:

Mail smart replies:

Summarizing Safari content:

The declarative-device-management endpoint uses what’s referred to as the client management ID to retrieve status items from the latest DDM status report sent to Jamf Pro. 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 pull all DDM status items that Jamf Pro has for the Mac in question:

For more information, please see below the jump.

That should produce output which looks similar to this, where the output is all of the status items reported by the DDM status report sent to Jamf Pro:

You can also query specific status item keys using the Jamf Pro API. For example, if the Mac in question supports reporting the device.operating-system.version key, you can use the following command to report on just that status item:

That should produce output which looks similar to this, where the output is the device.operating-system.version status item reported by the DDM status report sent to Jamf Pro:

You can then parse the output to get only the status item’s reported value:

That should produce output which looks similar to this: