Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Managing Configuration Profiles
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: https://github.com/timsutton/make-profile-pkg
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
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.
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:
Is the profile's identifier in the output of
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 -Cto 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.
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.
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.
ProfileInstallDatefrom the profile's receipt match the
In the event that these dates differ, even thought the identifier and hash match, Munki will install the profile.