One of the capabilities of mobile device management (MDM) on macOS is that you can use MDM commands to deploy installer packages, via the InstallEnterpriseApplication MDM command. If you’re using Jamf Pro for your MDM management, one of the capabilities of the Jamf Pro API is being able to leverage its ability to run MDM commands to send out InstallEnterpriseApplication commands to deploy installer packages. For more details, please see below the jump.

The relevant Jamf Pro API endpoint is the v1/deploy-package endpoint. Here are the required API permissions for using it:

API permissions using user account authentication:

Jamf Pro Server Objects:

• Computers: Read, Update

Jamf Pro Server Actions:

• Send Computer Remote Command to Install Package
• Send MDM command information in Jamf Pro API
• View MDM command information in Jamf Pro API

API permissions using API client authentication:

• Read Computers
• Update Computers
• Send Computer Remote Command to Install Package
• Send MDM command information in Jamf Pro API
• View MDM command information in Jamf Pro API

Installer packages deployed using this method would need to be signed and built as a distribution-style package. I have a blog post describing the details available via the link below:

https://derflounder.wordpress.com/2023/10/24/preparing-installer-packages-for-installation-using-mdm-commands/

If you look at the Jamf Pro API documentation available with Jamf Pro, using the v1/deploy-package Jamf Pro API endpoint to successfully deploy a package requires sending a JSON block containing a manifest for the package along with some additional information on whether or not the package is set to be managed and which devices to install it on. Let’s take a look at the essential components of this block, using an example provided as part of the Jamf API documentation:

This has several parts, so let’s break it down by section:

Manifest:

This is providing the MDM command’s information about the package to be installed. Here are the essential parts you need to provide as part of the manifest:

• URL: The installer package will need to be hosted on an available location which allows anonymous HTTPS downloads (i.e. downloading via HTTPS without requiring authentication.)
• Hash: This is a unique, fixed-length string generated by running an file’s data (in this case an installer package) through a cryptographic algorithm like MD5 or SHA256.
• Hash Type: This is the cryptographic algorithm being used. Either MD5 or SHA256 is supported.

Note: The hash type description must use capitalization. No lowercase letters allowed in this use case.

• Bundle ID: For an installer package, this is the unique, reverse-DNS identifier (for example, com.example.app) used to identify macOS installer packages.
• Bundle Version: For an installer package, this is the version of the installer package. Packages with the same package identifier are compared using this version, to determine if the package is an upgrade or downgrade.
• Title: This is the title of the package being installed
• Size in Bytes: This is the size in bytes of the installer package.

For more information on the topic of creating a manifest for installer packages deployed using the InstallEnterpriseApplication MDM command, please see the link below:

https://www.dersoldat.org/?p=1456

Next, there’s the choice to install as managed or not:

The installAsManaged configuration option defines if the installer package is defined as installing a managed app or not installing a managed app. For the most part, this defines whether or not the MDM would be able to uninstall the app following installation using the InstallEnterpriseApplication MDM command.

The default configuration for the InstallAsManaged configuration option is false, so unless you know you will need to define it as true, this configuration option does not need to be included as part of the API call.

For Mac admins, here are the considerations to keep in mind for this option:

installAsManaged = true:

• The MDM server can install, track and remove the app installed by the installer package.

installAsManaged = false:

• The MDM server is only deploying the installer package and does not track anything afterwards.

Of course, if you’re choosing to deploy an installer package, you need to define what devices you’re installing it on. That’s the next two parts of the configuration:

This allows you to define the individual Jamf Pro ID numbers of the devices you want to install on.

This allows you to define the device static or smart group containing the devices you want to deploy the installer package to.

Here’s an example API command to install a package named MyGreatInstaller.pkg as unmanaged from an S3 bucket named 75d831079efb4d02ada44eed4f8ae093 on individual devices with Jamf Pro device IDs 102, 103 and 104:

In this example, the JSON block being sent looks like this:

Here’s an example API command to install a package named MyGreatInstaller.pkg as unmanaged from an S3 bucket named 75d831079efb4d02ada44eed4f8ae093 on all devices in a Jamf Pro device group with Jamf Pro ID 37:

In this example, the JSON block being sent looks like this:

Once the API command is sent, there are two possible HTTP status codes which indicate the API command ran successfully:

• HTTP 200
• Meaning: Package deployment MDM command was successfully processed.

• HTTP 202
• Meaning: Package deployment MDM command was queued up for processing.

Here’s an example of a successful API response from an installer package deployment to a device with the Jamf Pro ID of 67: