Home > Bash scripting, Casper, Linux, Mac administration, Mac OS X > Upgrading from Casper 8.73 to 9.32

Upgrading from Casper 8.73 to 9.32

Since Casper 9.x was first released, I’ve been preparing for my shop’s own upgrade from Casper 8.x to 9.x. As of the morning of Saturday, June 28th, those preparations have ended with my shop’s successful upgrade to Casper 9.32. When I mentioned this on Twitter, I heard from a few folks who mentioned that they were planning to also do this in the near future and @theycallmebauer asked if I was going to post about my experience.

Screen Shot 2014-06-28 at 3.48.47 PM

I thought that was a good idea, so please see below the jump for the details.

The biggest lessons I took away from the experience were these:

1. Having a test environment is essential.

I have two Casper test environments to help with me with my testing. The first was a Casper 9.x server hosted at my home. It did not replicate my work environment, but it allowed me to test new Casper 9.x releases on a small scale. If something blew up, it was no big deal as the only things affected were the VMs I was testing with.

The second was my test environment at work. This used a Casper 9.x server that replicated as closely as possible my production environment. If something didn’t blow up in my home test environment, the next step was to try it in my work test environment.

Between the two environments, I must have installed every version of Casper 9.x at least once. I also must have rolled back my work test environment to 8.73 about three or four times to help me practice upgrading to various versions of 9.x.

2. Surprises are bad. Test as much as you can to find issues.

I found a few things that worked in Casper 8.73 that either didn’t work or didn’t work like I expected them to. For example, in Casper 8.73 you can have a message pop up once Self Service policies are finished running. You can also have messages be displayed when policies are run in Casper 9.x, but for whatever reason, they won’t appear when those policies are run through Self Service.

Since I like to have “Hey, this is done,” messages appear for my users when Self Service policies finish running, I needed to figure out a way to have the messages appear in Casper 9.x. After some work, the answer I preferred was to have a script like the one below set to run after the Self Service policy’s main action:

#!/bin/bash

# This script displays a message that lets the user know that 
# a printer setup policy has finished. It is set to the lowest
# priority to ensure that it runs last after all other scripts
# and policy actions.

printer_name="$4"

/usr/sbin/jamf displayMessage -message "The $printer_name printer has now been set up on your Mac."

exit 0

In this case, $4 would pass along a name which I had set on the Casper server’s end. That worked fine, until I discovered that the jamf displayMessage -message command didn’t appear to work right in Casper 9.32 on 10.5.x and 10.6.x Macs. After discussing it with JAMF’s support, I decided to use jamfHelper for my 10.5.x and 10.6.x Macs, while using jamf displayMessage -message on 10.7.x and higher. With an OS check thrown in, my updated message script looked like this:

#!/bin/bash

# This script displays a message that lets the user know that 
# a printer setup policy has finished. It is set to the lowest
# priority to ensure that it runs last after all other scripts
# and policy actions.

# Determine OS version
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')

printer_name="$4"
dialog="The $printer_name printer has now been set up on your Mac."
description=`echo "$dialog"`
button1="OK"
jamfHelper="/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper"
icon="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertNoteIcon.icns"

if [[ ${osvers} -lt 7 ]]; then

  "$jamfHelper" -windowType utility -description "$description" -button1 "$button1" -icon "$icon"

fi

if [[ ${osvers} -ge 7 ]]; then

  jamf displayMessage -message "$dialog"

fi

exit 0

For those interested, I have my message scripts posted to GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/message_display_scripts

Another issue I found in 9.32 was with how Casper-passed parameters were interpreted. In particular, I saw an issue in Casper 9.32 where Parameter 6 is seemingly being read as Parameter 7 in scripts. I verified that the problem did not happen on Casper 8.73 with the identical script used with an identical policy.

Script used:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/install_company_xerox_printer_drivers

Blog post that explains how the script is used with Parameters 6 and 7:

http://derflounder.wordpress.com/2014/02/10/deploying-xerox-print-drivers-on-a-per-os-basis-via-caspers-self-service/

Where the parameters were coming into play was that Xerox provided several different versions of their print driver that I was using in my shop:

For 10.5.x – Xerox Print Driver 2.94.3

For 10.6.x – Xerox Print Driver 2.112.0

For 10.7.x through 10.9.x – Xerox Print Driver 2.113.0

When I ran my Casper 9.32 printer setup policy on a 10.6.x Mac, it reported that it did not detect that Xerox Print Driver 2.113.0 was installed and triggered a second policy to install drivers before the original policy proceeded with setting up the printer. The second policy correctly installed Xerox Print Driver 2.112.0 because that was the only option available for 10.6.x Macs. If the Casper 9.32 printer setup policy was re-run, it again reported that it did not detect that Xerox Print Driver 2.113.0 was installed and triggers the second policy to install the 2.112.0 drivers again.

