It hits all the harder in that his death is so unexpected. Charles was one of the most alive people I knew. He wrote countless books (including a couple editions of Apple Device Management with me as co-author), either ran or appeared in multiple podcasts, had a full time job, contributed multiple open source tools and despite all of that always seemed to have time to talk. My regret is that I didn’t talk to him more often, with our last conversation happening in February.

I already miss you terribly, man. Wherever you are now, I hope you know how much you are loved and missed here.

If you have good memories of Charles, please share them in the comments below.

The original scripts would check the download directory and see if there was an installer package with the same name as an installer package in the JCDS2 distribution point. If there was an installer package with a matching name, download of the installer package was skipped and the script would move on to the next installer package.

In the updated scripts, if there are installer packages already in the download directory which have the same name as an installer package in the JCDS distribution point, the MD5 hash of the existing installer package is checked against the MD5 hash of the installer package stored in the JCDS distribution point. 

If the MD5 hashes match, download of the installer package with the matching name is skipped. If the MD5 hashes do not match, the existing installer package in the download directory is deleted and a fresh copy of the installer package is downloaded. For more details, please see below the jump.

Usage: 

/path/to/Jamf_Pro_JCDS_Installer_Package_Download.sh

The script takes the following actions:

• Creates a download directory if none has been specified in the script.
• Uses the Jamf Pro Classic API to download the list of installer packages from the Jamf Pro server.
• Gets the Jamf Pro ID numbers for the individual installer packages.
• Uses the Jamf Pro Classic API to get the names of the individual installer packages.
• Checks to see if a file with a matching name exists in the download directory.
• If a file with a matching name does not exist in the download directory, use the Jamf Pro API to query the JCDS2 distribution point for the download URL of the installer package and download the installer package.
• If a file with a matching name exists in the download directory, check the MD5 hash of the file with the matching name and compare it against the MD5 hash of the file in the JCDS2 distribution point. 
•  If the MD5 hashes match, display a message that the file exists in the download directory. 
•  If they don’t match, delete the file with the matching name from the download directory, use the Jamf Pro API to query the JCDS2 distribution point for the download URL of the installer package and download the installer package.

The script should provide output similar to this:

The scripts are available from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Installer_Package_Download

Advisory: I strongly advise having Jamf’s Professional Services folks involved if you’re planning a migration like this. The reason is that, as of the current Jamf Pro 11.3.2 release, you can only have one cloud distribution point at a time. A migration like the one I performed will involve a cut-over process which includes having to re-upload your current distribution point’s installer packages to the new JCDS2 distribution point. This process also necessitates having good recent backups for the Jamf Pro instance in question.

With the assistance of Jamf’s Professional Services (particular thanks to Sepie Moinipanah, Leslie Helou and David Raabe for their support), the migration in my case went smoothly. Please see below for the process I followed to migrate from an AWS-hosted cloud distribution point to using a Jamf-hosted JCDS2 cloud distribution point:

Pre-requisites:

• A copy of all of the installers in the current AWS-hosted cloud distribution point
• The Cloud Services connection enabled in your Jamf Pro server’s settings
• jamfCPR
• API Client Role and API Client with the correct permissions
• A very recent backup of your Jamf Cloud-hosted Jamf Pro server

Getting the installers from your current distribution point:

There are several ways to get the installers from an AWS-hosted cloud distribution point. The method I chose was to use AWS’s command line tool to sync the contents of the S3 bucket used by the cloud distribution point to a local directory on my workstation:

https://derflounder.wordpress.com/2018/02/15/backing-up-the-contents-of-an-aws-hosted-jamf-pro-cloud-distribution-point-to-a-local-directory/

API Client Role and API Client:

The jamfCPR wiki describes the necessary permissions needed to sync installer packages to a JCDS2 cloud distribution point, in the context of an API Client Role. As a result, I used an API Client Role and API Client in this case because the API Client Role permissions don’t always map one-to-one to the permissions available to Jamf Pro accounts and groups. Please see below for the permissions I set for my API Client Role:

• Read Cloud Services Settings
• Read Distribution Points
• Create Packages
• Read Packages
• Update Packages
• Delete Packages
• Read Cloud Distribution Point
• Update Cloud Distribution Point
• Create Jamf Content Distribution Server Files
• Read Jamf Content Distribution Server Files
• Delete Jamf Content Distribution Server Files
• Jamf Packages Action

Preparing for the distribution point migration:

1. Verify that you have the latest version of jamfCPR available.

Note: If the JCDS2 cloud distribution point you’re migrating to is located outside of the United States, make sure you’re using jamfCPR 5.x or later. jamfCPR 4.12 and earlier is not able to work with JCDS2 cloud distribution points which are hosted in AWS regions outside of the United States.

2. Verify that you have an API Client Role and API Client on the Jamf Pro server which has the correct permissions assigned.

3. Verify that you have a copy of all installers on your current AWS-hosted cloud distribution point stored on the same Mac that you have the jamfCPR app installed on.

4. Work with Jamf to make sure that a backup of your Jamf Pro service is made just prior to doing the migration.

Advisory about the Jamf Pro backup:

At this point, I want to stop for a moment and discuss why that backup of your Jamf Pro service is so important. The reason has to do with how AWS-hosted cloud distribution points are created. When you set one up, Jamf Pro will do the following:

1. Create an S3 bucket with a randomly-generated name in the US-East-1 AWS region.
2. Create an associated CloudFront distribution which connects to the S3 bucket created in Step 1.

As the Jamf Pro admin, you don’t get to choose anything in this process and you can’t select an existing S3 bucket. What this means is that the migration goes wrong and you need to revert back to your AWS-hosted cloud distribution point, the only way to do so is to roll back your Jamf Pro service to a point in time before the migration started. You will not be able to go back to using your existing AWS-hosted cloud distribution point without restoring from that backup because there is no way otherwise to have Jamf Pro use that existing AWS-hosted cloud distribution point.

If you try to go back otherwise, Jamf Pro will not use the existing AWS-hosted cloud distribution point. Instead, Jamf Pro will set up a new S3 bucket and CloudFront distribution and you will now have a brand-new and completely empty AWS-hosted cloud distribution point.

Running the migration:

1. Log into your Jamf Pro server as an admin user with all needed rights.

2. Verify that the Cloud Services connection is logged in and appears to be working properly.

3. Go to Settings: Server: Cloud distribution point.

4. Click the Test button and verify that your connection to the cloud distribution point is working correctly.

5. Install something from your Jamf Pro server and verify that installation is working correctly.

6. Verify in your policy logs that the installer is coming from an address which matches something similar to what’s shown below:

https://d2zft6agzhvlnv.cloudfront.net

7. In your Jamf Pro server, go to Settings: Server: Cloud distribution point.

Note: The next step is a point of no return, for reasons described above in the Advisory about the Jamf Pro backup section. Make sure a very recent Jamf Pro backup is available.

8. Select Jamf Cloud and click the Save icon.

9. Click the Test button and verify that your connection to the cloud distribution point is working correctly.

10. Open the jamfCPR app on your Mac.

11. Select the directory containing the downloaded copy of the installers from the existing AWS-hosted cloud distribution point.

12. Set up the connection to your Jamf Pro service, using the API Client ID and its associated Client ID Secret.

13. Click the List button in the jamfCPR app. You should now see a list of packages that your Jamf Pro service has, showing a status of different.

Note: To allow the migration process to go quickly for this blog post, I’m using dummy installer packages with a size of one kilobyte. The jamfCPR app should display the actual size of the installer packages in its application window when the installers are listed.

14. Select the packages you want to copy back from the downloaded copy of the installers to your Jamf Pro service.

15. Click the Replicate button.

You can monitor the replication process using the jamfCPR logs, which are available under the View menu using the Show Logs command.

16. Once replication is completed, the packages should appear as Availability Pending when you bring up information on the package in the Jamf Pro admin console.

You also won’t see any packages listed in the Cloud distribution point screen available via Settings: Server: Cloud distribution point.

This is normal and the package should already be available for installation. One way to verify that the packages are present in the JCDS2 distribution point is by downloading them from the JCDS2 distribution point. I have a post on how to do this available via the link below:

https://derflounder.wordpress.com/2024/02/24/using-the-jamf-pro-api-to-download-installer-packages-from-a-jcds2-distribution-point/

17. Install something from your Jamf Pro server and verify that installation is working correctly.

18. Verify in your policy logs that the installer is coming from an address which matches something similar to what’s shown below:

https://server_name_here.jamfcloud.com/jcds

Note: If you’re using a custom DNS name for your Jamf Cloud instance, it would appear similar to what’s shown below:

https://server_name_here.custom_domain.here/jcds

Post-migration:

After about an hour, the packages should appear listed in the Cloud distribution point screen available via Settings: Server: Cloud distribution point:

The Availability Pending message should also disappear when you view information about the installer package.

For folks who don’t want the clock display, it’s possible to turn it off via System Settings. In the Lock Screen settings, set the Show large clock option to one of the following settings:

• On Screen Saver and Lock Screen
• On Lock Screen
• Never

The Never setting will stop from being displayed on either the login window or as part of the screen saver.

For more information, please see below the jump.

For those who want a profile which can enforce the Never setting, please see below. It’s also available via the GitHub link below:

https://github.com/rtrouton/profiles/tree/main/DisableLoginWindowClock

https://learn.jamf.com/bundle/jamf-cloud-distribution-service-release-notes/page/Release_History.html

Among these new API capabilities is the ability to query a JCDS 2 DP for download links, for the installer packages stored in the distribution point.

https://developer.jamf.com/jamf-pro/reference/get_v1-jcds-files-filename

I’m interested in this because I’ve had an existing workflow for downloading installer packages from a non-JCDS AWS-hosted cloud distribution point, where I’ve been using AWS’s awscli command line tool to run a one-way synchronization process between the cloud distribution point in Amazon’s S3 service and a local directory stored on a Mac.

For those who want to use this new capability, I’ve written a script which uses the Jamf Pro Classic API and Jamf Pro API to get the list of installer packages on a Jamf Pro server, retrieve the associated download links and download the installer packages to a directory on my Mac. For more details, please see below the jump.

Pre-requisites:

If setting up a specific Jamf Pro user account for this purpose with limited rights, here are the required API privileges for the account on the Jamf Pro server:

Jamf Pro Server Objects:

• Packages: Read
• Jamf Content Distribution Server Files: Read

For authentication, the script can accept manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file. The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

To store the account username in the plist file:

To store the account password in the plist file:

Usage: 

/path/to/Jamf_Pro_JCDS_Installer_Package_Download.sh

The script takes the following actions:

1. Creates a download directory if none has been specified in the script.
2. Uses the Jamf Pro Classic API to download the list of installer packages from the Jamf Pro server.
3. Gets the Jamf Pro ID numbers for the individual installer packages.
4. Uses the Jamf Pro Classic API to get the names of the individual installer packages.
5. Checks to see if a file with a matching name exists in the download directory.
6. If a file with a matching name exists in the download directory, display a message that the file exists in the download directory.
7. If a file with a matching name does not exist in the download directory, use the Jamf Pro API to query the JCDS2 distribution point for the download URL of the installer package and download the installer package.

The script should provide output similar to this:

This script is available below and also from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Installer_Package_Download/user_account_authentication

A version of this script which uses Jamf’s API client authentication instead of a Jamf Pro user account is available from GitHub at the following location:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Installer_Package_Download/API_client_authentication

Both scripts can be accessed via the following link:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_JCDS_Installer_Package_Download

1. Signed with an Apple Developer ID Installer certificate
2. Be a distribution installer package

For criteria #2, this references the fact that there are two kinds of modern installer packages for macOS:

• Component packages: these are the standard type of installer package, which contain an archive of files to install and the information on where the files should be installed.
• Distribution packages: These packages can contain one or more component packages, and may also include additional resources to customize and control the user interface shown in the Installer application.

By default, AutoPkg will build component packages using the PkgCreator processor or the AppPkgCreator processor. But there is a relatively straightforward way to create a a distribution package while using an existing component package as a source, using the productbuild command. To create a distribution installer package from an existing component installer package, you would use a command similar to the one shown below:

Note: If using a signed component installer package as a source, the resulting new distribution package will not be signed. If needed, you will need to sign the distribution package following its creation.

For those who want to create distribution packages as part of an AutoPkg workflow, I’ve written a DistributionPackageCreator AutoPkg processor which is designed to perform the following tasks:

1. Rename the existing AutoPkg-generated component package.
2. Create a new distribution package from the AutoPkg-generated component package.
3. Set the newly-created distribution package to have the original name of the AutoPkg-generated component package.

For more details, please see below the jump.

The DistributionPackageCreator processor is shown below, as well as being available via the following link:

https://github.com/rtrouton/AutoPkg_Processors/tree/main/DistributionPackageCreator

Update – 2-5-2024: It turns out that both myself and @davidbpirie wrote practically identical AutoPkg processors. His processor is FlatToDistPkg (written in 2022) and it is available in his repo:

https://github.com/autopkg/davidbpirie-recipes/tree/main/SharedProcessors

When included in an AutoPkg recipe, the DistributionPackageCreator processor will locate AutoPkg-generated component packages by using the pkg_path variable and do the following:

1. Rename the AutoPkg-generated component package from /path/to/package_name_here.pkg to /path/to/package_name_here-component.pkg
2. Create a new distribution package from the AutoPkg-generated component package.
3. Save the distribution package as /path/to/package_name_here.pkg, so that the name matches the original package.

Note: Setting the distribution package’s name to match the original component package’s name allows AutoPkg to continue to work with the distribution installer package.

To assist folks who want to use this processor, but don’t want to rewrite their existing .pkg recipes, I’ve written an example recipe to assist with this: the .distpkg recipe.

The .distpkg recipe uses the DistributionPackageCreator processor and is designed to be placed in the AutoPkg workflow between a .pkg recipe and whatever else came next. In this case, the .pkg recipe would be a parent recipe for the .distpkg recipe. In turn, the .distpkg recipe would be used as the parent recipe for whatever came next in the workflow.

A good example would be if you wanted to create a signed distribution package. In that case, you could combine a .pkg recipe, a .distpkg recipe and a .sign recipe into the same workflow to produce a signed distribution package, which should meet all the necessary requirements to install the package via an MDM command.

For those who want to use .distpkg recipes, there is an example recipe available via the link below:

https://github.com/autopkg/rtrouton-recipes/blob/master/SharedProcessors/Example.distpkg.recipe

https://gist.github.com/rtrouton/f8f2433843d0b5a7880439ad0fce4298

If you want to use the DistributionPackageCreator processor hosted from my AutoPkg recipe repo, first verify that AutoPkg is installed on the Mac you’re using. Once verified, run the following command:

In this example, there are going to be multiple AutoPkg recipes and support files referenced:

• CiscoSecureClient.download.recipe – Download recipe for the vendor-supplied Cisco Secure Client disk image with the vendor-supplied installer package stored inside.
• CiscoSecureClient.pkg.recipe – Package recipe for Cisco Secure Client, which generates an installer choices XML file and wraps both the installer choices XML file and the vendor-supplied installer package inside a separate installer package generated by AutoPkg
• Example.xml – Sample VPN profile for Cisco Secure Client’s VPN module
• CiscoSecureClient package recipe override – This is the AutoPkg recipe override where you’re defining how the installer choices file is configured and other information being supplied to the Cisco Secure Client installer by the AutoPkg package creation process.

Important information:

A. The recipes as written assume the following:

• You’re using the Cisco Secure Client Umbrella module.
• You’re adding the necessary configuration information for the Cisco Secure Client Umbrella module to the AutoPkg recipe override.
• You may be using the Cisco Secure Client VPN module.

B. You absolutely must create an AutoPkg override to work with these recipes. The download location, configuration for the installer choices XML file and other settings are not included in the AutoPkg recipes themselves and must be defined in the override.

C. The Cisco Secure Client disk image does not have a set address for download, so you will need to do one of the following:

• Download the disk image from Cisco and host it yourself somewhere.
• Change the download URL in the AutoPkg recipe override to match wherever you can currently download the Cisco Secure Client disk image from.

D. To configure the installer choices XML file, you must designate what modules you want to include using ones and zeros in the AutoPkg override. By default, the .pkg recipe is configured to install all modules:

To change this, change one to zero for the modules you don’t want to install. For example, the configuration below will configure the Secure Client installer to only install the Secure Client Umbrella module:

E. If you do not want to have the VPN module installed or enabled, you will need to set the CHOICE_VPN and DISABLE_VPN settings in the recipe override. Please see below for an example:

In this example, the CHOICE_VPN setting is set to zero and the DISABLE_VPN setting is set to true.

F. These recipes allow you to hide the Cisco-provided Secure Client installers, so that your users will not be able to see them in the Finder. Like the installer choices selection, this can be set using ones and zeros in the AutoPkg override.

To hide, set the HIDE_UNINSTALLERS setting to one:

To not hide the uninstallers, set the HIDE_UNINSTALLERS setting to zero:

G. It’s possible to disable the customer feedback functionality through the installer. To set this to be disabled, set the DISABLE_CUSTOMER_EXPERIENCE_FEEDBACK setting to true.

To leave the customer feedback functionality enabled, set the DISABLE_CUSTOMER_EXPERIENCE_FEEDBACK setting to false.

Please see below for the example .download and .pkg recipes, example VPN XML file and example .pkg recipe override:

Download recipe:

Package recipe:

Example VPN XML file:

Example .pkg recipe override:

The Jamf Pro Server Action privilege, “Enroll Computers and Mobile Devices”, was split into two separate privileges.

What this means is that in Jamf Pro versions before 11.2.0, you had one permission:

• Enroll Computers and Mobile Devices

As of Jamf Pro 11.2.0, there are now two permissions:

• Enroll Computers
• Enroll Mobile Devices

The important thing to know is that as part of upgrading to Jamf Pro 11.2.0, the Enroll Computers and Mobile Devices permission is removed, but the following permissions are not selected automatically:

• Enroll Computers
• Enroll Mobile Devices

To address this issue, if needed go into the Jamf Pro admin console following the upgrade to Jamf Pro 11.2.0 and select the new separate Enroll Computers and Enroll Mobile Devices permissions.

Desired behavior:

1. Open application.
2. Click the login button.
3. Be prompted for the Entra ID user account to sign in with.
4. Log in with that user account.

Actual behavior:

1. Open application.
2. Click the login button.
3. Be automatically logged in as the Entra ID user registered for single sign-on.

Unfortunately for my use case, I really needed to have the application in question prompt the user for which account they needed to log in with because a user account other than the one registered for single sign-on needed to be able to sign in to the application in question.

After some discussion in the #jamf-intune-integration channel in the Mac Admins Slack, I was pointed towards a way to sign out the account which was enabled for single sign-on using Microsoft’s Company Portal application. With no account enabled for single sign-on, the application would now prompt for a user account to sign in with. For more details, please see below the jump.

To sign out the Entra ID account enabled for single sign-on using the Company Portal application, please use the procedure described below:

1. Open the Company Portal application.

2. Sign into the Company Portal application as the user of the computer.

3. Under the Company Portal menu in the menubar, select Settings…

4. In the Settings window, in the Single sign-on (SSO) section, click the Remove account from this device button.

Note: I’ve noticed that clicking the Remove account from this device button doesn’t make a noticeable change in the Settings window; the account still appears as enabled. However, clicking the button should do what’s needed and applications should now prompt for a user account.

https://www.motionbug.com/jamf-pro-and-macos-onboarding/

One of the things to be aware of with the new macOS Onboarding feature is that once the feature has been enabled, macOS Onboarding will run its associated policies on all Macs which don’t have the following user-level preference set:

• Domain: com.jamfsoftware.selfservice.mac
• Key: com.jamfsoftware.selfservice.onboardingcomplete
• Value: Boolean (TRUE or FALSE)

Value set to FALSE (allowing macOS Onboarding to run):

Value set to TRUE (blocking macOS Onboarding from running):

Fortunately, it’s possible to add this setting with a value of TRUE to a macOS configuration profile and deploy the profile to all Macs that you don’t want to run macOS Onboarding on.

For those who would need this, I have an example macOS configuration profile with com.jamfsoftware.selfservice.onboardingcomplete set to TRUE available via the link below:

https://github.com/rtrouton/profiles/tree/main/JamfProSelfServiceOnboardingCompleted