CREATING MAGIC WITH ENDPOINT PROVISIONING PART 3 – THE POLICIES

“Any sufficiently advanced technology is indistinguishable from magic.”‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎ Arthur C. Clarke

In parts one and two of our series on the magic on endpoint provisioning we started at the end, looking at the big reveal, and then we moved onto the script that drives it all.

Today we are taking another step back and looking at the policies that make up the

framework.

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

later.

The rest will just happen when they get to their turn.

Global Policies

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:

jamfCommand policy

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.

Departmental Policies

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:

jamfCommand departmentalApplications

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.