One of the issues that I occasionally run into in my shop is that sometimes the Casper agent on my Macs stop working properly. They stop checking in with the Casper server, or check in but can’t run policies anymore. I’ve set up smart groups on my Casper server to help me identify these machines, but actually fixing them has not been an automated process.
While at the JAMF Nation User Conference in October 2013, I was fortunate enough to hear Mike Dodge and Ajay Chand talk about the challenges they faced at Facebook with keeping Casper agents working in an environment where users are encouraged to break down any obstacle that gets in their way (sometimes, the obstacles in question were perceived to include the Casper agent.) As part of their talk, they mentioned they had a scripted way to verify that the Casper agent was running properly and automatically fix it if it wasn’t. This was a capability that I wanted to include in my own environment, so I asked them if this was going to be available at some point. They said it would be, so I waited to see what would be released.
At this point, the story fast forwards to March 2014, where the Facebook team was able to release their code to GitHub and I was able to take a look and see what they had done. I saw that I could adapt some of their work, but I would need to do additional work on my end to develop a solution that not only worked in my environment, but would be relatively straightforward to adapt to work in others’.
After a lot of work and testing, I’m happy to announce the release of CasperCheck. This is a script-driven solution that will do the following:
A. Check to see if a Casper-managed Mac’s network connection is live
B. If the network is working, check to see if the machine is on a network where the Mac’s Casper JSS is accessible.
C. If both of the conditions above are true, check to see if the Casper agent on the machine can contact the JSS and run a policy.
D. If the Casper agent on the machine cannot run a policy, the appropriate functions run and repair the Casper agent on the machine.
For more details, see below the jump.
As covered previously, Greg Neagle’s createOSXinstallPkg is a useful tool for installing or upgrading Mac OS X in a variety of situations. One of the nicer features is that you can edit the OS X installer to install additional packages.
However, the limitations of the OS X install environment mean that there are a number of installers that won’t install correctly. In particular, packages that rely on pre- or postflight scripts to perform important tasks may fail to run properly in the OS X install environment.
To help work around this limitation, I developed First Boot Package Install.pkg, an installer package that enables other packages to be installed at first boot. It’s designed for use with createOSXinstallPkg with the goal of allowing installer packages that can’t run in the OS X Install environment to be incorporated into a createOSXinstallPkg-using deployment workflow.
The first version of First Boot Package Install.pkg had some limitations though, with the biggest one probably being that you couldn’t tell what it was doing when it was running. Instead, all that was displayed was the gray Apple loading screen.
I tried various approaches of booting into verbose mode and writing log entries to the console, but none of the approaches were good enough to introduce into production. Fortunately, Per Olofsson developed exactly what I was looking for with his LoginLog tool.
Using LoginLog.app as a way to display updates to the user, I’ve been able to update First Boot Package Install.pkg with improved visual feedback. I’ve also now incorporated another piece of feedback I’ve received, which is to add a network check. This new check makes sure that the Mac has a network address other than 127.0.0.1 or 0.0.0.0 before it proceeds to install any packages. For more details, see below the jump.
Microsoft has released Microsoft Lync 14.0.8, which included compatibility with Mavericks. Since we have several folks using both Lync and Mavericks, I wanted to get this into our Casper server’s Self Service as soon as possible.
To test installing it, I downloaded the installer on a disk image from Microsoft’s site, then renamed the package from Lync Installer.pkg to Lync 14.0.8 Installer.pkg. After renaming it, I set up an installation policy for Self Service, scoped the policy so that only my test machine could see it, then ran the installation.
I go check the logs and see this entry:
/usr/sbin/jamf is version 8.73 Executing Policy Microsoft Lync... [STEP 1 of 2] Downloading BOM for Lync 14.0.8 Installer.pkg... This Apple Package did not have a valid index.bom file. Assuming it is a flat file package. Downloading http://casper.server.here/repo_name/Packages//Lync 14.0.8 Installer.pkg... Error: The package could not be found on the server. [STEP 2 of 2] Running Recon... Displaying message to end user...
OK, maybe I did that wrong. Deleted the package and this time uploaded the installer to my Casper server without changing the name from Lync Installer.pkg.
/usr/sbin/jamf is version 8.73 Executing Policy Microsoft Lync... [STEP 1 of 2] Downloading BOM for Lync Installer.pkg... This Apple Package did not have a valid index.bom file. Assuming it is a flat file package. Downloading http://casper.server.here/repo_name/Packages//Lync Installer.pkg... Error: The package could not be found on the server. [STEP 2 of 2] Running Recon... Displaying message to end user...
Failed again. Meanwhile, /var/log/install.log on my test Mac only showed that installd was starting and then stopping. In short, Casper’s logs were right; the installation process was starting but couldn’t then find a package.
At that point, I started thinking. How would the developer have installed this package? How did Q&A likely test installing it, however minimally?
Developer – Would have double-clicked on the package to install it, followed by typing in an admin password.
Q&A – Same process as the developer, except they would have tested installing it from the mounted disk image.
I recently learned about how to use Parameter Labels as part of a JAMF training class. I had read about them in the Casper Administrator’s Guide but managed to fundamentally misunderstand what they did and how they work.
What I thought:
Adding a Parameter Label value to a script in Casper Admin meant that the associated variable value would be pre-set for the script when I added it to a policy.
I didn’t want this behavior, as I wanted to maintain flexibility when setting policies. Consequently, I didn’t set anything in the Parameter Label value for my scripts.
How they actually work:
Setting the Parameter Label value in Casper Admin means that you’re changing the label that shows up in the script parameters in a policy. For example, changing the Parameter Label value for Parameter 4 in Casper Admin to Username means that the parameter name for the script will change from Parameter 4 to Username when you add the script to a policy.
Here’s how to set Parameter Labels in Casper Admin:
1. Open Casper Admin
2. Select the script you want.
3. Click the Info button.
4. Click the Options tab.
5. Set the parameter you want to change to the desired name.
6. When you create a policy that uses that script, the parameter will have the name you set instead of the default parameter name.
I do a lot of work with payload-free packages and I’ve looked for a while for a tool that would let me easily create them from existing scripts. While I have a process for creating them as needed with pkgbuild, this approach still requires some setup work.
After thinking about it and taking a look at various approaches, I’ve developed Payload-Free Package Creator.app, an Automator application that will allow the selection of an existing script and create a payload-free package that runs the selected script. For more details, see below the jump.
For the past few major releases, Sophos used a standard installer package to install both their free and paid antivirus solution. With the release of Sophos Anti-Virus 9.x though, Sophos changed how their antivirus solution for Macs was installed by switching to using an application to install it. For their customers using Sophos Enterprise Console, Sophos will still provide a installer metapackage, but all other customers now need to use the application to install Sophos Anti-Virus 9.x on Macs.
Curiously, Sophos went to some lengths to make their install application look like a standard installer package.
This extended to the point of naming the actual application as Installer, which is the same name as Apple’s Installer.
This switch away from using installer packages was a problem for Mac admins who wanted to deploy Sophos 9.x, but did not have Sophos’ enterprise console. After doing some research and reading a very helpful thread on JAMF Nation, it looks like it is possible to repackage Sophos 9.x for deployment. For more details, see below the jump.
In my shop, we use a Xerox color copier/printer along with a number of Canon ImageRunner printers. Like the Canons, I have the Xerox printer available in Casper’s Self Service so that our users can set this printer up themselves on their Macs. When I recently overhauled my Canon printer setups, I decided to also revisit how Self Service handled setting up the Xerox printer. Unlike our Canon printers, our Xerox printer used LPR already so I figured that getting the right drivers deployed should be straightforward.
Then I looked at Xerox’s driver page and saw three different driver installers available:
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
I wanted to maintain roughly the same workflow as I had with the Canon printers, but I also wanted to make sure that the OS-appropriate driver was delivered to each Mac.
For details on how I addressed this, see below the jump.
In my shop, we use a number of Canon ImageRunner printers and have them set up in Casper’s Self Service so that our users can set them up themselves. All of the Canon printers in question have PostScript enabled, so I’ve been deploying the Canon PostScript drivers.
Historically, one of the things that was installed along with the drivers was a proprietary printing application that sat between the Mac’s CUPS printing system and the actual printer. That changed with the release of Canon’s 4.x PostScript drivers. With the new drivers, Canon has switched to using LPR and no longer uses that proprietary printing application.
Good news: Canon is no longer building in a custom printer program to handle talking to the printer; instead the new drivers are using LPR.
Bad news: Our existing printer setups that are available in Self Service do not work with the new printer drivers. I would need to delete and re-add our various printers to Self Service.
The bad news wasn’t a big problem by itself, but my testing showed that updating the printers in Self Service to accommodate the new printer drivers would make them no longer backwards-compatible with the old drivers. The new drivers would need to be installed in order for the new printers to work. Conversely, just pushing out the new drivers to our Macs could result in existing printer setups breaking.
In short, here were the problems I was looking at:
1. The old printer setups could not use the new drivers
2. The new printer setups could not use the old drivers
3. The new drivers needed to be installed before the new printer setup happened.
4. I didn’t want to break existing printer setups if I could avoid it.
Making the new drivers available in Self Service as standalone installers wasn’t an issue but I was concerned about adding them to the printer setups themselves. That potentially could result in the printer drivers being installed over and over again as people set up multiple printers on one Mac. I also wanted to avoid problems with accidentally trying to overwrite newer drivers, in the event that Canon released new drivers and someone installed them before I updated the driver installer in Self Service.
For details on how I addressed this, see below the jump.
Oracle’s Java 7 Update 51 has introduced new security requirements for browser plugins for applets and web start applications. However, not all applets are able to run using the new requirements. To help with this, Oracle has included a way to whitelist specific sites using Java 7’s new Exception Site List. This allows the applets and web start applications hosted on the specified sites to continue to work, even if they don’t meet the new security requirements in Java 7.
On Mac OS X 10.7 and higher, the Exception Site List is a plaintext file named exception.sites, which is stored in /Users/username/Library/Application Support/Oracle/Java/Deployment/security.
To help Mac admins manage the Exception Site List, I’ve written a script which is designed to add websites to Oracle’s Java 7’s Exception Site List without overwriting existing entries. For more details, see below the jump.
If you want others to be able to temporarily use your computer, but you don’t want to create an account for each user, Mac OS X allows you to create a guest account. This guest account allows a person to log in to the Mac without entering a password, but the account type has the following limitations:
- Guest users can’t make changes to other user accounts.
- Guest users can’t change setting on the computer.
- Guest users can’t log in remotely.
- Files created by guest users are deleted when the user logs out. As part of this, a temporary home folder is created for the guest’s files but this folder and its contents are deleted when the user logs out.
By default, OS X only allows the creation of a single guest account with the name of Guest. That said, it is possible to create custom guest accounts with names that are different from Guest. This would allow Mac admins to create multiple guest accounts if needed. See below the jump for more details.