Photo of stones in a bowl
Common Solutions Group: Common Solutions Group:

Network Printing Report

October 25, 1995

TO:   Common Solutions Group
FROM:   Mark Luker
SUBJECT:  Report on "Current Accounting Methods for Network Printing"

This group has requested short reports on current methods for managing
and billing for networked printing (e.g., in computing labs) from six
universities.  We now have full or partial reports from four, and names
to contact at each place.  We will prepare and distribute a more complete
list in the near future as the final responses come in.

Notes by campus:


Thomas B Hughes
220 CCC / CIT
Ithaca, NY 14853

We are about to try a Mac-only pilot of a new system for recovering the
costs of laser printing in our public labs.  Currently we have free dot
matrix printing and stand-alone laser printing stations that charge
$.15/page via VendaCard technology.   We have plans to implement the system
on Windows but have nothing beyond a conceptual plan and where we might buy
the LPD/LPR code.

The new model will have the student authenticate themselves at the Mac
using a Kerberos based technology developed here at Cornell called Sidecar.
To precluse spoofing, the Mac has a small init that registers an AppleTalk
<-> IP mapping with the Unix/CAP based spooler upon bootup.

When the user prints for the first time, the spooler requests
authentication from the Sidecar via IP after confirming the AppleTalk <->
IP mapping.   This callback code is based on some elegant CAP modifications
made by Steve Andrewartha of the University of
Tasmania (based originally on a callback system created by Neil Chesire and
others at Stanford for the Stanford Residence Halls).  If the user is in
the authorization table, the spooler accepts the job.

At this time we are planning to use IP based security that we have worked
out for HP 4si printers (we're working on others) to restrict use of the
printer to jobs coming from the spooler.  We will set the printer to only
accept jobs via IP from the spooler address.  Steve Andrewartha uses an
AppleTalk based solution that discourages circumventing the spooler by
changing the Chooser device type for the laser to something that cannot be
typed.  We opted to not use this because of concerns that a savvy student
with an AppleTalk sniffer could figure out the device type and replace the

In either case, the spooler queries the printer for the current page count,
sends the job (including a header page), and then queries the printer again
for the page count to determine the actual number of pages printed.   The
need for the page count via IP is the reason we are currently restricted to
the HP 4si printer.   Steve Andrewartha's method allows a wider range of
printer types including all Apple LaserWriters.

The final step of the print process records the page count in a database
against the user's name/NetID.  Steve Andrewartha uses QI, I believe we are
using a generic flat file table in Unix.  Eventually we wish to
automatically bill the student's Busar account once a month, but for the
pilot we are likely to just have the lab operator take a check (no cash)
and increase the student's print allocation (Stanford does this with no
apparent problems).

Management of print queues is being done via dynamically created Web pages.
Users can see their own queue and can delete jobs or move them to another
queue if they wish.  Lab operators will be able to shut down and wake up
printers (via the spooler) and also move all the jobs in a queue to a
different printer in the same location (in the case of a dead printer).
LaserWriter 8.3 software will give the users desktop drag and drop printing
to the spooler.



Frank Steen, Director FAS Computer Services
Harvard University

We have indeed implemented a grow-your-own print charging system. I am
not completely satisfied with it, but it is working in most regards. Here
are my bullets:

