Losing a giant

I learned today that Charles Edge, one of the smartest people I’ve been privileged to know in my life, has passed away. I don’t know more details, but we have lost a kind and magnificent giant in the Mac Admins community and I have lost a good friend. 

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.

Updated scripts for downloading packages from a JCDS2 distribution point

As part of an earlier post, I had provided scripts for downloading installer packages from a JCDS2 distribution point. I’ve made some updates to the scripts to provide more checking of the installer packages, to hopefully ensure that the downloaded installer package and the package available in the JCDS2 distribution point are exactly the same package.

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.

Migrating a Jamf Pro AWS-hosted cloud distribution point to a JCDS2 cloud distribution point

I recently needed to migrate a Jamf Cloud-hosted Jamf Pro instance from using an AWS-hosted cloud distribution point to using a Jamf-hosted JCDS2 cloud distribution point. For those looking at a similar migration, please see below the jump for more details.

Disabling login window clock display on macOS Sonoma

One of the changes with macOS Sonoma is to the login window, where the username blanks and icons were made smaller and moved down to the bottom of the screen and a large clock display is enabled by default near the top of the login window.

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.

Using the Jamf Pro API to download installer packages from a JCDS2 distribution point

As part of Jamf’s release of Jamf Cloud Distribution Service 2.0, Jamf has added the ability to communicate with a JCDS 2 distribution point via the Jamf Pro API:

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.

Building distribution packages using AutoPkg

I’ve been thinking about the issue of building installer packages using AutoPkg which are ready for installation using MDM commands. Installing an installer package via MDM command requires packages to have the following attributes:

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:

/usr/bin/productbuild –package /path/to/package_being_converted_to_distribution.pkg /path/to/new_distribution_package.pkg

view raw

gistfile1.txt

hosted with ❤ by GitHub

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.

Using AutoPkg to build a Cisco Secure Client installer

Fraser Hess recently posted about automating the creation of Cisco Secure Client installers. Similar to my earlier post on using AutoPkg to build a Cisco AnyConnect installer, it’s possible to replicate this packaging workflow, including generating an installer choices XML file, using AutoPkg. For more details, please see below the jump.

Jamf Pro 11.2.0 computer and mobile device enrollment permission changes

As part of Jamf Pro 11.2.0 and later, Jamf has made a permissions change which affects enrollment. It is is mentioned in the 11.2.0 release notes in the Other Changes and Improvements section:

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.

Clearing the logged-in Microsoft SSO user on macOS using Microsoft’s Company Portal app

As part of working on a task recently, I ran into an issue with Microsoft’s Enterprise SSO plug-in on macOS. This plug-in enables single sign-on for Entra ID accounts for applications which support it. In this case, the issue was the following:

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.

Blocking Jamf Pro’s macOS Onboarding feature using a macOS configuration profile

One of the new features of Jamf Pro 11.1.x and later is macOS Onboarding, which is a Self Service-based feature which provides a way to run a setup policy or policies. Rob Potvin has a good write-up on it here, which I recommend checking out:

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):

	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
	<plist version="1.0">
	<dict>
	<key>com.jamfsoftware.selfservice.onboardingcomplete</key>
	<false/>
	</dict>
	</plist>

view raw

com.jamfsoftware.selfservice.mac.plist

hosted with ❤ by GitHub

 

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

	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
	<plist version="1.0">
	<dict>
	<key>com.jamfsoftware.selfservice.onboardingcomplete</key>
	<true/>
	</dict>
	</plist>

view raw

com.jamfsoftware.selfservice.mac.plist

hosted with ❤ by GitHub

 

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