Inventory 10.9 Machines on First Logon

add a recon as a first boot script.

Create a simple LaunchDaemon and script that runs a jamf recon, and then deletes the daemon and itself.
The LaunchDaemon should simply have a RunAtLoad key and a ProgramArguments which runs the script.
Use Lingon or LaunchControl to create the LaunchDaemon
Lingon: https://jamfnation.jamfsoftware.com/viewProduct.html?id=148&view=info
LaunchControl: https://jamfnation.jamfsoftware.com/viewProduct.html?id=246&view=info

Wrap up the Daemon and the script into a package (pkg). Deploy that package along with your Mavericks upgrade workflow. When the Mac reboots, it should immediately run the inventory scan, even before any user logs in, then delete the LaunchDaemon and itself, so in effect, cleaning up.

Alternatively, you could simply leave them on the Mac, so they'll inventory every time they reboot.

Appreciate the follow-up. I will give this a try.

I have not had much luck with this. Since we leverage wifi (802.1x) as a primary connection, the start-up script is unable to reach our jamf server (I seem to be having similar issues with the logon trigger). As a workaround, I may just advertise a 'Mavericks Post Install' which includes the various 10.9 specific configuration scripts... any other ideas would be appreciated. Thanks!

@josaxo][/url][/url][/url][/url][/url, that tends to be an issue with machines that don't have hardwired Ethernet connections or otherwise may boot up off the network.
What I've done to get around this is put in a simple check up front in the script that does a jamf log
Have the script check the exit status. If successful, then move on to do the recon and clean up. Otherwise, exit until the next run. To have it run again in addition to the RunAtLoad, add in a StartInterval to the daemon. Say, every 30 or 60 seconds, etc.

#!/bin/bash

status=$(/usr/sbin/jamf log; echo $?)

if [ "$status" == "0" ]; then
    /usr/sbin/jamf recon
    /bin/rm -f /Library/LaunchDaemons/com.company.firstrecon.plist
    /bin/rm -f "$0"
else
    exit 0
fi

Hope that helps.

I'd do something similar to @mm2270][/url, but likely using NetCat to your JSS instead... something like:

#!/usr/bin/env bash
ServerStatus=$(nc -z $Server 8443 | grep -c "succeeded")
if [[ $ServerStatus > 0 ]]; then
    jamf recon
    rm -rfv $LaunchD_Plist
    rm -rfv "$0"
    sleep 10
    launchctl remove $LaunchD_Identifier
fi
exit 0

OK, so I've tested the script and although it forces the machine to check-in, it does not update the inventory. Should i include any additional commands besides recon?

That's odd. The jamf recon should be enough to gather new inventory.
Just to clarify, this is running after the Mac reboots and has been upgraded?
Are you testing the script manually or via a LaunchDaemon? If you're doing it via the latter, remember that it must be run from a LaunchDaemon, not a LaunchAgent, since only a daemon can run the script as root, which is required since you're doing s jamf recon in it.

Perhaps it is something in the script logic? If i run recon manually via terminal it updates the inventory as expected... if I run the script via terminal, the inventory does not update... I'm basically using your script, and updated it with my plist name:
#!/bin/bash

status=$(/usr/sbin/jamf log; echo $?)

if [ "$status" == "0" ]; then
/usr/sbin/jamf recon
/bin/rm -f /Library/LaunchDaemons/com.company.firstrecon.plist
/bin/rm -f "$0"
else
exit 0
fi

@c0n0r i assume i would need to customize your script to point toward my plist name?

I left the variables $Server, $LaunchD_Plist and $LaunchD_Identifier for you to replace with your custom info, or to be defined by you in the script.

How are you firing off the script? The script needs run are root, so if you aren't setting it up as a LaunchDaemon, you would need to fire off the script manually with the sudo command. To completely test it, I would suggest using:
sudo sh -x <path to script>
That should dump each line of the script, exactly as it's trying to be run, to be reported to StdOut.

I ran the script, and this is the result:
bash-3.2$ sudo sh -x /Users/myuser/Desktop/jamfrecon.sh
++ /usr/sbin/jamf log
++ echo 0
+ status='Logging to https://ourserver:8443/...
0'
+ '[' 'Logging to https://ourserver:8443/...
0' == 0 ']'
+ exit 0

Yeah, looks like its not picking up the exit status correctly in the variable. Odd though since echo'ing it out reports as "0" as it should. Splitting it up like above seems to work better.

As for the difference between jamf log or using nc, generally speaking it probably doesn't matter, but I think the important difference is that the jamf log ensures communication between the Mac and your JSS. It won't work if the Mac isn't enrolled and the jamf binary isn't there, so you'll get a non zero exit status. Whereas I can take any Mac on my network, not enrolled in my JSS and do a successful NetCat to the JSS. In other words, being able to NetCat it doesn't imply you can do a recon, whereas a successful jamf log typically does. Just my 2¢.

@c0n0r @mm270 Thanks for the help. With the updated code provided by conor, the script is now working as expected. This will help to streamline our 10.9 upgrade process. By the way, I ended up using Lingon to create the LaunchDaemon. Thanks again.

do you have a hidden management account? Did the 10.9 update remove it?
We use a hidden casper management account, and our 10.9 upgrades would remove it as the uid was under 500.
I setup a launch daemon script to check for the presence of the account and to run a script to recreate it if it does not exist, this was pushed out to all 10.8 machines before they were upgraded. Something to think about also

@clum_carey, it's strange that you're having the sub 500 Casper management account removed when doing upgrades to 10.9. If you check out the thread at https://jamfnation.jamfsoftware.com/discussion.html?id=8744 there are several people that haven't experienced that behavior. I wonder what the difference is between the process your using the the process that others are using. When I tested upgrading to 10.9 my sub 500 Casper admin account remained but I didn't do the upgrade by pushing it out out through Casper. It would be nice to know in what situations the account stays and what situations it gets removed.

Yeah, most of us have found that installing Mavericks in an update fashion doesn't delete any sub 500 accounts. If that's happening to you, you may want to investigate further, because all accounts from the field have shown that Apple stopped this practice with the 10.9 update, so that shouldn't be happening at all. Something else may be causing that.

Hmm will have to take another look. Have been using the same workarounds for so long they just become a habit and standard practice now. I'm not sure I even tested an upgrade from 10.8 to 10.9 without the script to recreate the management account. Thanks for the heads up, will test and confirm then its one less package I need to worry about in my workflow