Replacing the $6 value in the script with a hard-coded “2.112.0” allowed the script to correctly detect that Xerox Print Driver 2.112.0 is installed. An identical Casper 8.73 policy and identical script worked properly and passed along $6 as being 2.112.0.

JAMF Support confirmed that they were seeing the same issue and that the solution for now was to hard-code it.

Screen Shot 2014-06-28 at 4.39.42 PM  

3. You don’t have to do everything at once.

As I found issues in testing, or learned about new functions and features, I tried to see if I could incorporate them into my existing Casper 8.73 setup. A good example of this had to do with MySQL. When I started the process, my Casper server was running the following:

Red Hat Enterprise Linux Server release 6.0 (Santiago)

MySQL 5.1.47

However, I looked ahead to Casper 9.x and saw the following versions of MySQL were now listed as being required:

MySQL Enterprise Edition 5.5 or later, or MySQL Community Server 5.5 or later

Since I didn’t want to deal with a MySQL upgrade at the same time that I was doing an upgrade to Casper 9.x, I went ahead and upgraded my Casper production server to use MySQL 5.5.

Another example of prior preparation had to do with the messages in Self Service. The nice thing there was that all of the scripts worked fine in 8.73 as well. Instead of having to do all the work of updating my scripts as part of the upgrade process, I could update my Self Service policies to use the scripts in Casper 8.73 and have both the policies and the scripts all be brought into Casper 9.x when I upgraded.

The Upgrade Process

When the time came to actually do the upgrade to Casper 9.32, here’s what I did to make the process go smoothly:

Pre-upgrade work:

  • Made a snapshot backup of my work’s Casper production VM
  • Verified that the previous night’s automated database backup ran successfully
  • Purged all Casper database logs older than one week
  • Performed a manual backup of the Casper database using the JSS Database Utility
  • Rebooted the Casper production VM

Upgrade work:

  • Ran the Casper 9.32 Linux installer on my RHEL VM to upgrade Casper from 8.73 to 9.32​
  • Migrated the Casper installer repository using Casper Admin to compress non-flat packages and move scripts from the repo to their new storage location in the Casper database.​
  • Created new Casper QuickAdd installer package with Casper Recon

Post-upgrade work:

  • Verified that a sampling of workstations running 10.5.8 through 10.9.3 had upgraded themselves to the 9.32 Casper agent.​​
  • Verified that a sampling of workstations running 10.5.8 through 10.9.3 were all able to run an inventory update and send it to the upgraded Casper 9.32 server.​
  • Verified that CasperCheck was able to detect and download the new QuickAdd installer package.
  • Verified that my policies were running as expected and that the Self Service messages were popping up as appropriate.

I’m indebted to those folks who went before me, as they helped find and fix a number of issues that I didn’t have to deal with as part of my upgrade process with 9.32. For those who have yet to upgrade to Casper 9.x, hopefully this information helps you out in your own upgrade process.

  1. June 30, 2014 at 1:40 pm

    Well, for one thing, it sounds like it’s relatively painless at this point (as compared to our fellow admins that did this with prior 9.x releases and ran into trouble). Thanks for sharing, Rich.

    Do you use directory credentials to log into Admin, or an account local to the JSS? If the former, did you do your package migration with that account, and did it succeed?

    • June 30, 2014 at 1:44 pm

      I used my AD account to log into Casper Admin and do the package migration. No issues were seen, it just took an hour and a half.

      The lion’s share of the time was spent on migrating AAMEE-built Adobe CS installers.

  2. Matt Bauer
    July 6, 2014 at 11:09 pm

    Thanks for the shout-out, Rich!

    Great to hear the process *is* much smoother now. I’ve been a little worried with how well the test upgrades have gone with my dev JSS and had this nagging feeling there’d be some kind of gotcha when I upgraded prod. Really reassuring to see you’re using a similar upgrade process and it almost all went as expected.

    Nice find with the $6 issue! I’ll be inspecting and testing scripts in dev tomorrow to make sure I don’t get bit by that during the upgrade.

  3. Tom
    July 8, 2014 at 3:33 am

    Nice write up Rich! I cannot express your point more, you gotta test this stuff. Version 9 is a complete code rewrite, a new and improved database schema. I have done a ton of version 9 upgrades for customers and I always start with a clean up process. Get rid of anything you don’t need. Smart Groups, saved searches, profiles/mcx, and anything else that is considered legacy. Flush logs you don’t need, and make sure your database has no existing issues (table checks, optimizations, etc), because items will get moved around, tables will merge and drop, and encryption and hashing will be applied. Tons has changed under the hood as well, that may not even be that clear to the administrator. With a good portion of these changes being security minded. As always, thanks for your contributions to the community, when you are out in California next let me know and I will buy you a beer, and we can catch up on some project talk.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 155 other followers

%d bloggers like this: