“Any sufficiently advanced technology is indistinguishable from magic.” Arthur C. Clarke
Today we are taking another step back and looking at the policies that make up the
Let’s start with the most important ones:
Why two triggers? Ideally, this will run at the time of enrollment; either through Automated Device Enrollment or User Initiated Enrollment. As we saw in part 2, the script makes sure to wait until we are in a user setting to begin. But should something happen and the enrollment complete trigger doesn’t happen (not common, but not unheard of either) we want a fall-back. That’s why we include the recurring check-in trigger as well.
And why two policies? We have one for user-initiated enrollment that includes the package with our company logo and welcome video. In the other policy, which is set up for Automated Device Enrollment, we don’t include the packages, because they are included in our PreStage enrollment configuration.
So now considering the following list of policies:
Configuration and Priority Items
If there are things we need to happen right away (e.g. binding to AD (ick!), renaming the computer, etc.) we start with policies like these. They are using custom triggers so that we can call them out in our script like this:
jamfCommand registerWithUser jamfCommand initialSetup
You may notice the first couple have numbers at the start of their names. Since multiple policies run by the same trigger run in alphanumeric order, we can control the sequence by changing the names of the policies. Here we are using two digit numbers (10, 20, etc.) at the beginning to make it easier to insert a new policy later (11 or 23) without having to rename all the ones above or below it.
We also have a policy called “Register Device to User” that runs a separate but related script. DEPNotify also includes capabilities to provide text input and dropdown elements. In our script, we are using a Jamf Pro user with limited capabilities to pull down the lists of Buildings and Departments in our organization through the API and ask the user to choose. Those choices are stored in a property list file that we can parse and send back to Jamf with another API call or use a script-based Extension Attribute that will get picked up with a recon
The rest will just happen when they get to their turn.
This group of policies are scoped to (most, if not) all computers and triggered by the recurring check-in trigger. We don’t care what order they go in as long as they all get installed. All we need in our script is:
And maybe to keep the user in the loop, we throw in something like:
DEPNotify “Status: Installing global applications. This may take a while.”
That first one also includes a manual trigger. We’ll see how we can use that in the next section.
Maybe you have some policies like this: ones that not everyone needs, but until we trigger the user registration above or pull the information in from AD, we didn’t have the machines scoped before now. We just need the single command:
And now each computer will check-in and Jamf can see which computers get which of these policies, but not all.
Last Minute Policies
Here we have some policies that either need to happen after other actions (mapping printers after the drivers were installed, running clean-up scripts) or ones that may rely on other policies populating smart groups beforehand. We get these with the following two lines:
jamfCommand recon jamfCommand policy
Doesn’t need to be more than that. Just update the inventory and check for additional actions to take.
Now obviously these are all fairly simple examples. Just a little demonstrative sleight-of-hand to show what kinds of magic we can create when we bring the right tools together.
I hope you’ve enjoyed this series. If you have any questions or want to know more about any of these pieces, please let us know.