Payloads available for use in a Policy include:
Packages
A package is a Mac OS-style .pkg or Composer-created .dmg file that installs applications, settings, or plain files to the computer. For commercial software, such as Microsoft Office or Adobe Creative Cloud, you can use the vendor-supplied .pkg installer directly here. For other software, especially those that are distributed as a .app file packaged into a .dmg, you will need to use Composer to capture the drag-and-drop installation, along with any other configuration, or create a payload-free package for this. (These techniques will be discussed in another post.)
JAMF allows you install packages directly in a Policy, or to direct the Mac to cache the package for installation later. Cached packages are useful for an organization-wide rollout where all computers need to install a package at the same time, but where the network bandwidth is not sufficient to distribute the package to all of them at once, and other such situations. For Composer-created .dmg packages that have been indexed in Casper Admin, you can also direct the policy to uninstall the package. Unfortunately, no such capability exists for .pkg installers directly, but commercial software often supplies an uninstall.pkg that can be used instead.
The Policy can also specify which distribution point (file share-based or deprecated software-based Jamf Distribution Server) from which the computer should download the package. In our environment, we have packages always downloaded from the local DP, but if for some reason a specific DP is preferred for this package - faster network link, etc. - that can be specified in the payload.
Software Updates
A Policy can direct the client Mac to install available software updates from either its default software update server, or from Apple's update servers directly. Mac OS Server provides the ability for administrators to select which updates will or will not be installed by clients, and caches those updates on the server to save traffic to and from Apple's servers.
We do not currently use this payload. While Mac OS Server allows you to control updates, it does not appear to have a way to specify where those updates should come from; if you manage updates through Mac OS Server, you must cache them on the server itself, which in our case is a several-year-old 500GB Mac Mini, so this is impractical when those Minis must also hold OS images and all other packages for the local campus. To that end, I created a custom update management system for our environment using Python, which I will discuss in another post.
Scripts
A Policy can also run any arbitrary shell or Python script, which allows most anything to be done with the client Mac. The Policy allows you to pass parameters to the script with a handy form-based interface, allowing one script to be used in multiple policies for different effects. Parameters 1 through 3 are pre-defined by JAMF, mount point, computer name, and user name respectively, while parameters 4 through 11 are available for your use.
One simple use of this in our environment is to replicate file share distribution points. We found that replicating DPs using Casper Admin works well enough to copy the files themselves, but tends not to set the correct permissions on the shared directory, requiring a manual chmod. Therefore, I created a script to manually mount and rsync the central distribution point to each local Mac Mini, which via Policy runs each night after a certain time. Our update management system is similarly implemented by a script that runs overnight on client Macs.
Printers
Mac OS printer definitions are simply URLs that indicate to which print server the computer should send jobs. A Policy can specify which printer is to be mapped or un-mapped on the Mac, as well as whether it should be set as default. Multiple printers can be mapped or unmapped at once, or any arbitrary combination of mappings/unmappings as well. (This would be useful if a printer's name changed, for example.)
Unfortunately, since printers on Mac OS are just URLs, the Printers payload does not allow you to directly install a driver if one is needed. For most models, Mac OS includes a driver that works well enough, but we have some very old HP printers that are no longer included. However, this is not such an issue, as you can have the Policy first install the driver .pkg, then map the printer.
Disk Encryption
A Policy can be used to control FileVault 2 disk encryption. You can choose to apply a Disk Encryption Configuration (a special kind of configuration profile that specifies the type of Recovery Key and FV2-enabled users), or to issue a new recovery key. You can also specify when FileVault 2 will be required to be enforced: the default is on the next login, but options are also available to allow up to six more logins before requiring encryption to be enabled. This would be useful in a situation where IT would set up a laptop, needing, say, four logins, and deliver it to the user, who on their first login would be prompted to set a FV2 password. Recovery keys are automatically synchronized with JAMF, so even if the user forgets their password, a JAMF administrator can unlock their device.
Dock Items
A Policy can add or remove application icons from the Dock for all users on a Mac. Dock items are specified by a name and a file:// URL pointing to their location, and can be added to the beginning (by the Finder) or end (by the Trash) of the Dock, or removed entirely.
Local Accounts
The Local Accounts payload, as its name indicates, allows you to work with local user accounts on a Mac via Policy. Four main operations are available: create a new account, reset an account's password, delete an account, or disable the account for FileVault 2.
Creating an account via Policy looks much like it does on a Mac in the System Preferences Accounts panel. You specify a username, the user's full name, a password (with verification), and a password hint. You can also choose the path for the user's home directory - for hidden accounts, you can choose to create the account in /private/var/username rather than /Users/username, for example - and the path to the user's account picture, which can be anywhere on the hard drive. You can choose to allow the new account to have administrator rights, and whether it should be enabled for FileVault 2.
Resetting an account password prompts for the username and new password. The old password is not required. It is important to note that this does not also update the user's FileVault 2 password, so that will need to be changed elsewhere.
Deleting an account asks for the username, as well as whether to permanently delete the home directory, or just to remove the account record. If you desire, you can also specify a location to which the account's home directory could be backed up. (This does not necessarily have to be on the local Mac! You could mount a network folder using a script, set to run before the Local Accounts payload, and then archive the directory there, ensuring that IT will have a backup of the user's data in case they need it.)
Disabling a user for FileVault 2 only requires the username. Once the Policy runs, the user will not be able to unlock the computer's FileVault 2 encryption, change its password, or otherwise work with FV2.
Management Account
The Management Account payload exposes the way that JAMF actually works, and allows you to manage the account it uses. JAMF actually performs most of its functions by SSHing into client Macs using a special management account, usually named jamfadmin, which has administrator rights. You can specify a known password for this account using the Management Account payload, or, as we have in our environment, ask JAMF to generate and store a random password for this account on each computer.
We have a Policy set up that changes the management password to random value for each Mac every day, ensuring that nobody knows one password that will allow effectively untraceable administrator access to every computer. Instead, we have a different admin account with a set password, managed as a Local Account using the payload previously described, so that if the password is leaked we can change that without needing to do anything with the special Management account.
The Management Account payload also allows you to enable or disable the management user in FileVault 2, which could be used to ensure that IT can always unlock a Mac even if the user forgets their password, but in our environment, this is not useful, and the key is recoverable through JAMF anyway.
Directory Binding
A Policy can enforce an Active Directory binding, specified in the JAMF management pages, that joins the Mac to AD using specific credentials, and can automatically put it in the correct OU. We use this with a custom trigger to allow us to easily un-bind and re-bind Macs to AD in our various campuses in the event that the binding is broken, in cases such as laptops that do not see the domain for an extended period of time.
EFI Password
You can use a Policy to set or remove the Open Firmware/EFI password on a Mac. In our environment, as many different users log in to many Macs in the course of a semester, we do not currently use this payload.
Restart Options
If anything in the Policy would require the computer to restart, you can use the Restart Options payload to specify how you would like that to happen. You can choose what action the computer should take if there are no users logged in, what it should do if there are users logged in, and how long (in minutes) it should wait before restarting.
This payload also allows you to do some useful things. You can choose to perform an authenticated restart, which allows the computer to fully reboot without requiring a user to enter the FileVault 2 password if one is set. You can also specify which disk the Mac should boot from - the default hard drive/partition, another hard drive/partition, or even a NetBoot or macOS installer image. The latter two options are useful in a lab environment where all Macs will be imaged at the same time, as it saves the tech the steps of shutting each one down, then booting them up while holding the N or Option key.
Maintenance
The Maintenance payload has a few options that can be used to ensure that Macs remain healthy, including Fix Disk Permissions (though this only works with Mac OS <= 10.11), Flush System/User Caches (including the Microsoft Office font caches), and Verify Startup Disk. However, if the Mac is in enough trouble to need these to be run, it may be doubtful whether it will actually be in a good enough state to run them via JAMF.
Two JAMF-specific options allow you to instruct the Mac to submit updated inventory information to the JSS (after software is installed, accounts are created, etc.), and to reset the local computer name to the name entered in JAMF, if for some reason a user had enough rights to change it.
Files and Processes
The Files and Processes payload allows you to perform a few routine tasks that would otherwise require the creation of a script to do, such as finding and deleting a file by path or filename, finding and deleting a process by name, or executing an arbitrary shell one-liner. For example, if you just wanted to use a policy to force a Mac to reset its time from a network time server, it would probably be easier to enter the command in the Execute Command field of the Files and Processes payload, rather than creating a whole script just for that.
Whereas Payloads are the effects that a Policy has, Triggers are the conditions that specify when it should be run. There are several available triggers, which mostly are what they sound like:
- Startup - the policy will run when the computer starts. This means that payloads that require a user to be logged on will not work correctly with this trigger.
- Login - the policy will run when a user logs in.
- Logout - the policy will run when a user logs out.
- Network State Change - the policy will run when anything happens that might impair JAMF's ability to communicate with the Mac, including switching interfaces (Ethernet to WiFi), changing of its hostname, or changing of its IP address.
- Enrollment Complete - the policy will run after the Mac finishes being enrolled in JAMF, or when reimaging is completed. This is useful for provisioning required software and other changes to new or freshly-imaged devices.
- Recurring Check-in - the policy will run at the frequency set for computers to check in with JAMF. By default, this is every 15 minutes, but it can be as short as every 5 minutes, or as long as every 60 minutes.
- Custom - You can define a custom trigger for a Policy to allow you to run it from Terminal on a Mac to create custom commands. For example, we have a custom trigger on our AD binding policies, one per campus, that all use the custom trigger "bindAD". To bind a Mac to AD, and to have it automatically drop into the correct OU, I can do sudo jamf policy -trigger bindAD without caring which campus the Mac belongs to.
In addition to these triggers, you can specify the Execution Frequency for the Policy, determining whether it will run once per computer, once per user (system-wide), once per user per computer, once a day, once a week, once a month, or ongoing. An execution frequency of Ongoing is useful with custom triggers, as well as with Recurring Check-in triggers for actions that need to happen every 15 or so minutes.
In case that's not granular enough, Policies also have two different levels of date/time filtering, allowing you to decide down to the minute when a Policy should or should not run. You can specify server-side limitations, outside of which clients will not see the Policy, as well as client-side limitations, which specify a range of times and dates that clients may see the Policy, but will not execute it. You could use this, for example, to have all Macs check for and install available updates on Monday, Wednesday, and Friday, but only between 10pm and 6am to ensure nobody is using them.
Using the above triggers, Policies can be set to run automatically, but this is not required. Policies can also be set to be available from the Self Service application that JAMF installs on client Macs. By making application-deployment Policies available in Self Service, an organization can set up its own App Store-like repository, from which users can install applications and other Policies as they need them.
For a Policy to be available to a Mac, either automatically via trigger or in the Self Service application, the Mac must be part of the Policy's Scope. A Scope is much like a Collection in SCCM; Macs can be added individually by name, or by Smart or Static Computer Group. Similarly, you can choose which users may or may not run Policies, and even combine the two to specify that a Policy should only run on certain machines for certain users.
Finally, using the User Interaction tab of the Policy editor, you can specify a message that should be displayed when the Policy runs, one that should be displayed when the Policy finishes, and one that should be displayed if the computer needs to be restarted. You can also choose to allow the user to defer the Policy until a certain date and time, after which it will run regardless of their deferment.
This concludes my exploration of Policies in JAMF. As you can see, they are the main powerhouse of the JAMF system. Next, I'll take a look at Configuration Profiles, the MDM-esque management technology provided by newer versions of Mac OS.