Managing Configuration Profiles

Greg Neagle edited this page Feb 8, 2019 · 7 revisions

Using Munki to manage configuration profiles


Since version 2.2, Munki offers "native" support for configuration profiles. Instead of having to wrap a configuration profile in a package to be able to deploy with Munki, Munki supports configuration profiles as an item it knows how to install and remove without "wrapping".


Munki manages system-level configuration profiles, as it runs as root. Enrollment profiles, for configuring the computer to be managed by an MDM server, are not supported.
For configuration profiles not supported by Munki, consider wrapping them in a package with this tool:


Use munkiimport /path/to/some.mobileconfig to import a .mobileconfig file into your Munki repo. Like a package, munkiimport will create a pkginfo file, add it to your pkginfo directory, and import the .mobileconfig file into the pkgs directory.

Configuration profiles should use the pkginfo key installer_type with value profile to specify that Munki should use the /usr/bin/profiles command to install the profile. Likewise, an uninstall_method of remove_profile specifies that Munki should use profiles to remove the profile as well.

Upon installing a configuration profile, Munki writes a receipt to the client's Managed Installs directory. Note, this is not the same as the OS X installer package receipts database. When removing a profile, Munki will remove this receipt.

The profiles command will replace an existing profile with a new profile if the profiles share an identifier. Therefore, the profile's identifier value is used for determining identity. The UUID is not considered.

You can treat a profile item in manifests as you would any other piece of software -- you can add it to managed_installs, managed_uninstalls, optional_installs, etc.

Deploying an update to an existing profile

If you need to update a profile, be sure to keep the identifier the same and bump the version number in the pkginfo. Do not attempt to use the PayloadVersion key inside the profile itself to track your internal version info -- that refers to the version of the configuration profile format -- which to date, is always 1.

How Munki Determines if a Profile Should be Installed

When examining whether to install a profile, Munki considers several conditions. If any of these conditions are false, Munki will try to install the profile.

Munki considers the following conditions, in this order:

  1. Is the profile's identifier in the output of profiles -C?

    Every profile has an identifier, with a recommended value of a reverse-domain name uniquely identifying the profile. (e.g. com.myorganization.SoftwareUpdateSettings). Munki will compare the profile it is considering installing with the results of profiles -C to see if there is a match. For this reason, updates to an existing profile must use the same identifier (but a different version) to be considered for installation.

  2. Is there a receipt for this profile identifier?

    Even if a profile has been manually installed, without a profile receipt, Munki will install the profile.

  3. Does the hash of this profile match the receipt's hash_value match?

    The hash value is generated by feeding the .mobileconfig file through a sha256 hashing algorithm. The hash is not based on the identifier, nor the UUID.

  4. Does the ProfileInstallDate from the profile's receipt match the ProfileInstallDate specified by profiles -C?

    In the event that these dates differ, even thought the identifier and hash match, Munki will install the profile.

Related links

Preference Management with Profiles - Penn State MacAdmins 2016


Munki 3

Managed Software Center

Command-line Tools

Munki configuration




Advanced Munki

Related tasks


Product-specific notes

Legacy Documentation

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.