babgond

Back in November 2025, Jamf released options for automatically upgrading the OS version of a Mac to the latest version of macOS that a particular Mac can support. However, this upgrade option meant that the Mac could potentially be upgraded to a new major version of macOS as part of the upgrade process.

For example, applying this software update declaration to a Mac running macOS Sequoia 15.7.1 would not upgrade it to the latest version of Sequoia, which is 15.7.3 as of February 5, 2026. Instead the Mac would be upgraded to the latest version of macOS available, which is macOS Tahoe 26.2 as of February 5, 2026.

To address this, now there is an option for updating the OS version to the latest minor version of the OS that the Mac is currently running. Using the example above, now a software update declaration can be applied to update a Mac running macOS Sequoia to the very latest version of macOS Sequoia, but not upgrade the Mac to now run macOS Tahoe.

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 minor version

The Latest minor version functionality in the managed software update functionality tells the managed Mac to download and install the latest update available to the current version of macOS that a particular Mac is running. The Blueprints software update declaration option provides that same experience, where you can do the following:

• Set that you want the managed Macs to update their OS version using the latest update for the current version of macOS that the Mac is running.
• 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 update for the current version of macOS that the individual Macs are running.

I want to have them all updated within one day of the release of new updates for the current macOS running on the individual Macs, 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 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
• Check the Ignore major versions checkbox (this setting is what restricts your Mac to updating to the latest update available for the current version of macOS that a particular Mac is running.)
• 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.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Update 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

For this example, I’m deploying this Blueprint to a Mac which is running macOS Tahoe 26.0.1. As mentioned previously, as of February 5, 2026, the latest version of macOS Tahoe is macOS 26.2.

On your managed devices that are not yet up to date with all updates for the current version of macOS being run by the Mac, you can verify that the new software update declaration 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.

Because 26.0.1 has 26.1 and 26.2 as subsequent updates, Required Software Update listings for both 26.1 and 26.2 appear. However the Mac will only install 26.2 since that is the latest update for macOS Tahoe.

The user logged into the macOS 26.0.1 Mac should also be prompted to install macOS 26.2 right away, since the declaration is enforcing installing the update at one day after the macOS update’s release date and macOS Tahoe 26.2 was released on December 12, 2025.

On your managed Macs that are fully up to date, you will not see the Software Update declaration appearing on the enrollment profile. This is because the Mac is already fully updated and there is nothing for the Mac to do in response to the deployed software update declaration.

As part of the software testing cycle, Mac admins may choose to delay making Apple’s macOS updates generally available to their fleet while they’re testing to make sure all the software used on their organization’s Macs works correctly on new versions of macOS. To assist with this, Apple has made available deferral settings for Apple’s Software Update on macOS, where you can choose to defer the following for up to 90 days:

• Major OS upgrades: An upgrade is a major macOS release with a new name (for example, macOS Sequoia 15 to macOS Tahoe 26).
• Minor OS updates: An update is a minor release within the same macOS version, such as Tahoe 26.0 to 26.2.
• Non-OS updates: These are software updates provided by Apple that are not covered by the prior two categories.

For those who need to know when deferral periods end, Apple has them available for the current shipping OS via the link below:

https://support.apple.com/guide/deployment/about-software-updates-depc4c80847a/web (see the Software release dates section.)

One example of a deferral choice is delaying the release of a new major version of macOS. In this scenario, a Mac admin may want to delay release because mandatory security software for their environment has not yet been certified by the software vendor as being compatible with the new version of macOS. You can use Blueprints in Jamf Pro to distribute these tokens, using the Software Update Settings component in Blueprints.

Let’s take a look on how to deploy deferral settings using using the following software update configuration as an example:

• What’s deferred: Major OS upgrades
• How long: 90 days

For more details, please see below the jump.

As of Jamf Pro 11.24.0, there is not a Blueprints template available for creating blueprints which manage software update 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. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Apple 90 Day Deferral.

5. Scroll down in the list on the left-hand side of the browser window to locate the Software Update Settings component.

6. Click on the Software Update Settings component and drag the Software Update Settings component to the Declaration group section.

7. Once added to the Declaration group section, click anywhere on the Software Update Settings component to open it for editing.

8. At this point, you will see all available Software Update settings which are available for all Apple platforms. To apply the desired deferral settings, select the following option:

Deferrals

Click the associated Configure button.

Check the checkbox for Number of days to defer a major macOS software update.
Enter the following value in the entry blank:

90

This will configure major OS upgrades to be deferred for the maximum amount of time, which is 90 days following the release of the major OS upgrade.

Once all choices have been made and verified, click the Update button.

9. Once all the settings choices have been made and verified, click the Save 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.

For this example, I’m selecting a static group named macOS 90 Day Deferral Group. Once the desired smart and/or static groups have been set and verified for the scope, click the Save button.

11. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

12. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Apple 90 Day Deferral Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a software update configuration via Blueprints, you should see a Software Update Settings listing for Software Update in the Device Declarations section.

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

• Major period: 90

As part of my work, I occasionally need to pull information from the unified system log, either directly on a Mac or from a sysdiagnose file, using the log command line tool. However, I also prefer to run as a standard user account most of the time and use privilege elevation tools like SAP’s Privileges or the privilege elevation functionality built into Jamf’s Self Service+ tool to get admin privileges when needed.

The combination of the two sometimes means I get halted while working because the log command line tool needs an account with admin privileges to run when it is getting log information from the unified system log on the Mac I’m using. Using the log command line tool doesn’t require root privileges or require admin authorization, but it needs to be run by a user with admin rights.

Note: This requirement for admin privileges does not appear to be coming from the log command line tool itself, but instead is coming from the unified system log. The reason I’m saying this is that accessing logs using the log tool from a sysdiagnose file does not require admin privileges. If any readers have more information about this topic, please let me know in the comments.

This has been an occasional annoyance because I get pulled briefly out of my focus while working in order to elevate my account’s privileges and then go back to my work. However, I was able to develop a solution for this issue using the sudo command line tool. For more details, please see below the jump.

This method uses the ability on macOS for the sudo command line tool to use properly formatted configurations for the sudo tool, where those configuration files are stored as plaintext files in the /private/etc/sudoers.d directory. The following process will create a sudo configuration which is stored in a plaintext file named logstandarduser which will be stored in the /private/etc/sudoers.d directory.

The configuration should be a plaintext file and formatted as followed:

A. Enter the following:

%staff

B. Hit the Tab key to create a tabbed space
C. Enter the rest of the line:

ALL = (ALL) /usr/bin/log

The complete configuration file should look like this:

What this does is create a sudo configuration which allows all members of the staff group on the Mac, which is a group that has all local users on the Mac as members, to run the log command line tool with root privileges. This removes the need for the account to have admin rights and enables accounts with only standard rights to use the log command line tool to get information from the unified system log on that Mac.

This sudo configuration can be deployed to Macs by either copying the logstandarduser file into the /private/etc/sudoers.d directory (a task which requires root privileges) or by using DDM to deploy the logstandarduser file as a configuration file for the sudo tool.

Once the sudo configuration is deployed, it should be possible for any local account on the Mac to query the unified system log via using the sudo command line tool to run the log command line tool.

As a follow-up to my previous post on using Apple Business Manager to enroll in the AppleSeed for IT program, my colleague Mark let me know that in addition to the Administrator role, it appears there are two other roles which can administer the AppleSeed for IT program for an organization.

Note: One of those roles is exclusive to Apple School Manager, so for Apple Business Manager there is only one other role in addition to the Administrator role which can administer the AppleSeed for IT program.

• People Manager role (available in Apple Business Manager and Apple School Manager):

If you look in the People Manager role in either Apple Business Manager and Apple School Manager, there is an Administer AppleSeed for IT checkbox option.

This option is disabled by default, but it is the same checkbox option which is checked for the Administrator role, which in turn allows the Administrator role to administer the AppleSeed for IT program for an organization.

• Site Manager role (available only in Apple School Manager):

If you look in the Site Manager role in Apple School Manager, there likewise is an Administer AppleSeed for IT checkbox option. This option is enabled by default, so it looks like the Site Manager role in Apple School Manager by default has the same ability as the Administrator role to administer the AppleSeed for IT program for an organization.

As discussed in a previous post, Apple provides tokens which allow devices to be enrolled in Apple’s beta programs without the need for the user to sign in with an Apple Account on the device.

