How to force a recon after reboot of a Self Service Mavericks upgrade?

[tomt]

I'm probably missing something simple but it's just not coming to me at the moment.

Scenario: 10.6 and 10.7 machines being upgraded to 10.9 via Self Service. JSS is 9.61, DPs are all AFP.

Policies: I have one policy to cache the 10.9.5 installer onto the target machine. Then a second policy that removes an unwanted configuration profile (it was 10.7 specific) and then installs the cached OS.

Issue: Everything goes through just fine and the machine finally reboots into 10.9.5. I need it at that point to do an immediate recon so it will pick up the appropriate policies for installation.

I'm thinking along the lines of a single use launch daemon but haven't really worked with them before. Any pointers or (most likely better) ideas would be welcome.

Thanks,
TomT

[Josh_Smith · Accepted solution]

I had the same problem recently and resolved it with a LaunchDaemon that calls a script. I got help from Mike, the always helpful @mm2270 , in this thread: https://jamfnation.jamfsoftware.com/discussion.html?id=9987

I created a postinstallrecon.pkg that contains 2 items:

1. A Launch Daemon: /Library/LaunchDaemons/com.your.naming.convention.postinstallrecon_1.1.plist. This will call your script. If you are new to LaunchDaemons the GUI tool LaunchControl makes them pretty easy to work with.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
   <dict>
   <key>Label</key>
   <string>com.your.naming.convention.postinstallrecon_1.1</string>
   <key>Program</key>
   <string>/Library/Application Support/your_folder/postinstallrecon_1.1.sh</string>
   <key>RunAtLoad</key>
   <false/>
   <key>StartInterval</key>
   <integer>300</integer>
   </dict>
   </plist>

2. A script: /Library/Application Support/your_folder/postinstallrecon_1.1.sh
   You can put the script in any directory you like, I put mine in a subdirectory of /Library/Application Support. The script will check for a JSS connection, if it can't reach the JSS it will exit, and the LaunchDaemon will call the script again in 5 minutes. If it can reach the JSS the script will run recon, check for policies, then unload the LanchDaemon and delete the LD and the script itself. I removed all of the logging and just left the bare bones to post here:

   if /usr/sbin/jamf checkJSSConnection -retry 2
   then
       if jamf recon
           then
               jamf policy
               launchctl unload /Library/LaunchDaemons/com.your.naming.convention.postinstallrecon_1.1.plist
               rm /Library/LaunchDaemons/com.your.naming.convention.postinstallrecon_1.1.plist
               rm "/Library/Application Support/your_folder/postinstallrecon_1.1.sh"
               exit 0
   
   
           else
               exit 1
       fi
   else
       exit 1
   fi

Setup your policy for the update as normal. Don't include a recon, instead include your postinstallrecon.pkg and include a reboot.(This also has the added benefit of the Recon not slowing down the user facing potion of the Self-Service policy). This package is not tied to any particular upgrade and it cleans up after itself, so you can just add it to a policy whenever you need a post reboot recon.

[Look]

You could create an EA for machines with either the specific cached installs or any cached installs waiting (must be a way to check for this).
Create a smart group of machines waiting on cached installs.
Create a Startup triggered policy scoped to the above group to recon the machine.
Recon the machine after immediately after caching to ensure it is in the group.

As long as there are no other recon events you should end up with.
cache install > recon > join group > install > restart > recon > leave group.

[tomt]

I like this idea and will definitely work on it tomorrow when I'm back in the office. Temporarily dropping a machine into a recon at every startup group is a completely different direction than I was thinking.

Thanks!

[dpertschi]

This is a huge problem for me too in the fact that your inventory record will still report the old OS version until next recon, and there's no way I can set an inventory update to run at every login.

Please vote this up, it's in review…
https://jamfnation.jamfsoftware.com/featureRequest.html?id=771

[jennifer]

I set up a policy that is triggered at startup, and the only thing it does is run recon (Maintenance/Update Inventory). With the execution frequency set to ongoing, it will always update inventory when a machine restarts.

[dpertschi]

@jennifer_unger Yes that solves the stale inventory reporting problem, but for folks with large inventories and/or large data collections, this can ballon the database rather quickly.

