Setting an Extension Attribute using policy?

ostrowsp
Contributor

Is it possible to set an Extension Attribute using a policy?
I have an extension Attribute and I want to set to yes using a policy

7 REPLIES 7

sdagley
Honored Contributor II

@ostrowsp If your EA's Input Type is Text Field you could have a Policy run a script to use the Jamf API to set the EA value.

Tribruin
Contributor III
Contributor III

You could write the result of your policy to a file and then have your EA read that file by running a recon at the end of the policy. The only reason I would not use the API is the credential aspect.

ostrowsp
Contributor

If I have a policy to write a file, then the EA can never manually be changed, so that wont really work. I'm surprised there is no way to automatically do this

sdagley
Honored Contributor II

@ostrowsp Can you describe what it is you're trying to achieve by modifying an EA? There may be another way to do what you need.

iJake
Valued Contributor

What @sdagley said, do this via the API in policy script. Put the credentials in the parameters section and pass them to the script.

tlarkin
Honored Contributor

If I need to do this I write to a flat file (plist) locally then have the EA just read the values of the keys. That way I can execute all logic off the local state, write the data, and next recon the EA will pick it up.

Also, super big pro tip - if you are collecting data for anything in an EA and you don't get the value you want or there is a failure, just write a value of false to the EA. Blank values can cause issues, and if you write something like false (or 1, 0, or N/A or anything to indicate it is a failure or no results) then you know for sure the code ran. This also largely helps your data downstream if you are collecting data in a data tool.

Here is an example template I use to see if binaries are present (i.e. they get stdout)

#!/bin/zsh

# EA to test if the foo binary is present

if /usr/local/bin/binary_name arg &> /dev/null
  then echo "<result>true</result>"
  else echo "<result>false</result>"
fi

That way if I run reports or check data downstream in our data tools, and I see false I know that the EA ran and it detected a failure. I can also use this value where ea_foo = false as smart group criteria to scope for fixes. So, really I don't see any reason why you would want a blank value in an EA. Blank values should only be found on devices that have not checked in and submitted inventory.

mpuyet
New Contributor II

if you don't want to do it from a script-extensionAttribute you can do a textfield-EA or popupMenu-EA & populate it from a policy using a script payload.

 

Script example to populate an Extension Attribute : 

jamfUrl="https://jss.jamfcloud.com"
jamfUser="your_JamfUser"
jamfPass="your_JamfPass"
V_SerialNumber=$(system_profiler SPHardwareDataType | grep "Serial Number (system)" | awk '{print $4}')
EA_Id="123"

EA_Value=""

curl -sku $jamfUser:$jamfPass -H "Content-type: application/xml" $jamfUrl/JSSResource/computers/serialnumber/$V_SerialNumber -X PUT -d "<computer><extension_attributes><extension_attribute><id>$EA_Id</id><value>$EA_Value</value></extension_attribute></extension_attributes></computer>"

You have to change Jamf API & EA variables.

Additionally you can add an IF to define your EA_Value  result to sent on the device inventory