Extension Attribute script to only update if field is empty

[nikgio]

Is there a way to only update an extension attribute's value if it hasn't been populated yet? If the field is already populated, I want JAMF to leave it alone. Something along the lines of:

if ""; then
do this command
echo the result
fi

not sure if there's a field or variable associated with it... in MUT, I know it would be EA_4 or whatever the ID is, but not sure if JAMF uses the same term.

[talkingmoose]

Unfortunately, no.

The EA, by design, will always return a result to Jamf Pro. If your script returns echo <result>some result</result>, then "some result" will be the value of the EA. If you don't explicitly return a result, the EA effectively returns <result></result> (an empty value).

[donmontalvo]

We always make sure an EA returns a value, even if the value is <result>DoesNotExist</result> or <result>NoValue</result>.

This way if the field is absolutely blank, it would mean the computer has not reported in since the EA was created.

[swapple]

To control the action, I make a policy to run the script (heavy lifting) and then output the results to a text file, then have the EA just check the text file for results (light task). With the policy, I can control it with once per computer or if file exists inside the script. I think there is a feature request out there to make EAs more powerful, like running some and not others or running them more often than along with recon.

[Tribruin]

You could pull the EA from the API in your script, check if it is empty, and then either create/return the value or just return the existing value.

I guess the question is what are you trying to accomplish by having an EA that never changes? How is the EA get set initially? And what are you using the EA for in Jamf?

[marklamont]

just fell foul of this and it's a pain. Trying to rework a LAPS script so it doesn't need API calls I used the write value to file then read file method, then delete the file for security. works ok until the EA runs again and outputs a blank value overwriting the password value! So it's API or leave file behind...
I did find and upvote this

[Mauricio]

@nikgio If I understood it, you do not want to use an API call and run the script directly from the EA and only setup a password if there is none. Basically set once and forget.

One option is to write an empty local file like .lapsSetupDone when you run the script.
So every time the EA script runs if that file exists/is found just exit the script otherwise set the password and set the "marker".
We do use a hidden file in our provisioning once it is done. We put it in /var/db/ like the .AppleSetupDone

And if there is a need to re-issue a new password just create a policy to delete that file.

[dan-snelson]

@nikgio On the off-chance that this proves helpful: Extension Attribute Frequency.

[DvR]

@nikgio If you do 'matches regex' '^$' it will return all the empty fields

[tlarkin]

Would strongly suggest to use explicit data sets with everything you do. Blank values can be treated as NULL or a blank string, and depending on how you are leveraging that data, it can mean two very different things. You can also find that in some scenarios blank values end up being used when they should not. As a general rule all my EAs will return false if I don't find the value I am looking for, that way I can use that data upstream and know exactly what it means and not have to code around either NULL or blank strings. Plus it mitigates being bitten by a blank value. I have seen this bite me before so just passing this along.

[mschroder]

What @tlarkin says is even more important for anything in date format. An empty date matches EVERYTHING, so I use a date outside the 'reasonable' range (eg 9.9.1999) as a default value in case an event has not yet happened on a device. That way I don't get bogus result with 'before' or 'after' tests.

[howie_isaacks]

I have an extension attribute that I call "ZTP Report". It reads the contents of a log created during ZTP and reports on the success or failure of installing the apps that we deploy through ZTP. The EA reports a "Yes" or "No" result for each app install. My Power BI admin asked me to change the EA to only report if apps did not install, hence a "No" result. This was easy to do. I just removed the variables from the script that would result in "Yes" if an app did install. As a result, the EA will just show blank results in Power BI. If there's a "No" it will have white space above or below it. From what I'm reading here, this is normal behavior and it can't be changed. Ideally, we want no app install failures, so most results will just be blank. Here's a screenshot of what I saw when I manually modified the log to have mostly "not installed" results for each app. For the apps that did install, the result is blank. In Power BI, it will look like this. This is a screenshot from CodeRunner.