Policies allow you to remotely perform common management tasks on managed computers. For example, you can run scripts, manage accounts, and distribute software using a policy.
Policies allow you to automate these tasks so that they run at a specified frequency. When you create a policy, you specify the tasks you want to automate, when the policy should run (called “trigger”), how often it should run (called “execution frequency”), and the users and computers for which it should run (called “scope”).
You can also make policies available in Self Service for users to run on their computers as needed.
A policy can be run at one of the following frequencies:
Once per computer—This policy runs on any computer in the current scope one time only. If a log entry exists for a computer in the policy’s history, the policy will not run for that computer until it is flushed.
Once per user per computer—This policy runs once per distinct username per distinct computer. It runs through Self Service as long as Self Service has user logins enabled.
Once per user—This policy runs only once per distinct username. It runs through Self Service as long as Self Service has user logins enabled. The policy will only run once per username in the scope, not once per username per computer.
Once every day—This policy runs if the scoped computer has not submitted a policy log to Jamf Pro in the past day (24 hours).
Once every week—This policy runs if the scoped computer has not submitted a policy log to Jamf Pro in the past seven days (168 hours).
Once every month—This policy runs if the scoped computer has not submitted a policy log to Jamf Pro in the past 30 days (720 hours).
Ongoing—This policy runs each time the specified trigger takes place.
Important: When using an ongoing execution frequency with a recurring check-in trigger, policies will run during every check-in. This may negatively impact server and client performance.
Triggers are events that initiate a policy. When you create a policy, you can choose one or more pre-defined triggers, or you can choose a custom trigger.
You can use the following pre-defined triggers to run a policy:
Startup—When a computer starts up. The startup script must be enabled within the Check-In section of Computer Management Settings
Login—When a user logs in to a computer. Login hooks must be enabled within the Check-In section of Computer Management Settings
Logout—When a user logs out of a computer. Logout hooks must be enabled within the Check-In section of Computer Management Settings
Network State Change—When a computer’s network state changes (for example, when the network connection changes, when the computer name changes, when the IP address changes)
Enrollment Complete—Immediately after a computer completes the enrollment process
Recurring Check-in—At the recurring check-in frequency configured in Jamf Pro
Note: On computers with macOS 10.15 or later, Jamf Pro must be whitelisted in the Privacy Preferences Policy Control payload to run policies that access data on a network volume at recurring check-in. By default, Jamf Pro is automatically whitelisted in the Privacy Preferences Policy Control payload.
Custom—Initiate the policy manually using the jamf policy -event binary command. For an iBeacon region change event, use beaconStateChange
Policy Execution Order
If multiple policies are triggered at the same time, the policies will run based on their name in alphanumeric order. Policies with names beginning with a number will run before policies that do not.
Policies can be renamed to ensure that they run on a device in a specific order. This is useful in situations when an application needs to be uninstalled before installing a newer version. The uninstall policy can be renamed in order to ensure that it runs prior to the install policy.
For example, if policies “Alpha” and “Beta” are triggered at the same time, “Alpha” will run first. However, if it would be preferable for “Beta” to run first, "Beta" should be renamed to “1Beta”.