Archive for the ‘Jamf Pro’ Category

Setting up software deployment groups using a Jamf Pro Extension Attribute

September 10, 2021 Leave a comment

When setting up software for deployment, it’s usually a good idea to first send it out to a small percentage of the Macs in your environment. That way, if there’s a problem that wasn’t caught in testing, the amount of cleanup required is also small. If that initial deployment works, the software can then be sent out to greater percentages of the Mac population until all of them are eventually covered by the deployment.

This can be a pain to track manually though. New Macs come in, older ones are retired and keeping all Macs covered can turn into a significant investment of time. Fortunately, this is a task which can be automated and enable the Macs to assign themselves to deployment groups based on their machine UUID identifier. For more details, please see below the jump.

Read more…

Using the Jamf Pro API to report on which Macs are assigned to a particular person

August 26, 2021 Leave a comment

Every so often, it may be necessary to generate a report from Jamf Pro on which computers are assigned to a particular person. To assist with this task, I’ve written a script which uses the Jamf Pro Classic API to search through the computer inventory records and generate a report in .tsv format.

For more details, please see below the jump.

Read more…

Backing up Self Service bookmarks for Jamf Pro 10.30.0 and later

June 23, 2021 Leave a comment

A while ago, I wrote a post on how to back up your Jamf Pro Self Service bookmarks. I’ve been using that process to back up my bookmarks and it’s been working fine until after my upgrade to Jamf Pro 10.30.0. At that point, my script stopped working. When I checked into it and talked with some colleagues, it became apparent that Jamf had made a change with how they stored bookmark information for Self Service.

In 10.29.x and earlier, Jamf had stored bookmarks as individual plist files in the following location:

/Library/Application Support/JAMF/Self Service/Managed Plug-ins

Screen Shot 2020 09 27 at 11 31 16 AM

In 10.30.x and later, the /Library/Application Support/JAMF/Self Service/Managed Plug-ins directory has disappeared.

Screen Shot 2021 06 23 at 10 37 24 AM

Jamf now stores bookmark information inside an XML file named CocoaAppCD.storedata in the user’s home folder at the following location:

~/Library/Application Support/com.jamfsoftware.selfservice.mac/CocoaAppCD.storedata

Screen Shot 2021 06 23 at 10 35 51 AM

Inside the CocoaAppCD.storedata file, the bookmarks are stored as XML objects similar to what is shown below:

<object type="SSBOOKMARK" id="z169">
<attribute name="url" type="string"></attribute>
<attribute name="priority" type="int64">5</attribute>
<attribute name="displayinbrowser" type="bool">1</attribute>
<attribute name="name" type="string"></attribute>
<attribute name="jssdescription" type="string"></attribute>
<attribute name="installstatus" type="int64">0</attribute>
<attribute name="id" type="int64">2</attribute>
<attribute name="iconurl" type="string"></attribute>
<attribute name="compliance" type="bool">0</attribute>
<attribute name="buttontext" type="string">Open</attribute>

view raw
hosted with ❤ by GitHub

Screen Shot 2021 06 23 at 4 22 03 PM

Fortunately, I was able to figure out a way to do the following:

  1. Parse the document for the bookmark XML objects.
  2. Split them out into individual XML files.
  3. Name the files using the title of the Self Service bookmark.

For more details, please see below the jump.

Read more…

Jamf Pro deprecating the ability to issue a Tomcat certificate from the Jamf Pro built-in certificate authority

June 15, 2021 1 comment

As part of the release of Jamf Pro 10.30, the following entry was added to the Deprecations section of the Jamf Pro Release Notes:

Functionality to issue the Tomcat SSL/TLS certificate from Jamf Pro’s built-in certificate authority — Jamf Pro’s functionality to issue the Tomcat SSL/TLS certificate from the JSS built-in certificate authority (CA) will be discontinued in a future release of Jamf Pro. The release version for this change has not been determined.

Before this change occurs, it is recommended that all on-premise Jamf Pro instances leveraging this functionality switch to a publicly trusted third-party CA to issue the Tomcat SSL/TLS certificate. This will prevent the potential loss of MDM communication from Jamf Pro to enrolled devices.

If needed, a Tomcat SSL/TLS server certificate for Jamf Pro may be issued from an internal certificate authority. The JSS built-in CA will maintain its current ability to manually issue server certificates to other servers.

Screen Shot 2021 06 15 at 3 08 31 PM

For shops which use Jamf Pro’s built-in certificate authority to create the SSL certificate used by the Tomcat web application, this means that at some point in the near(ish) future, you will need to plan to use a certificate for your Jamf Pro server which is no longer being issued by your Jamf Pro server’s built-in certificate authority.

Screen Shot 2021 06 15 at 3 11 52 PM

For more details, please see below the jump.

Read more…

Categories: Jamf Pro, Java, Linux, PKI

Updated Jamf Pro MDM lock script to add reporting feature

June 1, 2021 1 comment

Previously, I’d written a script to manage sending device lock commands using the Jamf Pro Classic API. After writing it, I thought that it would be a good idea if the script could also generate a report that could be handed off to others so I forked the script and updated it to generate a report in .tsv format. Since others might prefer the original script without the automatically generated report, I left that one alone and have made the forked copy into its own script. For more details, please see below the jump.

Read more…

Using the Jamf Pro API to send device lock commands via MDM to multiple Macs

May 28, 2021 1 comment

