Archive

I recently saw an issue where several computers in Jamf Pro were showing up with the same serial number listed in their inventory records. This made it difficult to work with this serial number using the API because Jamf Pro Classic API calls may fail if we’re referencing the serial number in the API call and more than one inventory record exists with that serial number.

First off, how can this happen? Aren’t serial numbers supposed to be unique? They are, but there’s two instances where serial numbers may unfortunately be associated with more than one Mac.

Hardware repair:

When you send a Mac out for repair and the logic board is replaced as part of the repair, the Mac’s existing serial number is flashed onto the replacement logic board.

However, both the old and new logic boards have separate Unique Device Identifiers (UDID) associated with them. When enrolling a device into Jamf Pro, it is possible for a new inventory record to be set up if a device has:

The same serial number listed in as an existing inventory record

A UDID not found in other inventory records

Parallels macOS virtual machine:

macOS virtual machines set up by Parallels Desktop and other Parallels hypervisor products use the same serial number as the Mac which is running the Parallels hypervisor software. These VMs will likewise have separate Hardware UDIDs associated with them.

So what to do with these duplicate records? My recommendation is to delete them from your Jamf Pro server when you find them, especially if you do a lot of work using the API. To help with this task, a script has been developed to identify and delete unwanted duplicates. For more details, please see below the jump.

Like this:

As part of setting up new Jamf Pro policies, the Restart Options section is automatically added to newly-created policies.

For policies which don’t need it though, this section should be removed as a best practice to avoid accidental triggering of a restart where one isn’t needed or wanted. In some cases, the options provided by this section are never needed and it may be useful to be able to remove the Restart Options section from all of your current Jamf Pro policies.

In those cases, depending on how many policies you have, it can be tedious to have to do them one at a time using the admin console. However, with the right API calls in a script, it’s straightforward to perform these tasks using the Jamf Pro API. For more information, please see below the jump.

Like this:

When working with Jamf Pro, one way to save yourself a lot of clicking in the admin console is to use one of the two current Jamf Pro APIs. Both APIs are REST APIs, which means they can perform requests and receive responses via HTTP protocols like GET, PUT, POST and DELETE. That means that the curl tool can be used to send commands to and receive information from a Jamf Pro server.

The two APIs are as follows:

Classic API

Jamf Pro API (formerly known as the Universal API)

Classic API

This API is the original one which Jamf Pro started with and it is slated for eventual retirement. This API is designed to work with XML and JSON.

The base URL for the Classic API is located at /JSSResource on your Jamf Pro server. If your Jamf Pro server is https://server.name.here:8443, that means that the API base URL is as follows:

The Jamf Pro API is designed to work with token-based authentication, with a Jamf Pro username and password used to initially generate the necessary token. These tokens are time-limited and expire after 30 minutes. However, you can generate a new token for API authentication using the existing token’s credentials. The new token generation process does the following:

Creates a new token with the same access rights as the existing token.

Like this:

Every so often, it may be useful to be able to enable or disable all of your current Jamf Pro policies. In those cases, depending on how many policies you have, it can be tedious to have to do them one at a time using the admin console.

However, with the right API calls in a script, it’s straightforward to perform these tasks using the Jamf Pro API. For more information, please see below the jump.

Like this:

As part of setting up Self Service policies in Jamf Pro, the usual practice is to include an icon to help the user distinguish between various Self Service policies.

However, when copying policy information via the API, a Self Service policy’s icon is sometimes not copied along with the rest of the policy. When this happens, it can be hard to figure this out later which ones were missed.

To help with situations like this, I have a script which does the following:

Checks all policies on a Jamf Pro server.

Identifies which ones are Self Service policies which do not have icons