Recently I've become more and more involved with the operation of Apple Computers running OS X (10.4, Tiger) in our corporate environment. While working with these computers, I am often impressed and disappointed on how well they work with and fit into corporate IT. Impressed because many things that one would expect to be complicated pretty much just work out of the box with no hassle. Integration with various directory services (including Microsoft Active Directory) is a great example. Then, just when Apple has knocked my socks off, I run into something simple that is over complicated.
Setting up shared printers is a prime example of something that should be simple, but isn't. So far I have discovered three different ways to configure and setup printers on an OS X Server. The CUPS interface at http://localhost:631, Server Admin, and the Print & Fax panel under System Preferences. If this was an Apple only environment my impression is that any one of these tools would get the job done, however in a mixed environment where the goal is to get Macs, Windows, and Linux machines printing to the printers hosted by the OS X server the process is not at all straightforward.
Before I started working with OS X I knew that there was UNIX under the hood. When it came to printing I knew that OS X used CUPS. What I didn't expect was how poorly Apple had gone about pulling this all together. All I wanted to do was to setup printers on the OS X server and have them share out to other OS X and Linux computers.
After much trial and error I discovered that the way to get printers working the way I expected was to first use the CUPS web interface to configure the printer basics. Neither Server Admin or the Print & Fax panel exposed the option for a HP JetDirect print server, yet it was right there under the CUPS web interface. I also discovered that OS X was using the information entered in the description field as the "shared name" of the printer, not the name of the printer. I ended up setting both name and description to the same string to avoid confusion. While the CUPS interface let me configure the HP JetDirect option, it didn't have the full driver listing. To get a full driver listing I had to leave the CUPS web interface after selecting a generic HP driver. I went into the Printer & Fax panel under System Preferences in order to select the specific HP Printer Definition and specify installed options (Memory, Duplexer, extra trays, etc.). Once all this was set, it was into Server Admin to start up the print service.
After getting printing figured out, I didn't get back around to doing more under OS X for a bit. The next not quite there moment was dealing with the Apple XRAID we have attached to one of our Apple XServes. Our XRAID is an early generation XRAID, and four of five years ago I was a bit skeptical about it, but since then hot-plug SATA drives have become the norm in SAN configurations and looking back I see that Apple was ahead of the curve in SAN technology with the introduction of the XRAID. Apple's RAID Admin tool is nice, clean, and useful, however I discovered a major flaw. If for some reason you happen to have a printer (or any other device) configured to use the same static IP address as your XRAID's management interface, the RAID Admin tool will sit and spin endlessly trying to connect and manage the XRAID. I would expect to get a timeout error, or something along the lines of "Device is responding to pings but RAID management is not available." All I got however was a spinner that just kept on spinning. After diagnosing and correcting the IP address conflict that was created by another tech things started working as expected.
The last almost there moment I have also involves the XRAID. We recently purchased seven more drive modules to fill up the XRAID. When the drive modules were inserted into the XRAID they all flashed an orange warning light. Close inspection of the box of one of the drive modules has a small sticker indicating a minimum firmware version was needed to recognize the drives. A quick check of RAID Admin showed that we needed to update the XRAID's firmware. We have located and downloaded the firmware update but haven't yet updated the update. The update has minimal documentation. We assume that the update will cause us to loose connectivity to the XRAID, and thus the data stored there will be unavailable for a short time. While our shop knows that updates of this magnitude should be scheduled for a proper maintenance window, other shops may not be so tech savvy and may miss this detail.
I would love to go on and hit on some of the things Apple has got right (I love Apple Remote Desktop!) but in the interest of getting this blog rolling I'm going to save that (and more) for a future post. :)
