Skip to main content

An example here will help. I have a policy that installs Acrobat. I thought about scoping this one of two ways:
1. All computers installed once per computer since we do want to install this on every Mac. If we ever have to wipe out a Mac and re-enroll we will have to delete the computer record in Jamf or Acrobat will not get installed.
2. Make a Smart Computer Group that checks whether Acrobat is installed and if it is not, go ahead and install it. This would be set to an ongoing basis. If the computer were wiped clean and re-enrolled, Acrobat would get installed.

On its face, choice 2 seems like the obvious one. The problem is I have other policies that are more difficult to check whether the Mac already has the policy applied. For example, we have a policy that sets the time server to our domain controller. Not even sure how to craft a Smart Computer Group to check if this has been set. I have a few policies that seem difficult to check whether they have been carried out. This leans me towards choice 1 with the caveat that if we ever have to wipe a computer we have to remember to delete the computer record from Jamf first.

We are new to Jamf so any guidance is appreciated

Either method will work just fine. You can always run a "jamf flushPolicyHistory" if your computers policy history was not being flushed at imaging. I prefer the smart group option because if the application is removed for some reason it will get reinstalled. As far as the time server you could try something like this in an extension attribute and build a smart group off it.

#!/bin/sh

echo "<result>$(systemsetup -getnetworktimeserver | awk '{print $4}')</result>"

exit 0

I find that the bulk of the job of being a Mac/Jamf admin is finding or writing Extension Attributes and making Smart Groups for them. I don't think I have a single policy that's set to run once per computer. There's always some condition, you know?
For apps that aren't in patch management for instance I'll have three Smart Groups:
App: Not Installed (App name is not App.app)
App: Installed (App name is App.app)
App: Outdated (App name is App.app and App version is not latest)
The first and third are usually scoped to a Policy that installs the current package while the second is scoped to whatever Configuration Profile I might have for the app in question.
This is a simplification of the process of course. In a larger environment you have to consider update testing, Self Service availability, using AutoPkg et c.

Welcome to the party!

Terms & ConditionsCookie settingsAccessibility statement