Open Radar

 
[This radar is also published as a blog post:
http://sites.uci.edu/atlauren/blog/2016/05/16/managing-os-x-printers-is-less-than-ideal/ ]

Taken as a whole, managing printers for OS X clients in the enterprise is far more difficult than it should be.

As a usecase example, central IT at this university manages 3,000 domain-joined Windows computers. In this environment, about 150 printer queues are provisioned, maintained, and deprecated via Group Policy; the queues are hosted on a central print server. Each queue’s definition includes the needed driver; if the target PCs don’t have the driver, they receive it. If a printer queue is added or removed removed from a policy, it is likewise added or removed from the clients. These queues connect to printers via LDR or IPP, specify different PCL or PostScript versions, encompass a variety of functional configurations for color, black/white, duplex, FAX, multiple paper sizes/sources, etc. The usecase calls for reliable and consistent programmatic deployment and deprecation of objects, within a wide variety of configurations.

Taking a fresh, modern approach to OS X, you want to think that MDM works similarly. Alas, it falls short:

* Only “Generic” and AirPrint queues can be reliably deployed.
* MDM can remove printer profiles, but their configured printers do not also disappear.

Custom printer profiles can be deployed, but are a particularly difficult usecase -- these are any printer that requires a non-Apple, vendor-provided PPD file. The challenges here are:

* “Custom” printers require either a declared printer driver string (matching the PPD filename), or the PPD file’s local file system path.
* Third party printer driver/PPDs are only provided via additional driver packages.
* MDM profiles cannot deliver the needed printer driver/PPD file.
* MDM “Custom” printer profiles cannot specify a driver package dependency.

As such, MDM on OS X can neither satisfy the dependencies of a Custom printer profile, nor validate them before installing the profile. In addition, third-party provider support for Custom printers varies widely in effectiveness. (One vendor told me that support for this had been “withdrawn” by Apple.)

In the MacIT community, it is accepted that MDM with printers “doesn’t work”. Instead, the accepted practice is to manage tasks via agents such as JAMF, Munki, etc..  These tasks are scripts that install and validate the drivers, and configure printers via lpadmin.  That admins retreat to these methods indicates that the provided mechanisms are not sufficient.

As of this writing, MDM with Mac OS X El Capitan (10.11.4) does not meet the needs of enterprise printer management. Many new features are needed to meet the needs of enterprise printing.  Such features include:

* Declare driver/package dependencies
*Provide a mechanism to meet those dependencies, for example:
** Kickoff a driver install from the MDM server.
** Direct softwareupdate to install packages from a (currently mythical) optional repository:
	softwareupdate -i -o xeroxprinterdrivers4.0.pkg
* Specify configurations and defaults for color, page size, layout, n-up, duplex, etc.
* Remove a managed printer when its profile is removed.

Hopefully a future release of MDM on OS X will meet these needs.