Enterprise Print Server problems and suggestions

My name is Grant and I am in charge of all the printer drivers and print
server functionality for a really big company. We have around 180,000
Windows users and I have heard we are actually the largest corporate Windows
network in the world.

I sent these suggestions (in 2 parts) to MS through
www.windowsserverfeedback.com. I got a response saying they liked some of
the ideas and have forwarded my sugesstions to some other people in MS. I am
posting this in case anyone else out there has some of these problems and
would like to comment on them or my solutions.

We have a couple hundred print servers and thousands upon thousands of print
queues. Needless to say, we have issues and problems that are not always
very common, but my ideas would benefit a lot of business users out there,
especially anyone using multiple print servers.

These are the primary print server issues we have:

#1 Migrating users to another print server with a different name
Every 2.5 years we lease roll our print servers. Sometimes we change the
name of the server, or move the queues to another server altogether.
Figuring out who the thousands of users that print to the old server are, and
migrating them to the new server continues to be a horrible exercise.

#2 Determining the users who print to each individual queue
It is unfortunately common to find a queue on the wrong server, such as
queue for a printer in Los Angeles on a Sacramento print server. Determining
the users who print just to that one specific queue is not fun. Migrating
them to an identical queue on a different server is less fun. It is so
difficult in fact, that we rarely ever do it.

#3 Determining if a queue is still used
The first thing I do before I migrate queues to a new server is I try my
best to determine which queues are no longer used. For print servers that
are 2-3 years old the average percentage of queues that have not been printed
to in the past 3 months is around 30-40%. It is startling to delete 150 out
of 350 queues because I find them not in use. Again, determining which
queues are not in use is not fun.

#4 Managing Printer Drivers
Standardizing which printer drivers are allowed on our print servers has
been a monster task. Enforcing our policy of ONLY using our approved drivers
has been impossible. Determining who installed a driver and/or where the
driver was loaded from, cannot be done and continues to give us the majority
of our driver problems.

#5 The System Event Log is a joke
The 10-20 daily system events are in the same log that creates an event for
every single print job, which is around 5000-6000 events per day per server.
Without increasing the size of the system event log this gives us only a few
days worth of events before they are overwritten.


Those are the main problems.
I have put a lot of time, thought and energy into my suggestions for fixing
these problems.

A. Printer Shortcuts
A printer shortcut would be exactly like a file shortcut (a file that when
executed directed the user to the location specified in the shortcut).
Printer Shortcuts would be in the Printers and Faxes folder, be shared, and
act just like printer queues. When the user printed to the printer shortcut
it would change the queue on the user’s PC to the queue the shortcut pointed
to. The printer shortcut could point to a queue on a different server or
even on the same server but with a different queuename.

Printer shortcuts would completely change how print queue migrations are
done. Queues would be created on the new server and the queues on the old
server would be replaced with printer shortcuts. Each time a user printed to
a queue on the old server it would migrate that user’s queue to the new
server, completely transparent to the user.

This would also allow administrators to migrate single queues to different
print servers that were closer to the physical printer or anywhere they
needed them to be.

B. Queue Migration Tool
Windows 2003 Print servers should have the ability to push or pull
individual, groups or all print queues and their drivers to and from other
2003 print servers. When a queue is moved a Printer Shortcut would be left
in its place.

C. Queue Logging
Each print queue should have the ability to track each print job title,
number of pages, user, time and date, size, and frequency of all the print
jobs printed to that queue.

Obviously this would take a considerable amount of resources compared to
what is tracked now (nothing) and it is not always necessary to track all or
some of this information. Each category should be selectable on a queue by
queue basis or on all queues. A date or time duration field would also be
needed, so you could set how far back you want to track. Ex: 1 month, 2
months, after Nov. 1st, etc.

Personally all we really NEED at SBC is the ability to track all the users
on specific queues, but the other data would be very useful.

This data needs to be stored in some kind of text or log file that can be
accessed as well. It should not be stored in the System Event Log

D. Queue Auto Management
Individually or as a whole queues should be configurable so if a queue (or a
Printer Shortcut) is not used for a set amount of time the queue is
automatically deleted or put into some kind of recycle bin. A log of this
kind of activity would need to be kept. If some kind of printer queue
recycle bin could be created the ability to restore deleted queues could be
used.

E. Printer Driver Tracking
Every time a printer driver is installed on a server the user who installed
it and the location it was installed from needs to be logged. The specific
queue it was loaded for or if it was just loaded on the server in general
would also be useful information, but are not as critical as user and
location.

F. Print Job Event Log
Print job events MUST be taken out of the System Event Log. A fourth Event
Log just for Print Jobs needs to be created. It would probably work well to
make the Queue Logging and Print Job Event Log work together.

As an administrator it is very important to get the System Event Log back.
Right now it is worthless.

G. Printer Driver Replication
It would be extremely useful to be able to replicate all of the printer
drivers on a Windows 2003 Server to other Windows 2003 Servers. As it stands
we have to load each individual driver on each individual server, thus the
versions of the drivers are always old or the wrong drivers are used. Only
during migrations of queues can we use Printmig to move drivers from one
machine to another, but that does not help with this problem.

H. Choose Which Driver From the Server Locally
This is a small fix but very important. During the creation of a print
queue, when choosing which driver to use the very first option should be a
drop down list box of drivers already loaded on the server. If the needed
driver is not already on the server then and only then should there be the
option to browse to the location of a printer driver to load.

As it stands, even if the needed driver is already loaded on the server the
person must go through a horrific process to specify that driver, and it
basically involves reloading the driver anyway. The current process is way
too complicated and confusing for our helpdesk people that create most of our
queues.



From what I can tell Print does not seem to be a priority for Microsoft.
There has been very little done to it since NT4 other than the introduction
of Version 3 drivers.

In this time of cost cutting I continue to fight off attacks by upper
management to consider moving our print server function to Linux. Right now
the transparent loading and updating of printer drivers by the server is the
only thing that winning the justification of Windows over Linux.

I know we are not the only large company that would greatly benefit from the
features I suggested. Using Linux for print servers is becoming all too
common. Windows Print needs attention desperately. I would love to discuss
this in more detail with someone involved with the print function of Windows
Server.

Grant