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

tomt
Valued Contributor

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

2 ACCEPTED SOLUTIONS

Josh_Smith
Contributor III

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.

View solution in original post

jpmaynar
New Contributor III

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.

View solution in original post

11 REPLIES 11

Look
Valued Contributor III

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
Valued Contributor

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
Valued Contributor

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
Contributor

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
Valued Contributor

@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
Contributor III

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
New Contributor III

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
Valued Contributor III

@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
Valued Contributor

@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
Valued Contributor

@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
Valued Contributor III

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

Gabe Shackney
Princeton Public Schools