wanting to eliminate EA's as a potential cause of an environment issue. The scripts within each EA are of course tested before being implemented, but when it comes to new MacOS compatibility testing etc. need to then ensure all EA's are functioning as expected for all situations on the new OS versions, or changed environment etc. In JAMF Log you don't get visibility of the EA's running when a recon is completed, so wondering if there are logs at the mac device level to be able to check at an EA by EA level all are working as expected and without any errors. Anyone had any experience with this ? and yes - am aware you can turn off/disable an EA now, which is a good step forwards, but need some logging at client OR server level?
bump - anyone had any experience with this. I'm working with JAMF support, and there is a debug mode for the jamf binary, which provides further info on overall processes kicking off, but not specifically EA's, so short of disabling all the custom EA's that have been added in the environment, would really like to be able to view the success/failure status of each when they run during a recon.
I don't know that there's any specific commands or tools you could use for this, other than what you already outlined, which is to test each EA separately against new applications and/or OS releases. But even testing them outside of a jamf kicked off recon may not be 100% accurate. I've seen instances of scripts that run ok when executed locally, but can fail for various reasons if run within the jamf binary context.
The only other option would be to write your own code for this. Meaning you could add a function to each and every one of your EAs to write the script exit status out to a local log file on the Mac. The log could contain the EA name and date that it ran, and what the exit status was. Of course, that means checking logs on local machines and not in the Jamf console, so it's not the most convenient, but it could enough if you're ok with it being at the client level.
If you really wanted to get fancy, you could have a separate policy that runs once a day that uses the API to put that log file up into the Attachments section of each machine so you could at least pull those down from within the Jamf console to look at them.
Edit: Heh, @sdagley basically had the same idea I did but beat me to it. 🙂
Edit #2: Based on what I've seen in the verbose mode with jamf recon, it does look like it runs the EAs in alphanumerical (or at least alphabetical) order. It's hard to know for sure since the jamf binary is multi-threaded, so tasks get a little jumbled up in the output, but it does seem it works that way.
@mm2270 thx for the suggestion. I was hoping I could get this info without making any further changes to the environment (and policies/ea's) given our current issues we are seeing, but thats an option worst case. You mention that you have been able to detect the order based on the verbose mode with jamf recon. Can you elaborate ? I have the jamf binary in verbose mode (sudo defaults write /Library/Preferences/com.jamfsoftware.jamf.plist global_log_level DEBUG) and when running jamf recon, I dont see that level of detail either from terminal output or in jamf.log. Doesnt appear to be a jamf recon -verbose or similar option either, so really keen to understand where you are seeing the EA's execute in alphabetical order. and thx @sdagley - your suggestion could also be an option, as above, if it comes to that worst case.
@RJH I based that on running
sudo jamf recon -verbose several times on my system. Each time I noticed in the verbose output that the Extension Attributes seem to run in alpha order. I could be wrong and it could just be that the jamf binary simply displays them that way in the Terminal output. But in my tests they always show in alpha type order. Here's an example output:
sudo jamf recon -verbose | grep "extension attribute" Finding extension attributes... verbose: Running script for the extension attribute Active Network Interface verbose: Running script for the extension attribute Battery Cycle Count verbose: Running script for the extension attribute Catalina Compatibility verbose: Running script for the extension attribute DEP Setup Completion Status verbose: Running script for the extension attribute Full Model Name verbose: Running script for the extension attribute Last Boot Time verbose: Running script for the extension attribute mozilla-firefox verbose: Running script for the extension attribute PatchManagement - Cached Packages Count verbose: Running script for the extension attribute PatchManagement - Cached Packages List verbose: Running script for the extension attribute Verify MDM Enrollment
The above just filters out the extension attribute lines.
@RJH Unless your system configurations vary enough that you feel only testing on a baseline system isn't sufficient I think @tlarkin's suggestion might be the simplest. Just make sure that whatever PPPC permissions are granted to the Jamf binary are enabled for Terminal on your test system so EAs running there have the same access they'd have in real life.