Reusable script for updating EA values in Jamf Pro with the API

Need a one-trick pony script to use for updating Jamf EAs with the API? I gotchu.

Not all extension attributes (EAs) are created equally. Sometimes you want to snag information off of a client Mac, and for that a small script to grab the info and report it up to the Jamf Pro Server is great. Other times you just need to set a simple value for a Mac on demand for reporting purposes. One of the handiest ways to set info ad hoc is with a pop-up menu extension attribute.

So let's say the help desk staff notices that some Macs that come by are really smelly. You can't really write a script to pull smell status off of a Mac. (Maybe you can?) So you make a pop-up menu EA for techs to mark if a Mac smells on the computer record in Jamf Pro.




Once created you can find that pop-up menu in whatever tab of a computer record you specified (above, "General") and change the value.



If you want want to make this a little more user-friendly, you can make a Self Service policy that runs a script that updates this value using the API. I've made a template script that uses parameters set on a policy to update an EA using the API to make this relatively painless to do.


When you add the above template script to a Jamf server, take the time to label the parameters so that when it's used in a policy later it'll be easy to remember what information you need to provide for the script to work.



I have them set as:

  • Parameter 4 - Jamf Pro Server URL (no port)
  • Parameter 5 - Encoded credentials
  • Parameter 6 - EA ID
  • Parameter 7 - EA Name
  • Parameter 8 - Value

To use the script in a policy (e.g., a Self Service policy), you'll want to collect the data you need for the variables, which would mean:

  • Jamf Pro Server URL - the URL of your Jamf server, such as jamf.yourcompany.com
  • Encoded credentials - take the username and password of your api account and use openssl to convert them into a base64 string. To do this format your credentials as apiuser:apipassword (meaning a username and password smooshed together with a colon in the middle of an actual user account that can write with the API, I very much hope it's not apiuser with apipassword as a password lol) and run through the terminal with echo -n 'apiuser:apipassword' | openssl base64. You'll get output in a long string, and that should be placed in Parameter 5 on your policy. This adds a layer of abstraction to your username/password string so it will require at least some effort for someone to determine what those credentials are besides just displaying them in plain text on your Jamf Pro server.
  • EA ID - the ID of an extension attribute is displayed in the URL when you are looking at it in your Jamf Pro server. The URL will look something like https://jamfqa.fake/computerExtensionAttributes.html?id=82&o=r. Grab that ID number and put it in parameter 6.
  • EA Name - whatever name you used for your EA should be entered here.
  • Value - what you want the EA to be set as when this script is run. For us, we're using this script to set the value of "Smelly" as "Smells very bad."

Your policy script configuration will look something like this:


Because this script uses the API to modify values in your Jamf Pro server please test the ever living hell out of this before using it in production. I cannot stress this enough. Test test test. 

Recommendations for testing:
  • Add script and test EA on a dev Jamf Pro server.
  • Set a policy to run on a custom trigger with the script and variables correctly configured to validate if values update properly.
  • Set a policy to run in Self Service with the script and variables correctly configured to validate if values update properly.
  • Add EA and script to your Prod Jamf Pro box only if it passes validation in dev
  • Test the script in a policy on a custom trigger to validate.
  • Test the script in a Self Service policy scoped to testing users to validate on another client device by another human.
  • Add the script to whatever policy you want to use it for and save without enabling it and have another human validate the settings and scope before using it as a production script.

There you have it! Have fun and test more than you think you should because you're smart, capable, and I believe in you.

Annoying yet probably necessary disclaimer:
This script has been shared out of me attempting to be a kind, generous member of our amazing Mac Admin community. Use with caution. Note that I will not help you troubleshoot issues that may arise from using this script in your environment. It's provided as-is with no warranty or guarantee. You got dis. 💪🏻

Write a comment