“Imaging is dead!” Now what? — Part 2

In part two of our three-part blog series, we talk policies, packages and scripts to replace imaging.

August 1 2018 by

Jonathan Yuresko

To recap, in part 1 we covered preparing and organizing the workflow needed to replace imaging.

The setup

Now that you have all of the items you wish to deploy in a list, and a folder of items you’re looking to upload to Jamf, go ahead and do so. Upload all the packages and upload all the scripts/settings you’ve gathered that you’d normally install via the “master” image. Once all of the packages are up in Jamf Pro, we can create a policy structure that will kill multiple birds with one stone. This is a three policy structure: Payload Policy, Provision Policy, Self Service Install Policy. See screenshots below. There are many ways to accomplish this task, and there will be other posts that explain some other options. Using this primary structure will make your work lives 10x easier in the long run and ensure consistent provisioning for all of your deployment scenarios.

For the example below, we will be deploying a non-Mac App Store app and a policy that contains a setting. You can use these templates for every other item you wish to deploy, though some you may want to leave out the “Self Service Policy” as it may only be necessary to deploy once at time of provisioning.

App Example - Google Chrome:

  1. Smart Group
    1. Name of Smart Group: “Has Google Chrome”
    2. Criteria: “Application Title is Google Chrome.app”
  2. Payload Policy
    1. Name of Policy: “Main – Google Chrome”
    2. Category: “Main Policy”
    3. Trigger: Custom – “main_googlechrome”
    4. Frequency: “Ongoing”
    5. Payload 1: Package – “Google Chrome.pkg”
    6. Payload 2: Maintenance – “Update Inventory”
    7. Scope: Target – “All Computers” or “All Managed Clients”
  3. Provision Policy
    1. Name of Policy: “Provision – Google Chrome”
    2. Category: “Provisioning”
    3. Trigger: Custom – “provision_googlechrome”
    4. Frequency: “Ongoing”
    5. Payload: Execute Command – “jamf policy -trigger main_googlechrome”
    6. Scope: Target – “All Computers”
    7. Scope: Exclude – Smart Group: “Has Google Chrome”
  4. Self Service Policy
    1. Name of Policy: “Google Chrome”
    2. Category: “Browsers” or whatever you’d like to brand it as
    3. Trigger: “Self Service”
    4. Frequency: “Ongoing”
    5. Payload: Execute Command – “jamf policy -trigger main_googlechrome”
    6. Scope: Target – “All Computers” or “All Managed Clients”
    7. Scope: Exclude – Smart Group: “Has Google Chrome”

Setting Example – Turn on Location Services

  1. Payload Policy
    1. Name of Policy: “Main – Turn on Location Services”
    2. Category: “Main Policy”
    3. Trigger: Custom – “main_locationservices”
    4. Frequency: “Ongoing”
    5. Payload 1: Script – “turnOnLocationServices.sh”
    6. Payload 2: Maintenance – “Update Inventory”
    7. Scope: Target – “All Computers” or “All Managed Clients”
  2. Provision Policy
    1. Name of Policy: “Provision – Turn on Location Services”
    2. Category: “Provisioning”
    3. Trigger: Custom – “provision_locationservices”
    4. Frequency: “Ongoing”
    5. Payload: Execute Command – “jamf policy -trigger main_locationservices”
    6. Scope: Target – “All Computers” or “All Managed Clients”

You may be thinking, I thought you said it would be easier, this looks like it could take forever! Well, truth be told, depending on how many items you have in your provisioning workflow, the longer it would take to build out the above structure. But, we have a very powerful API toolkit built into Jamf Pro, that using some scripting/automation, we can create hundreds of policies in the amount of time it takes to make just one by hand (example). I cannot emphasize enough to utilize API and webhooks to eliminate the need to do repetitive tasks. Please, do not be afraid of APIs or scripting. Check out our documentation on the basics.

As you go, check your work to ensure the payload is only found in the “Main” policy and every other policy (“Self Service” or “Provisioning”) has the proper custom triggers to call the “Main” policy. See screenshots for examples. This is where time is now saved. If you follow the above steps, every time a manufacturer puts out a new update to the software, you only have to update one policy! That “Main” policy will always be used to deploy the payload desired, and because it is the only place that houses the payload to be deployed, you only need to update/change that one policy. In previous workflows, you may need to adjust many policies to keep everything up to date, but no matter how you’re looking to deploy a new Adobe software, or BBedit or Slack or browser, you now only need to swap out the payload found in the “Main” policy.

One final tip when it comes to deploying apps, try to utilize scripts to deploy software. To deploy an app via a script means that in the “Main” policy, you’ll have a script instead of a .pkg or .dmg and that script is going to automatically reach out to the manufacturer, download the latest and greatest version, and install it on the target machine in one swoop. This means you will NEVER have to update any policies for that app, as the vendor/manufacturer of that app will adjust the version on the backend but your script will reach out to the proper URL to get said updated app! The more you set up now, the less you’ll have to adjust later. Set and forget!

In part 3 we’ll cover how it all ties together to kick-off a provisioning workflow.

Not a Jamf customer? Take our best-of-breed Apple management solution for a free test drive and start putting these workflows in place.

Subscribe to the Jamf Blog

Have market trends, Apple updates and Jamf news delivered directly to your inbox.

To learn more about how we collect, use, disclose, transfer, and store your information, please visit our Privacy Policy.