You can use Blueprints in Jamf Pro to distribute these tokens, using the Software Update Settings component in Blueprints. Let’s see how this works using the following software update configuration as an example:

• Macs are enrolled in the macOS Tahoe beta program.
• Macs cannot opt out of participating in the macOS Tahoe beta program.

For more details, please see below the jump.

Pre-requisites:

• Token for the Apple macOS Tahoe beta program

As of Jamf Pro 11.23.1, there is not a Blueprints template available for creating blueprints which manage software updates 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. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Apple Beta Tokens.

5. Scroll down in the list on the left-hand side of the browser window to locate the Software Update Settings component.

6. Click on the Software Update Settings component and drag the Software Update Settings component to the Declaration group section.

7. Once added to the Declaration group section, click anywhere on the Software Update Settings component to open it for editing.

8. At this point, you will see all available Software Update settings which are available for all Apple platforms. To apply the desired beta program settings, select the following option:

Beta Updates

Click the associated Configure button.

In the Program enrollment section, select the following:

• Check the checkbox for Program enrollment
• Select the Always option

Once the Always option is selected, two additional options should appear:

• Require program
• Offer programs

Select the Require program option.

Once the Require program option has been selected, a new set of entry blanks should appear:

• Apple Business Manager or Apple School Manager beta enrollment token
• Description

For the Apple Business Manager or Apple School Manager beta enrollment token entry, enter the token for the macOS Tahoe beta program.

For the Description entry, enter whatever you want in plain text. For this example, I’m entering the following text:

macOS Tahoe beta program

Once all choices have been made and verified, click the Update button.

9. Once all the settings choices have been made and verified, click the Save 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.

For this example, I’m selecting a static group named Beta Software Deployment Group. Once the desired smart and/or static groups have been set and verified for the scope, click the Save button.

11. Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

12. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Apple Beta Tokens Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section.

If you’re deploying a software update settings configuration via Blueprints, you should see a Software Update Settings listing for Software Update in the Device Declarations section.

If you click on the Software Update Settings listing, it should report the following for the beta program settings:

• Beta program enrollment: AlwaysOn
• Require Specific Beta Program: macOS Tahoe beta program

You can also see the details of what’s configured in System Settings: General: Software Update. In this case, it’s showing the latest macOS Tahoe beta version available for installation.

You can also click on the ( i ) button next to the Beta Updates section and see the settings which have been applied, as well as a notification that the settings are managed.

As discussed in an earlier post, you can sign up for Apple’s AppleSeed for IT program using a user with the Administrator role in Apple Business Manager or Apple School Manager and subsequently obtain tokens which allow devices to be enrolled in Apple’s beta programs without the need for the user to sign in with an Apple Account on the device.

Apple has documentation available on how to obtain these tokens using an API call to the following endpoint:

https://mdmenrollment.apple.com/os-beta-enrollment/tokens

However, the documentation does not include the specifics on how to set up the API call or the necessary OAuth authentication for it. Fortunately, the folks at HCS Technology Group have published a technical article showing how to obtain the necessary tokens using the following:

• An ADE token from your organization’s Apple Business Manager or Apple School Manager instance.
• The getBetaTokens script written by the folks from Microsoft.

For more details, please see below the jump.

I’m going to be using the process described in the HCS technical article to do the following:

1. Set up a new Device Management Services server in Apple Business Manager.
2. Use the getBetaTokens script to do the following:

• Generate a public key for the new Device Management Services server.
• Use the ADE token from the new Device Management Services server as a source for the necessary OAuth credentials for the API call to the https://mdmenrollment.apple.com/os-beta-enrollment/tokens endpoint
• Authenticate to the API endpoint and fetch all available Apple beta tokens associated with an organization’s AppleSeed for IT program.
• Display all available beta tokens

Pre-requisites:

• An Apple Business Manager instance.
• Enrollment in the AppleSeed for IT program by a user with the Administrator role for that Apple Business Manager instance.
• A managed Apple Account with the Administrator or Device Manager role for that Apple Business Manager instance.
• The getBetaTokens script.

1. Log into Apple Business Manager using a managed Apple Account with the Administrator or Device Manager role. In the case of my example, I am using an account with the Administrator role.
2. At the bottom left corner of the browser, click on the menu and select Preferences.

3. Click the Add button for the Device Management Services section.

4. Name the new Device Management Services server. For this example, I’m choosing to name it as Apple Beta Tokens.

Note: You will not be able to save changes to the new Device Management Services server until a public key is uploaded.

5. Launch the getBetaTokens script. You should see output similar to this:

Note: Leave the script running, as it is watching for the ADE token which will be downloaded from Apple Business Manager later in this process.

In the directory you’re currently in for running the script, you should see a new abm_auth directory. This was created by the getBetaTokens script for storing the public key needed for the new Device Management Services server which was just created in Apple Business Manager.

Inside the abm_auth directory, there should be a file named mdm_public_cert.pem. This is the public key you need to upload to the new Device Management Services server in Apple Business Manager.

6. Get the mdm_public_cert.pem file and upload it to the Apple Beta Tokens Device Management Services server in Apple Business Manager.
7. Once the mdm_public_cert.pem file gas been uploaded to the Apple Beta Tokens server, click the Save button to save the changes.

8. Verify that the changes were saved successfully and that there is now an Apple Beta Tokens server appearing in Apple Business Manager.
9. In the Apple Beta Tokens server listing, click the Download Token button to download the ADE token associated with the Apple Beta Tokens server.

10. Confirm that you want to download the ADE token by clicking the Download Token button in the confirmation window.

11. The getBetaTokens script should detect the downloaded ADE token and then take the following actions automatically:

• Use the ADE token as a source for the necessary OAuth credentials for the API call to the https://mdmenrollment.apple.com/os-beta-enrollment/tokens endpoint.
• Authenticate to the API endpoint and fetch all available Apple beta tokens associated with an organization’s AppleSeed for IT program.
• Display all available beta tokens.

Once the script has completed running, you should see output similar to this:

The token(s) for the Apple platform(s) you want to run beta testing for should be identifiable from the script output.

Note: All OAuth credential and token information in the output shown above have been replaced with non-working randomly generated values.

Apple’s AppleSeed for IT program is designed to help enterprise and education customers test beta versions of Apple’s software.

To assist with making it easier to test these beta versions on devices, it’s possible for a user with the Administrator role in Apple Business Manager or Apple School Manager to accept the AppleSeed program’s terms and conditions on behalf of their organization. In turn, this will enable devices to be enrolled in Apple’s beta programs without the need for the user to sign in with an Apple Account on the device. For more details on how to do this, please see below the jump.

Pre-requisites:

• Apple Business Manager or Apple School Manager instance for your organization
• Managed Apple Account with the Administrator role for that Apple Business Manager or Apple School Manager instance

1. Sign into the Apple Business Manager or Apple School Manager instance via a web browser using a managed Apple Account with the Administrator role.
2. At the bottom left corner of the browser, click on the menu and select Preferences.

3. Select Beta Features.
4. Click the Begin Enrollment button.

5. At the Agreement window, read through the Apple Beta Software Program Agreement agreement.
6. Once you’ve read through the agreement, click the Agree button.

7. At the Program window, click the Join button for the AppleSeed for IT program.

8. At the Agreement window, read through the AppleSeed for IT agreement.
9. Once you’ve read through the agreement, click the Agree button.

Once you’ve agreed to the AppleSeed for IT agreement, you should now be signed into the AppleSeed for IT website.

With this program signup completed, you should now be able to enroll devices in an Apple beta program using a token. The token-based enrollment method removes the need to sign into the device using an Apple Account. For more details on how to do this, please see the link below:

https://support.apple.com/guide/deployment/test-software-updates-appleseed-beta-program-depe8583cf10/web

A question I’ve seen pop up in the Mac Admins Slack since the release of macOS Tahoe 26.x goes something like this:

Why does macOS 26 have a build number that starts with 25?

The answer has to do with Darwin, the core operating system that is the foundation for all of the following Apple operating systems:

• audioOS
• bridgeOS
• iOS
• iPadOS
• macOS
• tvOS
• visionOS
• watchOS

For more details, please see below the jump.

The Darwin operating system has its own version number which is separate from the version number of the other Apple operating systems. In the case of macOS, Apple includes Darwin’s version number in the macOS build number. For example, the build number for macOS Tahoe 26.2.0 is the following:

25C56

The 25 part refers to the major version number for the current Darwin release. Beginning in 2011, the major version numbers of the Darwin operating system have coincided with the last two digits of the year it was released:

The current Darwin operating system release is 25.2.0 as of macOS Tahoe 26.2.0, so macOS Tahoe build numbers start with 25. Unless Apple decides to change Darwin’s version numbering system, this will mean that future macOS releases will continue to have build numbers that will start with a two digit number that is one number less than the macOS major version number.

As part of my personal changeover from using the Jamf Pro Classic API to using the Jamf Pro API, I’ve needed to change from using XML for the Jamf Pro Classic API to now using JSON for the Jamf Pro API. In particular, one of my issues has been figuring out how to properly write variables to JSON when updating something on the Jamf Pro server using the Jamf Pro API. As always when writing scripts, there’s usually multiple ways to solve a problem and I figured out a solution to mine using the printf command. For more details, please see below the jump.

As an example, I had written a post a while back about updating the asset tag number of a Jamf Pro computer inventory record using a script. As part of that script, I was using a command similar to the one below to send the updated asset tag information to the Jamf Pro server, defined in a variable named asset_tag_number_goes_here.

As part of that command, the following XML string is being sent with the asset_tag_number_goes_here variable being included:

The XML string is double quoted, so my script knows to read in the value from the asset_tag_number_goes_here variable because the variable is referenced using the $ character.

When I updated my script to use the Jamf Pro API and JSON, my command now looked similar to this:

My JSON string looked like this:

However, that didn’t work right and the asset_tag_number_goes_here variable’s value wasn’t being read correctly. Why? Because the JSON string uses single quotes to enclose it and in Bash, enclosing characters in single quotes means every character is being sent exactly as it is written.

How to fix this? The printf command was my eventual solution to the problem because in Bash, you can use printf to write a variable using what’s known as a format specifier. In this case, I needed to use the s format specifier because that will allow a string of characters to be used. To call the s format specifier for printf, %s% should be used.

To set it up, I needed to do the following in my script:

1. Create the JSON string with %s% in place of ${asset_tag_number_goes_here} and store that JSON string as a variable.
2. Use printf in a separate variable to create the JSON string and use the s format specifier to substitute the %s  with the value of the asset_tag_number_goes_here variable in the correct place inside the JSON string.
3. Send the API command and include the JSON string created by printf.

The end result looks similar to this:

One of the challenges with reporting on DDM settings is that as of macOS Tahoe 26.2.0 there aren’t currently command line tools available which can report back on settings which are managed via DDM declarations. You can see the settings which have been applied on the managed Mac via System Settings, but so far that’s about it. However, in some cases, Apple is writing information for some DDM declarations to files which are readable by command line tools. I recently discovered that one of those declarations was the com.apple.configuration.softwareupdate.settings Software Update Settings declaration. For more details, please see below the jump.

I have an earlier post on the Software Update Settings declaration and how it is used by Jamf Pro’s Blueprints. Using that information, I built and deployed a Software Update Settings declaration which has the following settings:

• Standard users can’t install Apple software updates
• Logged-in users will see all software update notifications
• OS updates will be automatically downloaded
• OS updates will be automatically installed
• Security updates will be automatically installed
• Rapid Security Response updates will be installed
• Rapid Security Response updates can be removed

Once deployed to managed Macs, you should be able to verify these settings by looking at the Software Update Settings declaration’s listing in System Settings.

You can also verify them by checking the following file:

/var/db/softwareupdate/SoftwareUpdateDDMStatePersistence.plist

On a managed Mac with those DDM settings running macOS Tahoe 26.2.0, the SoftwareUpdateDDMStatePersistence.plist file should show information similar to what’s shown below:

From there, you can use tools like PlistBuddy to read the values stored in the /var/db/softwareupdate/SoftwareUpdateDDMStatePersistence.plist file. For example, the following command should read the value for the enableRapidSecurityResponse key from the SoftwareUpdateDDMStatePersistence.plist file.

If Rapid Security Response updates are set to be installed, that should give you a value of true:

To the best of my knowledge, this method of verification is undocumented by Apple and they could choose to change it at any time. That said, if you’re looking for a way to report on Software Update Settings declaration settings, this is a way to do it as of macOS Tahoe 26.2.0.