babgond

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.

As part of the What’s new for enterprise in macOS Tahoe 26 release notes for macOS Tahoe 26.2.0, there’s this note:

App privacy permissions configured by device management are now shown in System Settings > Privacy & Security.

What this indicates is that a long-standing feature request by Mac admins has been fulfilled by Apple. For more details, please see below the jump.

As part of macOS 10.14 Mojave, Apple introduced a number of privacy controls for user data. At the same time, Apple also introduced device management options to allow authorized applications to access data protected by those privacy controls. These permissions are referred to collectively as Privacy Preferences Policy Control (PPPC) and are deployed via management profiles from an MDM server. However, up until macOS Tahoe 26.2, there was no way to see in the Privacy & Security section of System Settings which applications had which permissions granted via PPPC management profiles.

As an example, by default, Macs managed by Jamf Pro will get a management profile which allows the Jamf agent permission to access data stored in the user home folder via the PPPC permission known as full disk access. Here’s how this looks on macOS Tahoe 26.1.0:

Privacy Preferences Policy Control profile installed which enables full disk access to the Jamf agent.

No mention of the full disk access permissions granted to the Jamf agent in the Privacy & Security section of System Settings.

How this looks on macOS Tahoe 26.2.0:

Privacy Preferences Policy Control profile installed which enables full disk access for the Jamf agent.

Full disk access permissions granted to the Jamf agent are disclosed in the Privacy & Security section of System Settings. It is also disclosed that the permissions setting is configured by a profile.

A while back, I wrote a post on how to set Jamf Pro computer inventory records to be managed using a script. I recently revisited this script as part of a general effort on my part to update scripts which have been using the now-deprecated computers Classic API endpoint, to now use the Jamf Pro API’s computers-inventory-detail API endpoint.

As part of this effort, I decided to not only update my existing script for setting the management status in Jamf Pro computer inventory records to be managed but also write a second script for setting the management status to be unmanaged. For more details, please see below the jump.

You can set the management status in a Jamf Pro computer inventory record using the computers-inventory-detail endpoint for the Jamf Pro API. The API command to change the management status in a Jamf Pro computer inventory record to Managed should look similar to this:

It’s sending the following JSON block to update the relevant computer inventory record and make the management change:

The API command to change the management status in a Jamf Pro computer inventory record to Not Managed should look similar to this:

It’s sending the following JSON block to update the relevant computer inventory record and make the management change:

I was able to use the API information discussed above to create a couple of scripts which a) update the management status in specified computer inventory records and b) generates a report of the Macs whose computer inventory records were updated.

The scripts are named Set_Jamf_Pro_Computers_To_Managed_Status.sh and Set_Jamf_Pro_Computers_To_Unmanaged_Status.sh and are available via the links below:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Set_Jamf_Pro_Computers_To_Managed
https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Set_Jamf_Pro_Computers_To_Unmanaged

Both scripts are designed to take in a set of Jamf Pro ID numbers in a plaintext file, where the Jamf Pro ID numbers correspond the Macs where you want to change the management status in their Jamf Pro computer inventory records. The plaintext file should look similar to this:

Four items are required to use these scripts:

• A text file containing the Jamf Pro IDs of the computer(s) you wish to delete.
• The URL of the appropriate Jamf Pro server.
• The username of an account on the Jamf Pro server with sufficient privileges to delete computers from the Jamf Pro server.
• The password for the relevant account on the Jamf Pro server.
• Jamf Pro account privileges required by the Jamf Pro server account referenced above:

Jamf Pro Server Objects:

• Computers: Read, Update
• Users: Update

Once the four specified items are available, the scripts can be run using the following commands:

For Set_Jamf_Pro_Computers_To_Managed_Status.sh:

For Set_Jamf_Pro_Computers_To_Unmanaged_Status.sh:

For Set_Jamf_Pro_Computers_To_Managed_Status.sh, you should see output that looks like this:

As part of the script’s run, a report will be generated and you’ll be notified of where it is stored. The report will be in TSV format and appear similar to what’s shown below:

For Set_Jamf_Pro_Computers_To_Unmanaged_Status.sh, you should see output that looks like this:

As part of the script’s run, a report will be generated and you’ll be notified of where it is stored. The report will be in TSV format and appear similar to what’s shown below:

In addition to the scripts described above which use user accounts for authentication, there are also matching scripts which use API client authentication available on GitHub via the links above. If setting up an API client with limited rights, here are the required API role privileges for the API client on the Jamf Pro server:

• Computers Read
• Computers Update
• Users Update

