Downloading installer packages from Jamf Pro when no other options are available

Every so often, Mac admins who administer Jamf Pro may run into a situation like this:

1. They need an installer package For Reasons.
2. That installer package is only stored on their Jamf Pro server.
3. They don’t have access to the distribution point which stores their Jamf Pro server’s installer packages.

In a situation like this, you can use a Jamf Pro policy to provide the installer to a specified Mac. For more details, please see below the jump.

Providing Jamf Pro computer inventory information via macOS configuration profile

Jamf Pro can store and make available a lot of information about a particular computer and who is using it as part of the computer’s inventory record, but it can be challenging to access that information from the computer itself.

It is possible to use an API call to access this information, using either the Jamf Pro API or Jamf Pro’s Classic API, but that means providing a way to authenticate to the API. This may pose some security issues as you will need to both:

• Provide a way for the computer to access those authentication credentials
• Protect the authentication credentials from potentially malicious third parties

Fortunately, there is an alternative way to provide at least some inventory information without needing to make an API call. Jamf Pro provides a number of variables which can be used in macOS configuration profiles and it’s possible to leverage those variables to build a profile whose task is providing information from the computer’s inventory record in Jamf Pro in a way which can be accessed from the managed computer. For more details, please see below the jump.

Using the Jamf Pro API to retrieve FileVault personal recovery keys

As part of Jamf Pro 10.43’s release, Jamf has added the ability to access and retrieve FileVault personal recovery keys via the Jamf Pro API:

• Return FileVault information for a specific computer: https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory-id-filevault
• Return paginated FileVault information for all computers: https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory-filevault

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 take a list of Jamf Pro computer IDs from a plaintext file, retrieve the associated Macs’ FileVault personal recovery keys and generate a report in .tsv format.

For more details, please see below the jump.

Creating a NexThink uninstaller for deployment via Jamf Pro

As a follow-up to my previous post on building an installer for NexThink Collector which could be deployed via Jamf Pro, I also needed to build an uninstaller for this software. Fortunately, NexThink ships an uninstaller script on the same disk image that it uses to ship its installer.

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing the following to run the uninstall process:

A. Mounting the disk image
B. Opening the Terminal application
C. Using the uninstaller script to run the uninstallation process.

In my case, I decided to do the following to deploy the uninstaller via Jamf Pro:

1. Wrap the disk image inside a separate installer package.
2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Use the uninstall script to uninstall the NexThink Collector software.
D. Unmount the disk image.

For more details, please see below the jump.

Creating a NexThink installer for deployment via Jamf Pro

A while back, I had to build an installer for NexThink Collector which could be deployed via Jamf Pro. NexThink can be interesting to deploy because the installation process:

1. Involves an application named csi.app, which has a command line tool.
2. The referenced csi app’s command line tool configures and runs an installer package.
3. The command line tool also needs to reference a license file, which NexThink refers to as a CustomerKey file.

The CustomerKey file should look similar to what’s shown below:

—–BEGIN CUSTOMER KEY—–MIIDhzCCAm+gAwIBAgIEIa+KoTANBgkqhkiG9w0BAQsFADBbMScwJQYDVQQDDB5SZWdlcnkgU2VsZi1TaWduZWQgQ2VydGlmaWNhdGUxIzAhBgNVBAoMGlJlZ2VyeSwgaHR0cHM6Ly9yZWdlcnkuY29tMQswCQYDVQQGEwJVQTAgFw0yMjEyMDIwMDAwMDBaGA8yMTIyMTIwMjIwMDIxMFowSTEVMBMGA1UEAwwMbG9jYWxob3N0LmlvMSMwIQYDVQQKDBpSZWdlcnksIGh0dHBzOi8vcmVnZXJ5LmNvbTELMAkGA1UEBhMCVUEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaKRW9KeX4wg/838FkxmzaBjqf1DeKD5GKEqhUKz0y78Wwnsv2zAXGM4UkdZJP9zHtC9/wFQT+lhclDlogxkU9lfMADV7nMdGL0GkJzwMQNS52dPNXDup7/d9yRkyjkV0Pf4t2fJF3igoNXFQuBvuArkNV6hfja2gOEczOSAaJ7L7qRnSahLjciJRaCuEPjwneh3krhOFT+djwuYJMIvBDEqs+gfp4OPDDBtVg2scUUGRmHsC+JAoK+JwqYwB9TNt+9hZtGfDqgZSHebXEfRTguhQpBj0mPTo76EahAbHbXJhV+efg3jt32pZ6qRl8ffrZAjefWEAnOMyXQ7fbL+bpAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zAfBgNVHSMEGDAWgBRNHRZG3IKNH0kTRaiVfq6N8Ovp5zANBgkqhkiG9w0BAQsFAAOCAQEAhpbntg+nwhIKgRuUidu/wXn197Ah0Pd4CYYxG5dR9rg8nWObx4QO6ApIH91nUUQVuV6mSTFtfy4yNQzxaROgZP9hDNvhd78D/ewXxp6bN/Xkn+c7SWrs/b1vHb2Dr1sDP4F9SAOrCI6TdoYa8UNhPXXSTt8M/hGSB2oWOpT2FAb2IbdmdYhDaibcJwp+/Had1FLbeDZgdgYCFoZLjws/9E/pIXjSxBYAJLbaQZffrfO5jCe2KesE73iQatW2IPynsFifRGGoMHXVLOfsLA9c2KDGqDmnJ+PvsBSe9rIpSJYC4WjR5Mt8W88kQSj05b9NqCsXmmMDEbD8uVLyKvQihA==—–END CUSTOMER KEY—–

view raw

Company-Name-customer-key.txt

hosted with ❤ by GitHub

All the needed components with the exception of the CustomerKey file, which is different for each customer, ship on a disk image.

NexThink’s install documentation for the macOS version of the Collector software assumes that a human is doing one of the following:

Graphical installation: Mounting the disk image, double-clicking on the installer package and following the prompts, entering the correct configuration information were needed.

 

Command line installation: Mounting the disk image, opening the Terminal application and using the csi app’s command line tool to configure the installer package and run the installation process.

 

 

For the Enterprise Deployment section of the application, the NexThink documentation says they support it but doesn’t provide information on how to do it.

In my case, I decided to do the following to deploy it via Jamf Pro:

1. Wrap the disk image and CustomerKey file inside a separate installer package.
2. Use a postinstall script to perform the following actions:

A. Identify the location of the disk image stored inside the installer package.
B. Mount the disk image
C. Identify the location of the csi.app on the mounted disk image.
D. Identify the location of the CustomerKey file stored inside the installer package.
E. Use the csi app’s command line tool to configure and run the NexThink-provided installer package on the mounted disk image, to install the NexThink Collector software.
F. Unmount the disk image.

For more details, please see below the jump.

Session videos from Jamf Nation User Conference 2022 now available

Jamf has posted the session videos for Jamf Nation User Conference 2022, including the video for my Running Jamf Pro at Scale, from SAP with ❤️ session.

For those interested, all of the the JNUC 2022 session videos are available on YouTube. For convenience, I’ve linked my session here.

Using the Jamf Pro API to report on Self Service policies

Every so often, it may be necessary to generate a report from Jamf Pro of which policies are available in Self Service. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the policy records and generate a report in .tsv format.

For more details, please see below the jump.

Building Jamf Pro smart groups for Ventura-compatible and Ventura-incompatible Mac models

As part of preparing for macOS Ventura, it may be useful to have a way to easily distinguish between the Macs in your fleet which can run macOS Ventura and those which can’t. Apple has published the following list of Macs which are compatible with Ventura, which will help with both identitying the compatible Mac models as well as the incompatible Mac models.

• iMac: 2017 and later models
• iMac Pro: All models
• MacBook: 2017 and later models
• MacBook Pro: 2017 and later models
• MacBook Air: 2018 and later models
• Mac Mini: 2018 or later models
• Mac Pro: 2019 or later models
• Mac Studio: All models

From there, here’s the list of Mac models which are compatible with macOS Ventura:

	Mac13,1
	Mac13,2
	Mac14,2
	Mac14,7
	MacBook10,1
	MacBookAir10,1
	MacBookAir8,1
	MacBookAir8,2
	MacBookAir9,1
	MacBookPro14,1
	MacBookPro14,2
	MacBookPro14,3
	MacBookPro15,1
	MacBookPro15,2
	MacBookPro15,3
	MacBookPro15,4
	MacBookPro16,1
	MacBookPro16,2
	MacBookPro16,3
	MacBookPro16,4
	MacBookPro17,1
	MacBookPro18,1
	MacBookPro18,2
	MacBookPro18,3
	MacBookPro18,4
	MacPro7,1
	Macmini8,1
	Macmini9,1
	VirtualMac2,1
	iMac18,1
	iMac18,2
	iMac18,3
	iMac19,1
	iMac19,2
	iMac20,1
	iMac20,2
	iMac21,1
	iMac21,2
	iMacPro1,1
	iSim1,1

view raw

ventura_compatible_models.txt

hosted with ❤ by GitHub

We can use this information to build smart groups which can help identify which Macs are compatible with Ventura and which are not. For more details, see below the jump:

Running Jamf Pro inventory updates at startup time using a Jamf Pro policy

As a follow-up to my previous post on running Jamf Pro inventory updates at startup, several folks have asked if the approach I showed was better or more efficient than using a Jamf Pro policy to run the inventory update. I thought about it and I can’t say for certain if the LaunchDaemon-driven approach I described is better than using a Jamf Pro policy.

The advantage of the LaunchDaemon-driven approach has is that the Mac admin has control of the options being used. In my example solution’s case, I have jamf checkJSSConnection checking for up to 60 seconds before giving up. Depending on your network setup, it may take that long before your Mac can verify it can talk to the Jamf Pro server.

If you’re running an inventory update via a Jamf policy’s startup trigger, you’re using whatever configuration Jamf has chosen for making sure the policy is triggered when you want it to be. Jamf’s choices may be the right ones, but those choices are being made by Jamf and not the individual Mac admin.

That said, collecting and submitting inventory updates to Jamf Pro is a problem which can be solved multiple ways and what I presented in my previous blog post was a solution, but not the only solution. With that in mind, please see below the jump for details on how to solve the problem of collecting and submitting inventory updates at startup using a Jamf Pro policy.

Running Jamf Pro inventory updates at startup time

With the release of macOS Ventura expected this month, an important topic to many Mac admins is having their systems management tools detect as quickly as possible which of their Macs have upgraded to macOS Ventura. The reasons for this are varied, but one particular reason is to get configuration profiles deployed as soon as possible to manage new features and functionality in macOS Ventura.

One way to ensure quick detection if you’re using Jamf Pro is to have your managed Macs submit an inventory update to the Jamf Pro server when the Mac starts up. For one way to do this, please see below the jump.