How it works:
*CAP running on an Ulrix box captures the HP laserjet printers on Ethernet
(100% of our printers are HP's with JetDirect cards) and Intel Ethernet
to serial boxes with one or two dot matrix printers attached. Macs print
to CAP which passes print jobs through a program that deducts money from
their printer budget. CAP prints to the printers as UNIX printers.

*PCs attach to our huge Novell server running on a VMS machine (TGV
software for Novell 3.12 emulation). Printers are selected from a menu.
Print jobs go from the Novell server directly to VMS. VMS passes the print
jobs on to the Ultrix box which runs them through the accounting software
and then sends the job to the same UNIX printers as above.

*Users add money to their print budgets by either putting paper money into
a cash acceptor attached to a terminal or by giving our User Assistants
a check. In either case the money is entered into the user's print account.
All of the lines between the terminals and the Ulrix box are considered
secure. Users verify their identity with their ID numbers. We have a
provision for overdraft and we currently give users a $2.00 overdraft in
case they are stuck without money and a paper due. All copies cost $.10

*We have 21 laser printers and 21 dot matrix printers connected to the
system. around campus. Dot matrix printing is free. Any of the 5000 network
connected computers we deal with can print to any of our 42 printers.

Plusses: We get central control of printing. We eliminated pesky
venda-cards. (We have lots of vendacard readers and a couple of card-cash
machines for sale!)

Minuses: a very complex system. There have been frequent problems. We now
offer a printing guaranty. If there is some kind of problem we give users
free laser printing (we open up laser printing). When there is a problem
we have to deal with UNIX, VMS, AppleTalk, CAP, Novell.... One person
alone cannot handle our printing problems. The biggest problems were with
the dot matrix printers which finally work on Ethernet. The cash acceptor
acts up often.

I am not ready to recommend this system, although it has stablized



Christopher C Barbeau
University of Michigan
2234 Argus 
313 764-7128

A complete description is available at
(See attached pages)



Greg Jackson
e40-359a/MIT/Cambridge MA 02139
voice: (617) 253-3712

First of all, for small machines (Wintels and Macs) we don't have any
network print accounting. Most of our network-accessible printers are
either in private spaces (making it hard for outsiders to retrieve print
jobs they send there) or public Athena printers with Mac and Windows access

Athena printers are a different story. We deploy something like 60 of
these campus-wide, currently all LaserJet IVsi's with extra memory and so
forth. The TCP/IP side of these is configured only to accept print jobs
from a limited set of machines, our print servers. On the workstation
client side (we have about 1,000 UNIX client machines), we've modified
the relevant printing commands so that they direct output to the print
servers. The print servers only accept authenticated print jobs (that is,
the request must come with valid Kerberos tickets), and they then keep
track of who printed how many pages.

This system is rather awkward, and since it requires too much hacking of
standard services it's difficult to maintain and operate. Moreover, since
we give each Athena user a free allowance of 1,000 pages per year, and
virtually no one reaches that limit, the charging system is rather moot,
and has fallen into some disrepair. In fact I'm not sure it's running now!

Our key requirements are that any system (a) rely on our standard
authentication schemes and (b) provide accounting without burdening
operations or development. It would be nice if the services extended to
lesser machines, especially Macs and Wintels. It would be even nicer if
it were possible for someone easily to set up a "private" printer that
was network-accessible but had a locally controlled authorization list.
We've seen no commercial products that do all this.

We have high hopes of the Cornell stuff...

If you want more technical detail, I can point you at people who know 



Merriman, Jeffrey W
Dir Of Res Computing
2nd Floor Wilbur Hal
Stanford University
(415) 723-4800

Dean Spearing (for technical details)

All the information regarding our print accounting is available as links
off of our home page,  (See attached pages)

As told to Mark Luker by phone:

Stanford serves some 5,000 undergraduates and 3,000 graduate students
through a print accounting system that works as follows:  Mac's and UNIX
computers are supported now.  Work is underway to support PC's.

Thirty-five HP 4M+ printers are scattered through the campus.  These IP
ready printers are configured to accept printing from only five Sun
Sparcstation computers that are used to spool print jobs.  (The printers
are invisible on the Macintosh chooser, but the spoolers appear as
printers.)  CAP is run on the spoolers to accepts Macintosh print requests.
When a request is received, the spooler generates a request for
authentication back to the user's Macintosh.  A small Mac Init called the
Mac Authenticator brings up a window that requests username and password,
using Kerberos for secure communication with the spooler.  The spooler
then queries and updates a flat file containing accounting information
for each student and sends the print job to the printer.

Students deposit money in their accounts at this time by handing checks
to the computer coordinators, who update the accounting file.  This will
shift to the debit card system when it is available.  Students have access
through web tools to the status, balance, etc., of their accounts.

They system has worked for three years and is working well.  The Mac
Authenticator is the private property of a student there.  Stanford is
negotiating to purchase it.



Philip E Long
Director, Academic Computing Services
175 Whitney Ave
Yale University

Our current operation is a manual card based charging system.  We have
one or more laser printers at 22 locations each controlled by a private,
dedicated-to-laser-printing, debit card system.  The cards themselves are
inexpensive plastic with a mag stripe.  End users buy the cards and add
$$ to them at cash machines at the five major campus clusters or in the
Master's Office in the residences.

We manage printing by a single Novell server.  All Macs, PCs and Unix
machines connected to the campus network can print to a queue associated
with each public cluster printer (this includes student room connected
machines).  We have a Novell queue manager machine next to each printer
(a Mac Plus).  The student prints to the queue which will hold the print
for 24 hours.  The student then physically goes to the printer, inserts
her "print debit card" in the associated card reader and releases her
particular print job to that printer.

Problems issues with this system include:
*  card reader costs:  at $300+, the card readers add substantially to
the cost of printers 
*  cash machine costs:  at $1,500, these are very expensive and, for
reliability, we have multiple machines at most sites to increase the
probability that one will be working at 3:00 am 
*  printer reliability:  we have tended to under invest in printers;
these get tremendous business, so industrial strength is definitely
* reliability:  students and cards are only 80% successful.  Many students
get confused and make mistakes which cost them $$ or require a refund;
also, the machines themselves are finnicy and jam much more frequently
than I think ought to happen.  Repair of a machine required sending it
back to the factory with a 2-3 week turnaround, so this fall we sent one
of our technicians to the factory to be trained.  
*  even with charging, there are huge costs to supporting printing:
answering user questions, providing paper and toner, especially making it
available to our student employees without making it available for theft;
and servicing the equipment.  We have a student visit every cluster once
a day (attended clusters are, of course, continuously monitored).  We also
have a staff member who visits every other day to check for problems, swap
broken equipment, etc.  A printer down w/no back-up in a cluster is a
"crisis" activity for us.

Considering our large investment, we provide only an OK service.  The
staff member mentioned above is new this year, so I hope it will become
a good service this year, but I doubt that we'll ever achieve excellence
with this technology.

I look forward to the reports from the other schools as this is an area
we are very interested in improving and/or controlling/lowering costs (!).


Mark Luker, CIO, University of Wisconsin-Madison
Div of Info Technology, 1210 W Dayton St, Madison, WI 53706      608-262-8874