Jamf Pro Deployment

Deploying super via Jamf Pro requires only a single Policy but in most cases you probably also need to deploy super related MDM configuration profiles. Similar to the workflow for most management tools, you should deploy any super related MDM configuration profiles before running the Jamf Pro Policy that installs super.

Jamf Pro Configuration Profile

While many of the super options can be deployed via either a command option or MDM configuration profile, several features of super can only be deployed via MDM configuration profile. Also don't forget that multiple payloads can be deployed via a single combined super MDM configuration profile.

In addition to the configuration payloads listed on this page, you should also consider deploying configuration payloads to manage the built-in Apple software update service.

Profile Payload For super Options

If there are specific super options you plan to set "permanently" then you should consider deploying these settings via a MDM configuration profile. In addition to over-the-air deployment, using a MDM configuration profile also allows you to enforce your options. In other words, if a specific super option is deployed via a MDM configuration profile then it cannot be ignored or changed via local command options.

The MDM configuration profile specification allows for custom settings deployed via application specific preference domains. In the case of super, the preference domain is com.macjutsu.super. Throughout this Wiki you'll find configuration profile example text detailing the option-specific XML formated keys to be used in the super MDM configuration profile.

The super repository contains a variety of MDM configuration profile example files:

• Jamf Pro ID only example as a .plist
• Jamf Pro ID only example as a .mobileconfig
• All options example as a .plist
• All options example as a .mobileconfig

DO NOT DEPLOY the "all options" examples as is. It is for example only and contains conflicting example settings that generate errors if deployed as is. Before deploying you should evaluate all example settings for your specific environment by removing any setting that is not required and auditing any remaining settings for appropriateness.

The ".plist" examples need to be inserted into a new MDM configuration profile payload, whereas the ".mobileconfig" examples are already complete. Consult with the Jamf Pro documentation for details regarding importing custom configuration profile settings.

Profile Payload For The Jamf Pro API Service Account

To harden the security profile of the Jamf Pro API service account you can avoid using the "Computers Read" privilege by deploying a MDM configuration profile payload that contains the computer's Jamf Pro ID.

As you can see, the Jamf Pro ID setting JSSID is part of the same com.macjutsu.super preference domain used for all other managed super settings. Obviously this setting can ride along with the rest of the super settings the same configuration payload.

Profile Payload For Creating a super Service Account

If you want super to create a local service account via Jamf Pro you must also deploy a Privacy Preferences Policy Control (PPPC) configuration payload. Specifically, you must allow the "SystemPolicySysAdminFiles" privilege for the /usr/local/jamf/bin/jamf and com.jamf.management.Jamf application identifiers.

Again, the super repository contains a complete example MDM Configuration Profile to allow Jamf Pro to create the super service account. After the creation of the local super service account on the system, you can remove this configuration payload.

Jamf Pro Policy

The Jamf Pro Policy to deploy super only needs the script as-is but you should also consider populating the Script Parameters. Specifically, any Apple silicon update credentials must be passed in via the Policy Script Parameters.

You can only pass in one super option per Policy Script Parameter. Thus, if you want to deploy more than eight super options you must also deploy a MDM configuration profile as documented previously on this page.

Jamf Pro Deployment Best Practices

Here are a few tips to get the most of super when deploying via Jamf Pro:

• When deployed via Policy, super always (re)installs itself. So to update super itself to a new version simply make your super Policy run again with an updated version of the script.

• Avoid adding an inventory collection to your super Policy if you have also enabled the "Collect available software updates" option in the Jamf Pro inventory collection settings. This is to prevent an issue where the softwareupdate process hangs when multiple processes (the jamf binary and super) are simultaneously asking for a list of updates.

• The default super workflow automatically relaunches itself. However, if you desire greater control over how often super relaunches itself you can have a Jamf Pro Policy relaunch super as well.

• The correct number of settings in a super configuration profile is the least required for your organization. For example, it's unnecessary to add any "false" settings because that is already the default for any true/false option.

• If you make changes to super settings via configuration profile, consider also using the --reset-super option in Policy Script Parameters to clear any locally cached super options that may cause conflicts.

• The Super-Friends folder contains a variety of Jamf Pro inventory Extension Attribute scripts you may find useful in your super deployment workflows.