How To: Using Static Groups to Install Software Via Munki

[raymondap]

In a Feature Request discussion, @shane.young asked me for details on how we integrate Munki with Casper Suite. In our organization, we use static groups in Casper Suite to assign licensed applications to computers, but use Munki to do the actual install. Here's how I've set that up. This is thrown together from internal documentation that I've removed any of our organization's specific information from, so hopefully I didn't miss something or leave something out.

I make no claims that this will work for you as well as it does for us, that this is the best way to approach this, or that it is even a good idea to go down this path.

Client Configuration
On each client you will need to create an "allowed_apps" folder in /usr/local/munki. You will also need to create a custom conditions script in munki's conditions folder (/usr/local/munki/conditions) and set it as executable. See Munki documentation for more info in custom conditions. The script we use is below:

#!/bin/bash
# jss_allowed_apps
# Adam Raymond
# State of Maine Judicial Branch
# Conditional item check for applications allowed by JSS groups

managedinstalldir="$(defaults read /Library/Preferences/ManagedInstalls ManagedInstallDir)"
plist_loc="$managedinstalldir/ConditionalItems"
IFS=$'
' 

# Build array of "tickets" in allowed_apps
for item in `ls /usr/local/munki/allowed_apps/`; do
    allowed_apps+=( $item )
done

# Write to plist
defaults write "$plist_loc" "JSSAllowedApps" -array "${allowed_apps[@]}"

# Convert plist to xml so munki can read it
plutil -convert xml1 "$plist_loc".plist
exit 0

I also recommend adding "jamf policy" to Munki's preflight and "jamf recon" to munki's postflight. See Munki documentation for more info.

The easiest way to get these changes out to all clients is to package them up and distribute them via Munki.

Software Package
For each application, a software package is created and uploaded to Munki. A package can be created using vendor tools, Packages.app, Casper Composer, or some other method. This will vary depending on the software. It's important to include any license/serial if at all possible.

Munki Repository Configuration
For each package, a custom condition needs to be created for each catalog it exists in. The condition should look like this:

JSSAllowedApps CONTAINS "Office2016"

Once done, and the package has the proper pkginfo information, it can be added to any catalogs. Typically, you'd want to add it to the Installs section. Be sure to set the Conditions to the condition you created, otherwise, you could push to everyone! TEST TEST TEST! See Munki's documentation on custom conditions for more info.

JSS Configuration
Several items need to be configured in the JSS

Groups
For each application, one static group, and two smart groups must exist.
- A static group that contains all computers that need the application. You'll need to make sure that all existing computers that have this application are added to the group (if there are any) or the application will be removed! Name this for the application. Example: FileMaker12
- A smart group that contains all computers that are members of the static group and DO NOT have the application currently installed. The application will be installed on these computers. Name this appropriately. Example: [MUNKI]FileMaker12: Pending Install
- A smart group that contains all computers that are NOT members of the group and DO have the application. The application will be removed from these computers. Name this appropriately. Example: [MUNKI]FileMaker12: Pending Removal

Scripts
Two scripts are needed. One to allow for the install by adding an allowed_app ticket, and the other to handle removals. Place these under the Licensed Software Distribution category. The name of the file you touch/remove in the scripts MUST match EXACTLY the custom condition you created in Munki.
The install script just needs to touch a file in the appropriate folder that Munki looks at. An example is below.

#!/bin/bash
touch /usr/local/munki/allowed_apps/FileMaker12
exit 0

Name this script appropriately. Example: [MUNKI]FileMaker12: Allow

The removal script needs to remove the allowed_app ticket as well as uninstall the application itself. Uninstalling is a simple process for some apps, but others, like Office require a more advanced script. You could choose to instead let Munki handle the removal, but it's easier to just let the JSS handle it. A simple example is below:

#!/bin/bash
rm -Rf "/Applications/FileMaker Pro 12"
pkgutil --forget com.filemaker.ardwrapper.FileMakerPro12.pkg
/usr/local/bin/dockutil --remove "FileMaker Pro" --allhomes
rm /usr/local/munki/allowed_apps/FileMaker12
exit 0

Name this script appropriately. Example: [MUNKI]FileMaker12: Remove

Policies
Two policies need to be created. One to allow the install, and one to do the removal. Place these under the Licensed Software Distribution category.
- Both policies should be set to Ongoing at Check-in.
- The removal policy should have the Maintenance option to Update Inventory checked.
- For the allow install policy, the Scope should be the Pending Install smart group you created. Add the appropriate allow install script. Name appropriately. Example: [MUNKI]FileMaker12: Allow
- For the removal policy, the Scope should be the Pending Removal smart group you created. Add the appropriate removal script. Name appropriately. Example: [MUNKI]FileMaker12: Remove

Putting it all together
Here is what happens on the client once you add them to the group.
When Munki is run, either manually or through Managed Software Center, the preflight script does a jamf policy run to check for any policies, including any application installs or removal.
If an application is marked Pending Install, the policy runs the script, and creates the file (aka the allowed_app ticket) in /usr/local/munki/allowed_apps/

If an application is marked for removal, the ticket is removed, and the application itself is uninstalled.
Once the Munki preflight is completed, Munki then runs the jss_allowed_apps script in /usr/local/munki/conditions. This script looks at the contents of /usr/local/munki/allowed_apps, generates an array, adds it to the ConditionalItems.plist that Munki looks at when processing catalogs.

Munki then processes catalogs for available software. If an item in ConditionalItems matches a catalog item with the appropriate condition set, it is marked for install.
When Munki is done its run, a jamf recon checkin is performed as part of the postflight script. At this point, the computer is removed from the Pending Installs (or Pending Removal) smart group to reflect any changes to installed applications.

[shane_young]

Thanks. This will be useful and we can build off of this.