Which is exasperated by the inability to specify or omit inventory criteria. https://jamfnation.jamfsoftware.com/featureRequest.html?id=78

[Josh_Smith · Accepted solution]

I had the same problem recently and resolved it with a LaunchDaemon that calls a script. I got help from Mike, the always helpful @mm2270 , in this thread: https://jamfnation.jamfsoftware.com/discussion.html?id=9987

I created a postinstallrecon.pkg that contains 2 items:

1. A Launch Daemon: /Library/LaunchDaemons/com.your.naming.convention.postinstallrecon_1.1.plist. This will call your script. If you are new to LaunchDaemons the GUI tool LaunchControl makes them pretty easy to work with.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
   <dict>
   <key>Label</key>
   <string>com.your.naming.convention.postinstallrecon_1.1</string>
   <key>Program</key>
   <string>/Library/Application Support/your_folder/postinstallrecon_1.1.sh</string>
   <key>RunAtLoad</key>
   <false/>
   <key>StartInterval</key>
   <integer>300</integer>
   </dict>
   </plist>

2. A script: /Library/Application Support/your_folder/postinstallrecon_1.1.sh
   You can put the script in any directory you like, I put mine in a subdirectory of /Library/Application Support. The script will check for a JSS connection, if it can't reach the JSS it will exit, and the LaunchDaemon will call the script again in 5 minutes. If it can reach the JSS the script will run recon, check for policies, then unload the LanchDaemon and delete the LD and the script itself. I removed all of the logging and just left the bare bones to post here:

   if /usr/sbin/jamf checkJSSConnection -retry 2
   then
       if jamf recon
           then
               jamf policy
               launchctl unload /Library/LaunchDaemons/com.your.naming.convention.postinstallrecon_1.1.plist
               rm /Library/LaunchDaemons/com.your.naming.convention.postinstallrecon_1.1.plist
               rm "/Library/Application Support/your_folder/postinstallrecon_1.1.sh"
               exit 0
   
   
           else
               exit 1
       fi
   else
       exit 1
   fi

Setup your policy for the update as normal. Don't include a recon, instead include your postinstallrecon.pkg and include a reboot.(This also has the added benefit of the Recon not slowing down the user facing potion of the Self-Service policy). This package is not tied to any particular upgrade and it cleans up after itself, so you can just add it to a policy whenever you need a post reboot recon.

[jpmaynar · Accepted solution]

As part of the Mavericks upgrade I run a simple command

touch /Library/Application Support/JAMF/Receipts/MavericksInstallPolicyRan.pkg | jamf recon

I have a smart group setup with the above pkg criteria.

Then I scope a startup inventory policy that will run once per computer for all computers in the smart group.

[Look]

@dpertschi A pretty simple solution I have been using for stale inventory is to make a smart group of Last Inventory date more than X days ago and then have a once daily policy that inventories any machine in the group. It means every machine will make a daily inventory but only if no other task has already inventoried the machine. I pretty much removed all other inventory tasks in policies except absolutely necessary ones (ie: an ongoing task based on a smart group). Seems reasonably effective.

[dpertschi]

@jpmaynar Now that looks like the simplest no fuss solution here. Long live the Dummy Receipt!

@Josh.Smith Ditto, and thank you for posting the full details. That's a good example of creating a self destructing LD! I hadn't revisited that thread or tried to figure out the LD/scripting business.

[tomt]

@jpmaynar][/url To echo what @dpertschiVF][/url said, that's a nice solution.

@Josh.Smith][/url I'll definitely use that as a reference for any future LDs I need to create.

Thanks to all who replied.

Edited to finish a sentence.

[GabeShack]

So I have a prepackaged jamf helper dameon that gets called at startup and locks out the login screen then runs a few extra installs and then runs a recon and a restart here it is below:

sudo rm -rf /Library/Application Support/JAMF/Receipts/Finish Upgrade Agent.dmg; sudo killall -m jamfHelper; sudo rm /Library/LaunchAgents/org.pps.donotinterrupt.plist; sudo killall loginwindow; sudo jamf recon; sudo shutdown -r now

Gabe Shackney
Princeton Public Schools