babgond

A while back, I had written a post on how to identify MDM-managed user accounts using the mdmclient command line tool. While this method continues to work on macOS Tahoe, it does have a drawback – the mdmclient tool will only report this information if the MDM-managed user account is currently logged in.

There is an alternative way to get this information though, as it is also available via the System Information app included with macOS. This information should be available regardless of whether the MDM-managed user account is logged in or not. For more details, please see below the jump.

In the System Information app, you can access information about the MDM-managed user account by selecting the Profiles section, then clicking on the MDM Profile listing. If this Mac has an MDM-managed user account, it should be listed as Managed User in the Other Info section at the end of the MDM Profile listing’s information.

In place of listing the account’s username, the Managed User information provides two items of information:

• The account’s assigned UUID identifier (also referred to as a GeneratedUID.)
• The account’s assigned user identifier (also referred to as a UID.)

This information can also be obtained using the system_profiler command line tool, where you should only need the account’s assigned UUID identifier in order to identify the account.

To get the UUID identifier information using the system_profiler tool, the following command can be run:

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 should provide output similar that shown below:

One of the changes between Jamf’s Self Service app (also referred to as Self Service classic) and the Self Service+ app is where each app stores its logs. Self Service classic stores its logs in the following location in the individual user account’s home folder:

• ~/Library/Logs/JAMF/selfservice_debug.log

The Self Service+ app is sending its logging to the unified system log.  With the right predicates, you can retrieve Self Service+‘s logging when needed by using the log command line tool. For more details, please see below the jump.

The Self Service+ app uses a number of processes and logging subsystems, but you should be able to retrieve them using the following search predicates:

• Process contains: Self Service
• Subsystem starts with: com.jamf.selfserviceplus

For example, the following log command should get all Self Service+ related logging for the last ten minutes:

With log predicates, the ” : ” character can also be used in place of contains and the ”  :^  ” characters can be used in place of BEGINSWITH, so the following command should also work to get all Self Service+ related logging for the last ten minutes:

The resulting logging should look similar to what’s shown below:

If you want to search for logging that contains both logging predicates in common, the following log command should get all Self Service+ related logging which contains both for the last ten minutes:

The resulting logging should look similar to what’s shown below:

One of the changes Apple has introduced with macOS Tahoe is the ability to use SSH at the unified login screen available on Apple Silicon Macs. Apple has built on this to provide a way to allow a FileVault-encrypted Mac to be unlocked via an SSH session. Apple mentions this new capability as part of the following KBase article:

• What’s new for enterprise in macOS Tahoe 26: https://support.apple.com/124963

As part the KBase article, the following man page is referenced:

apple_ssh_and_filevault

This can be accessed using the following command:

For more details, please see below the jump.

To unlock FileVault on macOS Tahoe using SSH, you can use the procedure described below:

Pre-requisites:

• Second computer available which can run SSH.
• Target Mac must be using an Apple Silicon processor.
• Target Mac must be running macOS Tahoe or later.
• Target Mac must have FileVault encryption enabled.
• Target Mac must have SSH enabled.

1. Connect from the second computer to the target Mac using the username and network address of the target Mac.

For this example, the target Mac has the following account and network address:

• Account: username
• Network address: computername.local

In this example, the following command is being used to connect from the second computer to the target Mac using SSH:

2. When you connect, you should be informed that the target Mac is locked and that you’ll need to a local username and password to unlock it.

In this example, we’re connecting with the username of an account which is enabled on the Mac to unlock FileVault. Because of this, we should only need to provide the password for that account.

3. Once the password has been provided, the Mac unlocks FileVault and automatically closes the SSH connection between the second computer and the target Mac.

On the target Mac, you should see activity similar to this occurring on the login screen.

4. After a short amount of time, the target Mac should be unlocked. At this point, you should be able to connect again from the second computer to the target Mac using SSH and have access to all expected functionality.

For those who wanted a copy of my talk on MDM and DDM at Jamf Nation User Conference 2025, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/JNUC2025PDF
• Keynote: https://tinyurl.com/JNUC2025Keynote

Apple has provided settings for suppressing various screens which appear the first time you log into a Mac and sometimes also after an OS update. In recent OS releases, Apple has been using the following preference domain and key for this:

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

Apple has the SkipSetupItems key set to store its settings in an array, as described below:

Why this is important is that the array and its list of strings is what’s being interpreted as the setting for the SkipSetupItems key in a management profile. This detail is important in itself because it can lead to multiple management profiles managing what macOS sees as the same setting.

In a case where you have two or more management profiles managing the same setting differently, you get what Apple calls indeterminate or undefined behavior. In a situation like this, macOS may randomly choose to apply one of the settings and ignore any others, or just ignore all of the settings. For more details, please see below the jump.

As an example, you may deploy a management profile to stop the Your Mac is Ready for FileVault screen from appearing.

In that case, there’s now a profile which is deploying the following setting in the SkipSetupItems array:

Later, you may choose to deploy a management profile to stop the Software Update Complete screen from appearing.

In that case, there’s now a management profile which is deploying the following setting in the SkipSetupItems array:

Once the second management profile to suppress the Software Update Complete screen has been deployed, you may now see the following behavior occurring randomly on the Macs it was deployed to:

• The Software Update Complete screen appearing.
• The Your Mac is Ready for FileVault screen appearing.
• Both the Software Update Complete and Your Mac is Ready for FileVault screens appearing.

The fix for this situation is to not deploy separate management profiles containing settings for the SkipSetupItems key. Instead, combine the settings into one management profile with multiple entries in the array. For example, to suppress both the Software Update Complete and Your Mac is Ready for FileVault screens, you would deploy a single management profile with the following settings in the SkipSetupItems array:

For macOS Tahoe 26.0, the following management profile should stop the following screens from appearing:

• Analytics
• Apple Intelligence
• Software Update Complete
• Update Your Mac Automatically
• Your Mac is Ready for FileVault
• Welcome

Over the years, Apple has introduced a number of screens which appear the first time you log into a Mac. Among those which appear following an upgrade to macOS Tahoe 26.0 is the Software Update Complete screen, which notifies you that the Mac has been upgraded to macOS Tahoe.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Software Update Complete screen on macOS Tahoe 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: UpdateCompleted

The profile is available on GitHub via the link below:

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

One of the management options Jamf Pro provides with Blueprints for macOS Tahoe is using DDM declarations to manage settings which can used by Apple’s Safari web browser. Let’s see how this works using by distributing the following Safari settings:

• Allow History Clearing: Set to false, to disable clearing history in Safari.
• Allow Private Browsing: Set to false, to disable private browsing in Safari.

For more details, please see below the jump.

Safari settings can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari bookmark management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari settings managed.

As of Jamf Pro 11.20.1, there is not a Blueprints template available for creating blueprints which manage Safari 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 Safari 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 Safari settings component.

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

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

8. To add the settings for the Safari settings in this example, set the following settings as follows:

• History clearing: Set to Disallowed
• Private browsing: Set to Disallowed

9. Once all the settings choices have been made and verified, click the Add button.

10. 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 arrow button.

11. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Safari Settings Deployment Group.

14. Once everything has been configured, 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 Safari Settings blueprint as being deployed.

On your managed devices, you can verify that the new Safari settings management 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 User Declarations section with a listing for Safari Settings.

If you click on the Safari Settings listing, it should report the following:

• Allow History Clearing: No
• Allow Private Browsing: No

You should also be able to open Safari and verify that the desired settings are being applied by trying to clear Safari’s history and opening a private window.

One of the management options Jamf Pro provides with Blueprints for macOS Tahoe is using DDM declarations to manage the bookmarks which can used by Apple’s Safari web browser. Let’s see how this works using by distributing the following links as Safari bookmarks:

• Company Name Intranet: https://intranet.company.com
• Company Name Developer Site: https://developer.company.com
• Company Name Travel: https://travel.company.com

For more details, please see below the jump.

Safari bookmarks can be managed using DDM declarations at the user level, which like with user-level MDM profiles, means that they can be applied only to MDM-managed users. When dealing with local accounts, this means that only the local user account which installs the MDM enrollment profile becomes the MDM-managed user. For our purposes here, this means that Safari bookmark management declarations can only be applied to the MDM-managed user and any other local accounts on the Mac cannot have their Safari bookmarks managed.

As of Jamf Pro 11.20.1, there is not a Blueprints template available for creating blueprints which manage Safari bookmarks 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 Safari Bookmarks.

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

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

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

8. At this point, you will see an Managed Bookmarks section without any listed bookmarks. Click the Add bookmark group button.

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

• Title: Company Name
• Group identifier: 875D8D76-20EE-43DB-B874-9FC9F1CCC3A9

Note: The Group identifier field can be any unique string and the only thing that matters is that it is unique. Acceptable unique strings include the following:

• 875D8D76-20EE-43DB-B874-9FC9F1CCC3A9
• Finance Department Bookmarks
• Man I Love Donuts Especially Those With Chocolate Frosting

If the string is not unique, the bookmarks which have a not-unique group identifier will be composited together into one set of bookmarks.

Bookmarks:

• Company Name Intranet: https://intranet.company.com
• Company Name Developer Site: https://developer.company.com
• Company Name Travel: https://travel.company.com

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

11. If everything looks right, click the Save button.

12. 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 arrow button.

13. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Safari Bookmarks Deployment Group.

14. Once everything has been configured, 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 Safari Bookmarks blueprint as being deployed.

On your managed devices, you can verify that the new Safari bookmark 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 User Declarations section with a listing for Safari Bookmarks.

If you click on the Safari Bookmarks listing, it should report the following:

Present

You should also be able to open Safari and verify that the desired bookmarks are appearing in Safari’s Bookmarks menu.

Every so often, something gets added to macOS and enabled by default where I wish it was off by default. In macOS Tahoe, that’s the appearance of desktop widgets automatically on login.

This behavior is managed in System Settings: Desktop & Dock and is listed as the Show Widgets setting. This has two selectable settings:

• On Desktop
• In Stage Manager

The default behavior is for both the On Desktop and In Stage Manager options to be enabled.

To prevent desktop widgets from appearing on your desktop, disable the On Desktop option.

Fortunately for my preferences, the desktop widgets behavior can also be controlled via the following setting:

• Domain: com.apple.WindowManager
• Key: StandardHideWidgets
• Value: Boolean

To disable desktop widgets and prevent them from appearing, run the following command as the logged-in user:

To enable desktop widgets to appear again, run the following command as the logged-in user:

In my case, I wanted to disable desktop widgets and prevent them from appearing so I’ve also written a profile which can enforce this. It’s available via the link below:

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

As part of the release of macOS Tahoe 26.0, Apple has removed built-in support for FireWire devices from macOS. This removal of support can be verified by looking in System Profiler.

For more details, please see below the jump.

On macOS Sequoia 15.7.0, System Profiler shows an entry for FireWire.

On macOS Tahoe 26.0, System Profiler no longer shows an entry for FireWire.

Running the following command on both macOS Sequoia and macOS Tahoe also shows that SPFireWireDataType has been removed from macOS, which means that System Profiler is not longer gathering data from that area: