Jamf School and installer packages

With Jamf School it’s possible to upload a macOS installer to distribute via an “automated MDM enrolment profile” or as part of another workflow. You can read more about this in my first blogpost.

However there are some peculiar behaviours you should know about which I encountered using Jamfschool the past 2 years. These behaviours are some of the “challenges” where I’m trying to find a workaround for. But that’s material for a future blogpost!

How Jamfschool analyses a package when uploading

Note: The package must be a “Distribution” style package format. If you want to know more about this style of packages or packaging in general, check Armin Briegel’s excellent book: “Packaging for Apple Administrators”

When you upload a package the following actions are performed:

  • Jamf School starts a parsing process. 
  • It tries to find an .app bundle and reads the xxx.app/Contents/Info.plist file.
  • Jamf School will retrieve the CFBundleShortVersionString and the CFBundleIdentifier keys from the Info.plist file
  • It displays the information so you can change the name of the installer, add additional scopes etc.
  • Jamf School also signs your installer package. If you signed the package with your own Developer certificate, that certificate will be changed to the one from Jamf School.

If your package is a “Payload free” package or doesn’t contain an .app bundle:

  • Jamf School starts a parsing process. 
  • It tries to find an .app bundle and reads the xxx.app/Contents/Info.plist file.
  • Jamf School can’t find a .app bundle, so it will create a random .app bundle for you
  • That new .app bundle will be added to your package in “/Library/Jamf\ School/Notifiers/jamf-school.notifier.xxxxxx.app 

The reason why Jamf School adds the bundle to the installer is to keep track if the package is installed on a macOS client. It does add an extra unidentifiable entry in the /var/db/receipts database that’s unrecognisable for us admins! For example: com.jamfschool.notifier.23d03eaf-1d34-46bd-b333-25b96fdd7768..pkg. Notice there’s a double dot in the name…..

Limitations with installer package versions

The mechanism that Jamf School uses to import and check installer packages isn’t what a macOS sysadmin “expects” how it should work. They perform an extra check if the package xxx.app/Contents/Info.plist “CFBundleIdentifier” already exists for any current uploaded packages in Jamf School’s application list. If there’s a package with the same “CFBundleIdentifier” it will notify you that the package is already uploaded. You have 2 options: Cancel or replace existing package.

As you can see in the screenshots below these are 2 totally different packages for a macOS device. Well not according to Jamf School as you can see in screenshot 5.

Why doesn’t Jamf School use the installer package info to read the receipts that macOS writes to the local /var/db/receipts database?

Screenshot 4:

screenshot 5:

This limitation makes it impossible to:

  • Test a new version of the package. Remember you can only replace the current package, even if you choose a new “Add app”.
  • Upload a second different version of the package that contains other pre or post install scripts, even if the package has totally different receipts.

Challenges I encounter with Jamf School and the Munki installers

For the fleet that I manage I actually needed 2 versions of the Munki installer packages created with the “make_munki_mpkg_DEP.sh” script.

One Munki installer that works from DEP with bootstrap and another without bootstrap. I can create a separate package that contains the bootstrap file, but due to possible APNS failures I want everything in one package.

Munki 5

Munki 5 has been released to circumvent the (broken) “/usr/sbin/softwareupdate” binary and prompts the user of the device to install macOS and security updates that require a reboot. 

So now I need extra versions of the Munki installer in Jamf School:

  1. Munki 4 dep and bootstrap package for our (non T2) 10.14 shared lab macOS clients bound to Active Directory
  2. Munki 5 dep and bootstrap package for our 10.14/10.15 personal desktops bound to Active Directory
  3. Munki 5 dep without bootstrap package for our 10.14/10.15 personal Macbooks

That’s it for this blogpost. My next post will be about the possible solutions I am currently working on. 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s