Home

Important Notice

JSSImporter is in basic maintenance mode. For the time being, I will attempt to fix anything that breaks as a result of changes to the Jamf Pro Classic API, but feature requests will not be considered. If you are new to AutoPkg and considering using JSSImporter for the first time, please instead consider the JamfUploader Processors instead (I maintain that project too). Before fully deprecating JSSImporter, I will provide 12 months' notice.

If you wish to take over maintenance of JSSImporter (and therefore python-jss), get in touch.

• Graham Pugh, 2021-10-29

Introduction

The JSSImporter processor adds the ability for AutoPkg to upload packages to a Jamf Pro distribution point, and create scripts, extension attributes, computer groups and policies in a Jamf Pro server (the server formerly known as "JSS"), allowing you to fully-automate your software testing workflow.

This project began from Allister Banks' original jss-autopkg-addon project, but has since diverged considerably completely to add greater customization options while maintaining the existing functionality.

Getting Started

Getting your software testing workflow constructed using AutoPkg and JSSImporter can be daunting. This document will go over the various configuration and usage information you will need for success. Start with the Installation and Setup page and work down the list.

See also:

• Jamf And AutoPkg by Graham Pugh, JNUC, 2019.
• Integrating AutoPkg and Casper with JSSImporter by Shea Craig, MacAdmins Conference at Penn State, 2015.

Best practices

While JSSImporter has a lot of options for crafting the workflow best suited to your organization's needs, there are best practices expressed in the AutoPkg organization's jss-recipes repo that drive the design of JSSImporter.

The workflow used in the AutoPkg org's jss-recipes repo goes something like this:

Package information

.jss recipes use .pkg recipes as parents - these produce standard Apple package (pkg) files. This ensures that a pkg can be uploaded to the distribution points. The resulting package file name includes the software's name and version number (e.g. Firefox-38.0.5.pkg).

The package file's metadata includes any OS version restrictions that govern that product's installation.

The .jss recipe specifies the category for the package file itself, which is chosen from among a limited set of approved categories. (See the list of categories in the Style guide below.) If the category doesn't exist, it will be created.

JSSImporter uploads the package file to all configured distribution points.

Smart Group Template

A SmartGroupTemplate.xml file tells JSSImporter to create or update a smart group called [SoftwareName]-update-smart. The criteria of this group are:

• the computer has the software in question installed
• the version does not match the newest version that AutoPkg found
• the computer is a member of a group called Testing (which is created and maintained manually by the Jamf admin)

The standard SmartGroupTemplate.xml file is available in the example_templates folder of the JSSImporter repo. Note that this needs to be available to AutoPkg before running any .jss recipe. We recommend copying it into your RecipeOverrides folder.

No groups other than the smart group mentioned above are created or modified.

Policy Template

• A PolicyTemplate.xml file tells JSSImporter to create a single Self Service policy for each product, called Install Latest [SoftwareName]. The policy:
  • installs the latest package file.
  • is scoped to the smart group mentioned above.
  • includes a Self Service icon and description.
  • category is Testing. This groups policies together under the Testing category on the Policies page of the Jamf Pro web interface to separate and distinguish them from other policies. If the Testing category doesn't exist, it will be created.
  • has an execution frequency of "Ongoing" to allow multiple runs should tests fail. However, following a successful installation, the Self Service policy performs a recon run, which will drop the computer out of the smart group, thus preventing further executions until the next update is made available. This also enables reuse of the same policy without needing to "Flush All" the policy logs.

The standard PolicyTemplate.xml file is available in the example_templates folder of the JSSImporter repo. Note that this needs to be available to AutoPkg before running any .jss recipe. We recommend copying it into your RecipeOverrides folder.

Icon files also need to be copied to the RecipeOverrides folder.

Extension Attributes

In the rare case of needing an Extension Attribute to determine whether a package is out-of-date, and thus used to determine membership in the smart group, these Extension Attributes will be created and/or updated. A separate [SoftwareName]-ExtensionAttribute.xml file is required for this. This is most commonly the case with apps that either don't live in /Applications, are not an app bundle at all (e.g. Java), or report different version numbers for CFBundleShortVersionString and CFBundleVersion (Jamf only uses CFBundleVersion for inventory).

autopkg/jss-recipes

The AutoPkg organization's jss-recipes repo is a community project which adheres to the best practices generally agreed upon by the community. Other Mac Admins may provide their own .jss recipes, and they are encouraged to follow the same guidelines so that the resulting policy & smart groups are compatible.

JSSImporter's goal is to allow you to, with AutoPkg, automate the drudgery of managing a testing workflow. It is not meant to deploy software straight to production machines. It is not meant as a way to bootstrap all of a JSS's policies.

Advanced usage

There is a lot you can do with the Jamf Pro API, and JSSImporter's code is an illustration of how to go about doing this. If you are trying to do something beyond what these recipes cover, you will most likely need to create your own .jss recipes, which may be best suited to a private repository so as not to produce unexpected effects if used by others. This usually involves establishing your own workflow, and writing the policy and smart group templates to support that. Implementing individual recipes becomes largely editing a handful of values in copies of these templates, 90% of which end up being the same.