Setting an Extension Attribute using policy?

[ostrowsp]

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

[sdagley]

@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]

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]

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]

@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]

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]

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]

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

[egorsc]

I am trying to do the same, however, always get the following error: The request requires user authentication

The interesting part is, that everything works (i.e. I am able to pull the values) if I ignore the last piece of the code. So, it's not like my credentials are incorrect.

 -X PUT -d "<computer><extension_attributes><extension_attribute><id>$EA_Id</id><value>$EA_Value</value></extension_attribute></extension_attributes></computer>"

Does anyone have an idea?