babgond

One of the management options Jamf Pro 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.

Previously, the only option for deploying software update declarations via Blueprints was to specify an individual OS version. Now there is a new option for upgrading the OS version to the latest version a particular Mac can support.

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

• Download and schedule to install
• Latest version based on device eligibility

The Latest version based on device eligibility functionality in the managed software update functionality tells the managed Mac to download and install the latest version of macOS that a particular Mac can support. The Blueprints software update declaration functionality provides that same experience, where you can do the following:

• Set that you want the managed Macs to update their OS version to the latest version of macOS a particular Mac can support.
• Set a deadline that you want to have your Macs updated by.

For more details, please see below the jump.

For this example, I have the goal of updating managed Macs to the latest available version of macOS. As of November 6 2025, that is the following version of macOS:

• macOS 26.1

I want to have them all updated within one day of the release of new OS versions, with the install time set as being 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 latest macOS version.

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:

• Enforcement type:
  • Latest OS version
• Days after release to enforce update:
  • 1
• Install at (local device time):
  • 18:00

7. Once all the information has been entered and verified to be correct, click the Save button.

8. Click the Deploy button to deploy the changes to the Macs you want to manage.

Note: The days after release refers to the date that the latest version was released. In the case of macOS 26.1, that was on the following date:

• November 3, 2025

By setting the Days after release to enforce update setting to 1 day, that means that Macs receiving this software update declarations will have this deadline to install macOS 26.1:

• November 4, 2025 at 18:00 (6:00 PM in the Mac’s local time zone)

Devices receiving the Blueprint will detect that they are past the deadline set by the software update declaration if the Blueprint is being deployed on the following date:

• November 6, 2025

In this case, the Mac will try to update as soon as possible and provide notifications that it is past the deadline for updating.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Update to latest macOS version Blueprint as being deployed.

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

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 Required Software Update. The Required Software Update listing will include the OS version number for the required update.

If you click on that listing, you should see the details of the software update declaration. In this case, since the latest available version of macOS is 26.1, that’s what is listed as part 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 12 minutes 33 seconds.

After updating to macOS Tahoe 26.1.0 yesterday, I then did what I normally do and began building new virtual machines to test with. I built a VM for macOS 26.1.0 and then noticed something odd. The virtual machine did not have an assigned system serial number. Instead, where you would expect to see the serial number displayed, there is a blank entry.

I built a macOS 26.0.1 VM and saw the serial number appear.

I then upgraded the VM from macOS 26.0.1 to macOS 26.1.0. Poof, no more serial number.

After talking with colleagues in the Mac Admins Slack, I was pointed to a Known Issues entry for Virtualization in the macOS 26.1.0 release notes:

The serial number published for the virtual machine is 0, which prevents iCloud and related applications from functioning correctly. (163294564)

You can’t set a system serial number manually for macOS VMs running on Apple Silicon Macs, so it looks like this state of affairs is with us until Apple fixes it. Hopefully that is soon.

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.