Policies are powerful management tasks used to deploy software, manage user accounts,
provide security, remotely run scripts, and much, much more.
Policies rely on the management framework installed during enrollment and, unlike configuration
profiles, do not require Apple's Push Notification service to deploy.
My name is Kyle - welcome to our policy overview video.
Let's begin by navigating to the Computers tab and selecting policies on the sidebar.
In a fresh Jamf Pro installation, one policy is configured by default: Update Inventory.
This policy serves as the means for computers to submit inventory to Jamf Pro.
Unlike mobile devices, whose inventory collection frequency is configured in Settings, computers
submit inventory through policies.
For more information on computer inventory, check out our video Computer Inventory and
Remote Commands.
Before we take a look at this policy’s configurable options, we have some information available
at a glance.
There are four key components required by every happy policy:
The "What": what's the content of this policy?
What are we trying to accomplish?
By clicking the disclosure triangle to the left of the policy, we can see this runs an
Update Inventory command.
The "When": when will this policy execute?
This is our trigger.
If we make a policy available in Self Service, a trigger is not required.
Policies may also have multiple triggers.
We’ll take a look at our available triggers in a minute.
This policy triggers at check-in.
The "How often": how often should this policy trigger?
In other words, what is the execution frequency?
In this case, the policy triggers once a week.
If a computer checks in with our server and the policy has already run this week, it will
not run again until 7 days have passed.
The "Who": who is the policy intended for?
This is our scope.
This policy is currently scoped to all computers managed by Jamf Pro.
Let’s select this policy to explore our available options.
Clicking the edit button in the bottom right will allow us to make changes.
Here we have the display name and an Enabled checkbox.
Deselecting this box will disable the policy, meaning it will not deploy to computers until
it's enabled again.
This is helpful if you'd like to configure the policy ahead of time before it's scheduled
to deploy.
This policy is configured a trigger at recurring check-in.
Check-in is facilitated by something called the Jamf Binary, which is installed as part
of the management framework.
Our other options are startup, login, logout, network state change, enrollment complete,
or a custom trigger.
If we want to trigger policies at startup, login, logout, or network state change, we
must enable Allow Network State Change Triggers, Startup Script, and Login/Logout Hooks under
the Check-In object on the Settings page.
Under execution frequency, we can select once per computer, once per user per computer,
once per user, every day, week, month, or ongoing.
Ongoing will trigger the policy every time computers in scope check in.
Exercise caution with this option because, depending on the content being delivered,
it can quickly result in large amounts of traffic crossing the network.
On the left side we have our configurable payloads - from packages to scripts and beyond.
This policy has one payload configured - maintenance.
The maintenance payload contains update inventory, can enforce the computer names listed in Jamf
Pro inventory records, and flush computer caches.
Moving to the Scope tab, we see this policy is scoped to all computers enrolled in our
server - this is because we want our managed computers regularly submitting inventory reports.
For more information about configuring scope, check out the our Scope video linked here.
Next, configuring the Self Service tab allows users to run the policy themselves from the
Self Service app.
It may make sense to make a policy like this available in Self Service for troubleshooting
purposes, but for this particular policy I’m going to leave this option deselected.
Self Service provides a central repository for software updates, self-help, and other
resources for users.
User Interaction includes start and complete messages for policies.
This is beneficial when policies require a restart, or if we would like to notify our
users that new software, networks, or printers are available to them.
Additionally, we can allow users to defer policies if they’re not ready for an incoming
installation.
Once we’re finished configuring our policy, hit save and it’s ready for deployment.
Like other management tasks, we can check the logs to view when, and on which, computers
this policy has run, is pending, or has failed.
If we need to rerun this policy before our execution frequency of a week has run its
course, we can flush this log and it will rerun the next time the computer checks in.
Finally, we have the option to show this policy on the Jamf Pro dashboard by selecting the
box Show in Jamf Pro Dashboard.
This will provide a quick glance of the policy’s status.
This video covered the core components of policies - content, trigger, execution frequency,
and scope.
We explored a few configurable options such as payloads, Self Service, and user interaction.
To start creating policies of your own, check out our video on Simple Policies.
Thanks for watching, and we’ll see you soon.