Most Mac admins have had this conversation at one point or another over the course of their careers:

“$Very Important Person left their Mac behind in a cab! What do we do?”
“OK, no worries. We can send a command to lock the computer or have it erase itself. Do you want it locked or wiped?”

At that point, the admin pulls up their MDM admin console and depending on what the response was (lock or wipe), send out the appropriate MDM command accompanied by a PIN code. Once received, the Mac will then turn itself into a paperweight which does or doesn’t erase itself.

Doing these one at a time is a pretty straightforward process. For example, here’s how it looks in Jamf Pro to send a device lock command via MDM:

1. Log into Jamf Pro using an account which can send lock commands via MDM.
2. Go to the appropriate computer inventory record.

Screen Shot 2021 05 28 at 2 48 00 PM

3. Select the Management tab.

Screen Shot 2021 05 28 at 2 48 01 PM

4. In the Management Commands section of the Management tab, click the Lock Computer button.

Screen Shot 2021 05 28 at 1 57 43 PM

5. Enter the PIN code which will later be used to unlock the Mac. If desired, you can also enter a message which will appear on the lock screen.

Screen Shot 2021 05 28 at 1 58 56 PM

6. Click the Lock Computer button.

Screen Shot 2021 05 28 at 1 58 57 PM

7. Click the OK button in the confirmation window.

Screen Shot 2021 05 28 at 1 59 42 PM


Once the device lock command has been sent, the Lock Computer button’s text should temporarily change to Command Sent.

Screen Shot 2021 05 28 at 1 59 49 PM


For a small number of machines (10 or less), the method outlined above works fine. But once you get beyond that number, this process gets time-consuming and unwieldy. Fortunately, there is also a way to use the Jamf Pro Classic API to send device lock commands. For more details, please see below the jump.

Read more…

Blocking account logins to the ?failover login page on Jamf Pro

May 21, 2021 1 comment

As part of Jamf Pro’s single-sign on (SSO) logins, there’s an option to bypass the SSO login using the following URL:

Screen Shot 2021 05 21 at 11 02 14 AM

This URL is designed to let you bypass the SSO login page and take you to Jamf Pro’s own login, so that if your SSO provider is having a bad day, you can still log into your Jamf Pro server.

For those wanting to make sure that that their folks are only using SSO for logins, this can seem like a security hole. Fortunately, there’s a way to plug it. For more details, please see below the jump.

Read more…

Categories: Jamf Pro

Workaround for timeouts when deleting installer packages from Jamf Pro

April 22, 2021 Leave a comment

I use AutoPkg and JSSImporter to keep my Jamf Pro server updated with the latest installers for the software used by my shop. However, this means that I usually have a large number of no-longer-needed installers stored in my Jamf Pro server’s distribution point and I need to periodically clear the obsolete packages out by deleting them. Recently, as part of removing 500+ unneeded packages from Jamf Pro using a script, I noticed the following behavior occurring:

1. Run an API command similar to the one below:

username@computername ~ % /usr/bin/curl -su username:'password' "" -X DELETE

2. Long pause (around 60 seconds)
3. Receive the following output:

<head><title>504 Gateway Time-out</title></head>
<center><h1>504 Gateway Time-out</h1></center>

4. Check the package and it has been deleted from Jamf Pro.

The 504 Gateway Time-out error indicated that either the load balancer in front my Jamf Pro server was timing out before the API command could report success or failure. I was seeing this behavior when running the API commands manually or as part of a script, so I decided to see if I saw the same behavior when deleting the package from the Jamf Pro admin console. When I checked, I did.

I sent in a support request to Jamf to ask about this and there is a PI open for this:

PI-009627: Having a large amount of packages uploaded to a distribution point can cause various timeouts

For others experiencing this issue, while Jamf addresses this product issue, the workaround for the timeout issue is (if possible) to increase the timeout value. In my case, increasing the load balancer timeout from 60 seconds to 120 addressed the timeout issue and allowed my API and GUI package deletions to complete successfully without timing out.

Note: This does not fix the issue of the package deletion taking a while. It just makes sure that the deletion command, either via the API or using the GUI in the admin console, doesn’t timeout before reporting success or failure.

Categories: Jamf Pro, Jamf Pro API

Using the Jamf Pro API to mass-delete obsolete packages and scripts

April 16, 2021 2 comments

If you’re using AutoPkg and tools like jamf-upload or JSSImporter to automate the uploading of packages and scripts to your Jamf Pro server, it may be necessary to periodically delete a large number of now-obsolete installer packages or scripts from your server. To help with this, I’ve written a couple of scripts to help automate the deletion process by using a list of Jamf IDs and the API to perform the following tasks:

  1. Delete the relevant installer packages or scripts.
  2. Generate a report of which packages or scripts were deleted.

For more details, please see below the jump.

Read more…

Using Markdown comments to add search keywords to Self Service descriptions

April 2, 2021 Leave a comment

For those using Jamf Pro’s Self Service, one of the handier features can be the Search function built into the app. This search is able to examine Self Service policies and use the information in the policy and Self Service description to populate its search results. For the most part, just the displayed information in the policy should allow Self Service’s search to display relevant policies.

However, you may have a need to force the search process to include policies that would otherwise fall outside of the search parameters. For those who need this ability, thanks to Self Service’s support of Markdown it’s possible to invisibly add search keywords to a Self Service policy description. For more details, please see below the jump.

Read more…

%d bloggers like this: