Archive
Using lpoptions To Identify Printer Options
In my previous post on adding printers via script I mentioned using lpoptions to identify the different option settings for a printer. Let’s open up Terminal and get started with identifying the options. You’ll need to have the printer already installed on the system, so if it isn’t installed go follow my previous post and get it installed.
First, let’s find the name of the printer. For that we will use lpstat -a:
Now that we know the name, Wayne_HOLD, let’s figure out what the options are that we can set. For that we’ll use lpoptions -p Wayne_HOLD -l. Now this list is way too much information to post here, so I’ll just cut it off at a few lines:
Wow, and there’s plenty more information beyond this. This part of setting the options can be a bit trial and error. We probably aren’t going to want to set everything, but we will want to add any options like the “Fiery Graphic Arts Package” that is installed, or the “Output option”, or perhaps the “Xerox high capacity feeder”.
One way we can figure out what option we need to set is by using grep along with the lpoptions command. For example, to know which option sets the “Fiery Graphic Arts Package” we might try this:
lpoptions -p Wayne_HOLD -l | grep -i "graphic arts"
This gives us the following:
That’s great, but what does “GA2” and “GA1” mean? Open up the Options & Supplies window for the printer by going to System Preferences -> Printers & Scanners -> click on the printer and then click on the Options & Supplies button. For this printer, we can see that “GA1” is the “Fiery Graphics Arts Package”.
What happens when we change that in the GUI to:
This is what we see from Terminal:
So now we know that the “GA2” option is the “Fiery Graphics Arts Package, Premium Edition”.
For other settings we need to do some investigation in the Print pane when printing a document. For most printers we’ll want to see what the default view is in the Print dialog window and then make the change in the Terminal using lpoptions and finally go back to the Print dialog window to see what that change did.
In our case we want to set the Output option and the High Capacity Feeder option from their default settings:
To use a high capacity paper source, and to put the output in a different tray:
Notice that in the second screen shot we now have Tray 6 available to us. We can acheive this using the lpadmin command to set the settings (note: the lpoptions command works most of the time, but I have far more success using lpadmin).
By figuring out which settings we want to use, we can now configure all of the options for a printer from a script. One more example would be setting a color printer to default to B&W and duplex print. This is often done as a cost savings measure.
| lpa='/usr/sbin/lpadmin' | |
| ${lpa} -p CopyThat -E -o printer-is-shared=false -v lpd://10.89.170.5 \ | |
| -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 7855.gz" | |
| ${lpa} -p CopyThat -o Duplex=DuplexNoTumble -o XROutputColor=PrintAsGrayscale |
I hope this has inspired you to dive further into setting up printers via script.
Identify EFI Fiery Driver
In this post I talked about how we can use the lpadmin command to add a printer via script. In this post we will cover how we can identify the driver for an EFI Fiery RIP. Note: all Fiery RIPs do not use the same driver, so you will want to follow this process for any Fiery you may have in your environment.
Open your favorite web browser and enter the IP address (or DNS name) for the printer. This should take you to the Fiery RIP webpage.
Now, click on the Configure tab, then on the “Check for product updates” link.
This will open up a new tab in your browser that will take you to the EFI Fiery live update page. From here you’ll want to click on the Printer Drivers tab and then scroll to locate the latest printer driver.
We’ve scrolled down to locate the latest driver that handles macOS 10.14 Mojave.
We can then click the Download link to download the latest version of the Fiery driver for our specific model of Fiery.
One Last Thing
Now that you have your driver downloaded, I would strongly suggest heading over to Foigus’ post, Trial By Fiery, to find out how to use AutoPKG to create a driver package that will install via a management tool, and not have update dialogs popping up.
Deploying Printers via Script
Deploying printers on the Mac in an enterprise environment, or heck, just in a small office environment, can be done in multiple ways. If you don’t have a management tool, or ARD, you’re going to be running around doing it by hand. If you have a management tool, like Munki or Jamf, then you can deploy printers in a more automated fashion. My preferred method is to use a Bash script to deploy printers because it provides me a little more flexibility
Identify The Driver
The first thing to do is to identify the printer and the driver that is required. For most printers this is pretty simple, just navigate to the IP address of the printer to verify the make and model, then head over to the vendor’s website to download the latest driver. Once you have the driver, install it on your machine and then go find the driver file on your system. On the Mac, most printer drivers are stored in:
/Library/Printers/PPDs/Contents/Resources
If your printer has a “RIP”, or “Raster Image Processor“, identifying those drivers can be a little trickier. Head over to this post on how to identify the driver, and download it, on an EFI Fiery RIP. Drivers for an EFI Fiery or other RIP are usually stored in:
/Library/Printers/PPDs/Contents/Resources/<localization folder>
For us here in North America, that folder path would be:
/Library/Printers/PPDs/Contents/Resources/en.lproj
Once you have identified the driver, copy the full path of the driver file (Option-Command-C, or hold down Command then Edit->Copy as Pathname, or right click while holding Command) to your clipboard.
Build The Command
The next thing we need to do is figure out the command to run to add the printer. Fire up Terminal and let’s figure out the commands to use. We will utilize the lpadmin command to get the printer on the system. For this post this is what our command will look like:
sudo lpadmin -p <name> -E -o printer-is-shared=false -v ipp://1.1.1.1 -D "<name>" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz"
That looks a little daunting, so let’s break it down a little bit.
-p <name> This flag sets the name of the printer as seen by the cups process. Use a name with no spaces, or substitute underscores for the space.
-E This flag enables the printer to accept jobs
-o printer-is-shared=false The -o flag allows us to pass options to the printer. In this case we are making sure the printer is not shared on the network.
-v ipp://1.1.1.1 The -v flag sets the URI of the printer.
-D <name> Where -p set the name the cups process saw, the -D flag sets what I call the “friendly” name, the name that is visible in the GUI.
-P <driver path> Pretty self explanatory, the -P flag sets the path to the driver.
Now that we have everything, run the command in Terminal to add the printer. You can verify the printer added by using the lpstat -a command. With the printer added, open up a program and send a test print to the printer. It is important for us to do this step so that we know our handy work is working properly.
Put It In A Script
Let’s get to the script to add the printer. Open your favorite code editor (TextMate or Sublime Text for me) and start a new script. I utilize Bash, but you could just as easily do this in Python if you prefer. First we want to make sure the proper driver is on the system, and if it isn’t we want to install it.
| if [[ ! -f "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" ]]; then | |
| /usr/local/bin/jamf policy -trigger xeroxGenericDriver | |
| fi |
If the driver file is not on the system, we call the jamf binary to trigger our install policy. Adjust this to fit your management toolset.
Now with the driver check complete, we use a case statement to choose the printer (or printers) to install. We pass the choice to the script using Script Parameters in our Jamf Pro server policy. Here’s an example showing how we can install one printer, or multiple printers in an office.
| lpa='/usr/sbin/lpadmin' | |
| case $printer in | |
| Printer1) | |
| ${lpa} -p Printer1 -E -o printer-is-shared=false -v ipp://10.1.1.1/ipp/print \ | |
| -D "Printer1" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ;; | |
| Printer2) | |
| ${lpa} -p Printer2 -E -o printer-is-shared=false -v ipp://10.1.1.2/ipp/print \ | |
| -D "Printer2" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ;; | |
| OfficePrinters) | |
| ${lpa} -p Printer1 -E -o printer-is-shared=false -v ipp://10.1.1.1/ipp/print \ | |
| -D "Printer1" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ${lpa} -p Printer2 -E -o printer-is-shared=false -v ipp://10.1.1.2/ipp/print \ | |
| -D "Printer2" -P "/Library/Printers/PPDs/Contents/Resources/Xerox WorkCentre 5955.gz" | |
| ;; | |
| esac |
You can hopefully see the flexibility this provides us for using one script to install multiple printers. Sure, we still have multiple policies in the JPS, but rather than have multiple printers or multiple scripts as well, we can do this with just the one. And, when a printer needs to change, we just edit the script.
Bonus Round
What about adding printer options, like paper trays or output trays or setting a printer to B&W instead of color? We can use lpoptions to figure out what those options are and to set them. Since that can be a daunting task, head over to this post about using lpoptions to identify the settings.
Hopefully this post has helped you evaluate the use of a script to add printers and has given you a new tool for your toolbox.
Custom CrashPlan Install With Casper
I’m a fanboy. There, I said it and I’m proud of it. I’m a fanboy of JAMF Software’s Casper Suite. I’m also a fanboy of Code42 and their CrashPlan software. Put them together and it’s like when the two teens discovered peanut butter and chocolate as an amazing combination.
I am all about trying to minimize the amount of time my users need to be interrupted due to IT needs. That’s a large part of the reason we use Casper, so that my users do not have to be inconvenienced. Let’s face it, the more time I take performing IT tasks on their computer that cause them to not be able to work, the less money they are making for our agency. It’s one of my primary tenets of customer support: make every reasonable effort to not disturb the end user, period. So when I discovered several of my end user machines were not backing up via CrashPlan, I needed to find a way to deploy CrashPlan with as little interruption as possible. In steps Casper and CrashPlan together.
Our original setup of CrashPlan that has been running for several years, was setup using local logins. At the time when we first deployed, we were not on a single LDAP implementation, so I didn’t want to deploy an LDAP integrated CrashPlan. Fast forward to now, and we have a single LDAP (AD) and I want to take advantage of that implementation to provide “same password” logins for my users.
Fortunately JAMF has a technical paper outlining how to do this, titled Administering CrashPlan PROe with The Casper Suite. This paper was written back when CrashPlan PROe was still a thing. With the release of version 5 of CrashPlan, it has now become simply Code42 CrashPlan. This document still works for the newer version of the software.
Get The Template
The first step is to get ahold of CrashPlan custom template for the installer. Following the paper, you can download the custom template by navigating to this URL:
http://YourServerAddress:4280/download/CrashPlanPROe_Custom.zip
NOTE: If you are deploying version 5 or higher of CrashPlan, you can use this URL to download a newer version of the kit:
http://YourServerAddress:4280/download/Code42CrashPlan_Custom.zip
While there are two different URLs, you can use either one to customize your install.
Edit Away
After downloading and expanding the zip file, you will need to edit the userInfo.sh file to set some settings. First of which is to hide the application from your users during installation. Simply set the following line:
| startDesktop=false |
The next thing you will want to edit are the user variables. CrashPlan uses these variables to grab the user’s short name and their home folder location. An assumption is made when it comes to the user’s home folder, and that is the assumption that the home folder lives in /Users. If your home folders do not live there, or you want to script the generation using dscl, you can. I’m lazy and so I simply went with the /Users setting.
Also, the method to grab the user short name is based on the user that is logged in currently. Now, we didn’t discuss before how you were deploying this via Casper (login, logout, Self Service, etc), but suffice it to say, it is preferable to deploy this when a user is logged in to the computer. There have been many discussions on JAMF Nation about CrashPlan and how to grab the user, I used the information found in this post to grab the info I needed:
| user=`/usr/bin/defaults read /Library/Preferences/com.apple.loginwindow lastUserName` | |
| CP_USER_HOME="/Users/$user" | |
| userGroup=`id -gn "$user"` | |
| CP_USER_NAME="$user" |
Now that you have the edits done, keep going through the technical paper, running the custom.sh script next to build the Custom folder we will need in a minute, and to download the installers. The custom.sh script will download the installers for Windows, Mac, and Linux, and slipstream the Custom folder into the installer package for us. In our case, since we are only concerned with the Mac installer, it places a hidden .Custom folder at the root of the DMG. We want that folder. So follow along in the tech paper to mount the Mac installer DMG and copy the .Custom folder out somewhere.
Package It All Up
We are going to need to deploy these custom settings alongside the CrashPlan installer. The tech paper has you using Composer (no surprise since it is their product), but I personally like to use Packages for my packaging fun. I’m not going to get into a discussion about what the best packaging method is, because that’s like debating which Star Trek movie was the best.
Using your method of packaging, create a package that drops that Custom folder (notice we are dropping the period so it is not hidden) into the following location:
/Library/Application Support/CrashPlan
Now that we’ve got our custom settings, we can move over to the JSS to work on our deployment. I’m going to skip discussing how to do this via Self Service, and instead stick with either a Login trigger or Recurring Check-In trigger. But first things first, go ahead and upload that custom settings package you just created into the JSS. Once it’s uploaded set the priority to something low, like 8:
Create Your Policies
The tech paper discusses uploading the CrashPlan installer along with the custom properties, but I like the method that is discussed in this JAMF Nation post. It’s towards the bottom, and basically it uses curl to download the installer from the CrashPlan server. This method insures you have the latest version for your server. Of course, if you are trying to deploy to end users around the globe that may not have curl access to your CrashPlan server, uploading the installer to Casper may be your only option. For me, however, it was not.
First step is to create a new script in the JSS (or upload a script if your scripts are not stored in the database). The script itself is nothing special, it checks for the presence of the CrashPlan launch daemon, and if it is there unloads it and removes CrashPlan. Then the script continues on to install the custom properties (via a second policy) and finally installs CrashPlan:
| #!/bin/sh | |
| # unload CrashPlan LaunchDaem if it exists | |
| if [[ -e /Library/LaunchDaemons/com.crashplan.engine.plist ]]; then | |
| launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist | |
| /Library/Application\ Support/CrashPlan/Uninstall.app/Contents/Resources/uninstall.sh | |
| rm -rf /Library/Application\ Support/CrashPlan | |
| fi | |
| # install the custom properties folder | |
| jamf policy -event CrashInstall | |
| # now install CrashPlan | |
| curl http://yourserveraddress:4280/download/Code42CrashPlan_Mac.dmg > /var/tmp/CP.dmg | |
| hdiutil attach /var/tmp/CP.dmg | |
| installer -pkg /Volumes/Code42CrashPlan/Install\ Code42\ CrashPlan.pkg -target / | |
| hdiutil detach /Volumes/Code42CrashPlan | |
| rm -rf /var/tmp/CP.dmg |
As you can see, I’m using a second policy to install the custom properties. You could do everything with one policy and two scripts, or one policy and curl the custom properties from another location. The key point is that if you are removing an existing installation (like I was), you cannot install the custom properties until you are done removing the existing. Make sense?
Now that we have all of our pieces and parts up there, you will create your two policies, one to install the custom properties and the other to run the script.
To Trigger Or Not To Trigger
With your policies created, you now need to determine how you want to trigger these policies. Obviously you will need to trigger one from within the script, but what about the main policy that kicks it all off? Well, I would probably do this via a recurring check-in trigger. It keeps the user from having to wait for the policy to complete before their login completes.
Of course, you could use the login trigger and throw up a nice notification using jamfHelper, Notification Center, or CocoaDialog. That sounds like a nice post for another day.
I Didn’t Do It
I cannot take the credit for this process. It was people like Bob Gendler and Kevin Cecil on JAMF Nation, along with the folks at JAMF and Code42, that did the heavy lifting. I just put it all into one location for me to remember later.
Upgrading Adobe Flash Player
Recently on JAMF Nation there was a discussion about the Adobe Flash Player Distribution site going away. This site is where admins can go to get a copy of Flash that can then be legally distributed to their fleet of machines. The discussion started out to be about the change Adobe recently made to the URL for this site, but quickly turned to a discussion around distribution of Flash via Casper.
While I have signed up for the Adobe distribution site, I currently utilize a PKG file that comes from AutoPKGr (I replaced my Jenkins install with AutoPKGr last year sometime). Utilizing AutoPKGr makes my life easier, because I do not have to do anything except update my policy to replace the actual PKG file. I’m not going to go into setting up AutoPKGr for use with Casper, there have been plenty of discussions on that, but rather I am going to list out my procedures for processing Flash upgrades.
It’s Upgrade Day
I typically find out that there is a Flash upgrade from JAMF Nation. Someone typically posts that there is a Flash update almost immediately upon release. Once I’ve verified that the update has been uploaded to my JSS by AutoPKGr, I will go update my policy, changing out the PKG file.
As you will see, the policy is set to trigger on “Recurring Check-In” because I don’t care if a web browser is open or not. Flash can be installed while browsers are open, the users just have to restart the browsers that are open after the update. We’ll handle letting them know via a CocoaDialog script.
There are a few pre-requisite items we need to have in place for this process to work. First, we need to have a way to grab the Flash version off of the machines in our fleet. Second, we need to have a Smart Group that will capture all of the machines that are out of spec. This will allow us to scope our policy to those machines.
Grab the Version
I utilize an Extension Attribute to grab the version of Flash and store it in the database. While it can be argued that utilizing an EA to grab the version is not efficient, since the EA will run every time a Recon runs, there really isn’t another reliable method for grabbing the version.
So, setup an EA to grab the version of Flash. My EA is named “AdobeFlashVersion” and utilizes the following BASH script:
| #!/bin/bash | |
| FlashVersion=$(defaults read /Library/Internet\ Plug-Ins/Flash\ Player.plugin/Contents/Info.plist CFBundleShortVersionString) | |
| echo "<result>$FlashVersion</result>" | |
| exit 0 |
That’s pretty straight forward. Now that we have the version, we can build our Smart Group.
As you can see, just pick your EA name out of the list of criteria to search for, and enter the version you are searching for using the “is not” operator.
Policy Time
Now that we’ve got our Smart Group collecting machines that are out of date, we can build our policy to install the update. We will name our policy “Update Flash Player” and place it in whichever category makes sense to your deployment of Casper.
I have my update policy set to run at “Recurring Check-in”, which means that machines will update as soon as they contact the JSS. The frequency is set to “Once per computer”, since we only need it to run one time.
We’ll click on Packages next so that we can add our Flash package. Click on Configure to get a list of all packages in the JSS:
We should now have a list of all packages that the JSS knows about. Locate our latest Flash Player package and click Add to add it to the policy:
I utilize a script that runs after Flash has been installed to notify end users to restart any open web browsers. My script uses CocoaDialog to make these notifications, but you can use the built in notification process that Casper has. The script I utilize is below:
| #!/bin/sh | |
| CD="/path/to/cocoaDialog.app/Contents/MacOS/cocoaDialog" | |
| # pass the title, text, and Icon via $4, $5, $6, and timeout via $7 | |
| cdTitle=$4 | |
| cdText=$5 | |
| # what icon to use | |
| # if no icon is given, set a default | |
| if [[ -z "$6" ]]; then | |
| cdIcon="/private/var/inte/icons/globeDownload.icns" | |
| else | |
| cdIcon=$6 | |
| fi | |
| if [[ -z "$7" ]]; then | |
| cdTimeout="--no-timeout" | |
| else | |
| cdTimeout="--timeout $7" | |
| fi | |
| bubble=`$CD bubble --title "$cdTitle" $cdTimeout --text "$cdText" --icon-file $cdIcon` | |
| exit 0 |
Now that we’ve added that script to our policy, we will add a line to the Files & Processes tab to set Flash to not auto update.
That line of information in the Execute Command box simply adds a line to a file called mms.cfg to tell Flash Player to not try to auto update. The line is:
| touch /Library/Application\ Support/Macromedia/mms.cfg | echo "AutoUpdateDisable=1" > /Library/Application\ Support/Macromedia/mms.cfg |
The final thing for us to do is to add our Scope. Just click on the Scope tab at the top and add our Update Flash Smart Group:
That’s all there is. Now that we have our update policy in place, each time there’s a new version we just have a few simple steps to update our end users:
- Get the new Flash package into the JSS
- Change our Smart Group to look for the new version number
- Change our policy to remove the old version and add the new version
- Finally, Flush All on the policy logs so everyone in the Smart Group gets the update.
I have been utilizing this method for updating Flash for well over a year now, and I have not had any troubles at all.
I hope this quick article has helped you out.
JAMF Nation User Conference 2014
Every year as October gets closer, I get anxious. I know that at some point, usually toward the end of the month, I will be traveling up to Minneapolis for the JAMF Nation User Conference, JNUC. The conference is located at the Guthrie Theater in downtown, in the Mill district of Minneapolis, right on the Mississippi river. It’s one of my favorite locations to go to.
The JNUC is one of my favorite conferences to attend. Not just for the great content, but for the relationships that get formed and strengthened there. There are friends at JNUC that I’ve known for well over 10 years now, just from attending different conferences in the past. It’s great to catch up with these friends.
This year was also special because I was presenting there. I had the opportunity to present on imaging in a session titled “Unwrap the Imaging Enigma”. It was a wonderful experience, and one that I will repeat again. Giving back to the community by presenting is important for any admin. If you’re interested in the slides, you can find them on my GitHub repository.
Now that I’ve called more attention to this blog, and to myself, I will try to post more relevant content regularly. If there is a topic you’d like to see, just post it in the comments and I’ll see if I can come up with something. Or reach out to me on Twitter: @stevewood_tx
What’s Your Extension
To say that I’m a huge fan of JAMF Software‘s Casper Suite is probably putting it lightly. I love it, and one of the features I love is the ability to use Extension Attributes for gather information. In the old days of Casper we had no real way of gathering things like Flash version and storing it in an easy to get to place. Along came Extension Attributes and we were now able to store that version information right in the
As I work on upgrading to 9.2, I am doing a clean installation of the JSS and not importing my previous database. In the process I am only taking over packages, policies, scripts, etc, that I want on the new server. So I thought I would do a quick post on some of my favorite Extension Attributes and what I use them for.
“X” Plug-in Version
It seems like about once every two or three months a question comes across the JAMF Nation list about how to grab the version of Flash, or Silverlight, or name your application or plug-in. Here’s how I grab those versions:
https://gist.github.com/anonymous/7346191
From that script we can start to swap out different plug ins. The magic is the “defaults read” statement that grabs the version information from the Info.plist file in each plug-in. For example, if we wanted Silverlight, we’d use:
https://gist.github.com/anonymous/7346262
And so on. Pretty easy to use this to grab version information from different apps.
Display Serial Number
I used to hate having to inventory Apple Cinema Displays because you’d have to tip them up or lay them flat to read the barcode. With this EA you can have Casper do the work for you:
https://gist.github.com/anonymous/7346277
Keyboard or Mouse Battery Percentage
Do you want to know when the batteries are getting low on your Apple keyboard or mouse:
Keyboard: https://gist.github.com/anonymous/9135830
Mouse: https://gist.github.com/anonymous/9135844
Warranty Status
I can’t take credit for this one, but it is in the script. Need to grab the warranty status of your equipment:
https://gist.github.com/anonymous/9135868
These are only a few of the Extension Attributes I’ve moved over to the new server. JAMF did a good job of including a lot of pre-built EAs in version 9 of Casper. Make sure to check them out and implement the ones that you need.
The Geeky Gordo 