Hi there. In order to keep our extension attributes up-to-date, we have added a recon policy, to run once daily, with a script called as follows;
#!/bin/sh /usr/local/bin/jamf recon exit 0
When I run this script locally on macs, the recon command updates the extension attributes correctly, populating the database with the expected results, but when it runs as a policy, all the results are cleared out leaving no information in the extension attribute fields.
Can anyone help to shed light on this or advise how I can force an update to the extension attributes?
jamf does some weird stuff with process listings when it's running. You know how to list all processes with 'ps auxw' on a mac? Put that in a script and look for the jamf processes - they're filtered out! So I expect there's a bug somewhere with that process. As @davidacland says, just use 'update inventory' checkbox instead.
This problem persists in our environment. We have a case open with JAMF but no progress for two weeks. We have determined that right after the upgrade to 9.100, any policy that has the checkbox for "update inventory" can trigger this behavior. It can manifest as all or most of the EAs being blanked out or the hardware record having no information in it or wrong information like a 0 where RAM and # of processors should be. Also as a result, the Macs that experience this issue also have an issue getting in through SSH or ARD. Or if I happen to get in and attempt to run any command manually I get sh. fork. resource temporarily unavailable.
We continue to work with JAMF on this. Its still ONLY Macs that have 10.12.6 as the OS X version (all hardware models affected). No resolution and really no progress on JAMF's end. We continue to send logs but no closer to resolution. Again.. this started happening right after our upgrade from 9.96 to 9.100. I have not tried chuinder's solution of deleting and then recreating the EA but that seems extreme, and also wont help the blank hardware section of the JSS record. And still no explanation why the binary freezes up the SSH tunnel when this occurs.
Is this possibly related to the macOS updates being misnamed?
Sounds a lot like what was happening on the 10.13 machines when they were collecting pending updates during inventory collection and a misnamed update was upsetting the database.
Disabling Collect available software updates under Inventory Collection resolved that (although of course you could no longer see pending updates on machines in the JSS).