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@theycallmebauerasked if I was going to post about my experience.
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.73about 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,$4would pass along a name which I had set on the Casper server’s end. That worked fine, until I discovered that thejamf displayMessage -messagecommand 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 usejamfHelperfor my 10.5.x and 10.6.x Macs, while usingjamf displayMessage -messageon 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 versionosvers=$(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"fiif [[ ${osvers} -ge 7 ]]; thenjamf displayMessage -message "$dialog"fiexit 0For 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$6value 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$6as being2.112.0.
JAMF Support confirmed that they were seeing the same issue and that the solution for now was to hard-code it.
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:
Upgrade work:
Post-upgrade work:
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.
So implementieren Sie Farbschriftarten in CSS
So entsperren Sie das Oppo-Telefon, wenn ich das Passwort vergessen habe
Daten vom Android-Telefon auf das Apple-Telefon migrieren
Gründe für eine DNS-Ausnahme
Verwendung der MySQL-Datediff-Funktion
Der Unterschied zwischen Powershell und cmd
system()-Funktion
Einführung in CLI-Befehle
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