In macOS, applications record version information in the Information Property List file. This file is stored inside the Contents directory of the application bundle and is named Info.plist.

There are two keys inside the Info.plist file for an application which store version information:

• CFBundleVersion
• CFBundleShortVersionString

What’s the difference between the two?

• CFBundleVersion: This is the version information used by macOS to determine which version is the most recent version of an application.
• CFBundleShortVersionString: This is the version information which is displayed to the user in a Finder window or a Get Info window.

There is no requirement in macOS that both the CFBundleVersion and CFBundleShortVersionString keys in the Info.plist file contain the same version information. What can happen as a result? Let’s take a look at that the context of some Microsoft applications which record different information in the Info.plist file for those two keys. For more details, please see below the jump.

For this example, I installed the following Microsoft apps on a macOS 26.1.0 VM:

• Microsoft Excel.app
• Microsoft PowerPoint.app
• Microsoft OneNote.app
• Microsoft Outlook.app
• Microsoft Word.app
• OneDrive.app
• Windows App.app

For each app, I checked the following:

• CFBundleShortVersionString
• CFBundleVersion
• Reported version on the Mac

Microsoft Excel.app

• CFBundleShortVersionString: 16.103.3
• CFBundleVersion: 16.103.25113013
• Reported version on the Mac: 16.103.3

Microsoft PowerPoint.app

• CFBundleShortVersionString: 16.103.3
• CFBundleVersion: 16.103.25113013
• Reported version on the Mac: 16.103.3

Microsoft OneNote.app

• CFBundleShortVersionString: 16.103.3
• CFBundleVersion: 16.103.25113013
• Reported version on the Mac: 16.103.3

Microsoft Outlook.app

• CFBundleShortVersionString: 16.103.3
• CFBundleVersion: 16.103.25113013
• Reported version on the Mac: 16.103.3

Microsoft Word.app

• CFBundleShortVersionString: 16.103.3
• CFBundleVersion: 16.103.25113013
• Reported version on the Mac: 16.103.3

OneDrive.app

• CFBundleShortVersionString: 25.209.1026
• CFBundleVersion: 25209.1026.0002
• Reported version on the Mac: 25.209.1026

Windows App.app

• CFBundleShortVersionString: 11.2.9
• CFBundleVersion: 2810
• Reported version on the Mac: 11.2.9

As you can observe, what’s reported in these two fields can be very different. How does this affect Jamf Pro? Up until Jamf Pro 11.23.0, only one of those keys in the Info.plist file was being used to get version information for a macOS application:

CFBundleShortVersionString

This was reported as part of a computer inventory record as the following field:

• Version

The Version reporting also has matching smart group and advanced computer search criteria:

• Application Version

However, version information for Microsoft applications in particular were often being reported in Jamf Pro using the information contained in the following key:

• CFBundleVersion

If CFBundleVersion and CFBundleShortVersionString did not have the same version information, now you have a problem because what you see in Jamf Pro for version information for that Microsoft app and what you’re seeing reported in a Finder window for version infomation are two different things. To help address this, as of Jamf Pro 11.23 two new reporting fields as well as matching smart group and advanced computer search criteria have been added:

• Bundle Short Version
• Bundle Version

Here’s how they’re mapping to the keys in the application’s Info.plist file:

• Bundle Short Version: CFBundleShortVersionString
• Bundle Version: CFBundleVersion

The existing Version reporting field and matching Application Version smart group and advanced computer search criteria have not gone away, since up until Jamf Pro 11.23 it was your only option. The new reporting information has been added and does not replace previously gathered data, so nothing in anyone’s existing version reporting setup should break.

Here’s how it should look as of Jamf Pro 11.23.0 for a computer inventory record’s application listing:

• Name
• Version
• Bundle Short Version
• Bundle Version
• Path
• App Store

Note: The Bundle Short Version and Bundle Version fields may initially be blank for devices which have not sent in an inventory update since Jamf Pro was upgraded to 11.23.

The matching smart group and advanced computer search criteria are as follows:

• Applications inventory listing: Bundle Short Version
• Smart and advanced computer search criteria: Application Bundle Short Version

• Applications inventory listing: Bundle Version
• Smart and advanced computer search criteria: Application Bundle Version

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 is the Welcome to macOS Tahoe 26 screen, which provides a walkthrough of selected new features available in macOS Tahoe.

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Welcome to macOS Tahoe 26 screen on macOS Tahoe 26.1.0 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: OSShowcase

The profile is available on GitHub via the link below:

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