babgond

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:

In Safari 18.3 and earlier on macOS, it’s been possible to access details about SSL certificates used by the websites being visited using the following process:

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.

On macOS, Apple uses the Tips app to provide information that Apple considers useful to folks using Macs. I had previously written a post about how you could launch the Tips app using a URL to provide this information on demand. At that time, I was aware of one place that the Tips app was installed. This location is /System/Library/CoreServices/Tips.app:

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.

On many Unix-based operating systems, rsync is a command line tool for transferring and synchronizing files on a computer, either between storage attached directly to the computer or between another computer located elsewhere on a network. The rsync command line tool has long been included on macOS, but Apple has provided the last version of rsync 2.x (rsync 2.6.9, released in November 2006) and did not update rsync past that even though rsync 3.x was released. Why not? It has to do with the version of the GNU General Public License (GPL) open source license that rsync 2.x and 3.x were released under, with rsync 2.x being released under the GPLv2 license and rsync 3.x being released under the GPLv3 license. Without going in-depth into the background legal issues, the reason for not providing rsync 3.x is that Apple decided that while it could comply with the terms of GPLv2 license with regards to rsync 2.x, it could not comply with the terms of GPLv3 license with regards to rsync 3.x.

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:

When enrolling a device into an MDM server using device enrollment, a couple of things happen as part of the MDM enrollment process:

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:

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac and sometimes also after an OS update. Apple added a new Software Update screen as part of macOS Sequoia 15.4.0.

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 a follow-up to my earlier posts on managing Apple Intelligence features on macOS Sequoia 15.1, 15.2 and 15.3, Apple has added new management options for Apple Intelligence as part of the release of macOS Sequoia 15.4. For more details, please see below the jump.

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:

With Jamf Pro’s ability to leverage declarative device management (DDM) for reporting device state changes on managed devices, Mac admins who use Jamf Pro may find it useful to be able to retrieve the latest reported state change for a Mac using the Jamf Pro API. This can be done using the declarative-device-management endpoint for the Jamf Pro API.

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: