Printers

Death by printing and political maladies


Here’s a dilemma that’s frustrated many an IT pro for

years. If we truly are in the electronic

age and everything is becoming digitized, why, oh why, are we spending so much

time troubleshooting and accommodating printing issues? Printing is the bane of our existence, always

rearing its ugly head when we least expect it.

We can customize the interfaces of a new system to work with existing

applications and deftly coordinate a multi-site client rollout to appear

seamless to the user, but it’s troubleshooting the printing problems that drive

us absolutely bananas!

Users seem to print more now than ever. Replace a paper system with an electronic

system and what happens? Users print reports

and screen dumps. Most of what’s printed

out is thrown right into the trashcan. A

quick search on the internet reveals that numerous organizations and educational institutions report a

sustained gradual increase in paper usage.

That can be an entirely separate topic for another day, but my point is

electronic systems aren’t decreasing the amount of printing by users, they’re

increasing it. And as it increases, the

more importance is placed on the printing infrastructure and the more IT staffs

walk around with headaches from chasing down the myriad of resulting issues.

To compound the problem, the cost of printers continues to

go down while the quality of lower end printers continues to rise. So it’s becoming increasingly easier for

staff to justify purchasing personal printers.

Everyone can create a reason for why they “need” a printer of their very

own. Mostly, managers play the

confidentiality card. They can’t be

expected to print performance reviews and other confidential documents on the

departmental printer. Okay, fine. I can

accept that. Plunk a printer down in

their office. But then staff reports

that they need printers for the mobile laptop carts. Reason – they can’t walk down the hall to the

unit’s main printer. That would negate

the benefit of having the mobile cart in the first place. Then the billing department reports that they

require individual printers to print each customer’s account screen. Reason –

it’s easier to read the printouts than the screen.

See where this is going?

It’s a runaway train headed down a steep cliff. It appears we’ve spoiled our users into

expecting technology coddling. Think of

someone at home frantically looking for the TV remote instead of walking over

and turning the channel (I’m not saying I’ve never done it.) I’ve

got to have it now and I shouldn’t have to move to get it.

So what is wrong with so many printers scattered around the

workplace? It complicates the printing

infrastructure and can severely hinder the deployment of thin client based

solutions. The more printers installed

in an environment, the greater number of model types, and that means there are

a greater variety of print drivers. It

becomes impossible to keep up with the number of drivers needed on Citrix and

Windows Terminal Servers; keeping up with the model type, platform and whether

it’s PCL 4, 5e, 6 or PostScript (please, anything but PCL 6.)

Printing in thin client environments has improved in recent

years. There are better universal

drivers from companies like HP and Citrix; better but not perfect. And special features such as duplexing are

usually forfeited when using a universal versus model specific driver. Citrix MetaFrame Presentation Server 4.0 has

an improved printing architecture, but still has its challenges. Unless you can keep up with print driver

mappings and experimenting with which driver type works for different

applications, you will always have a fair share of printing issues to

troubleshoot.

For example, a user with an attached scanner connects to a

Citrix server and the session hangs because the server can’t correctly map a

driver for the scanner. All subsequent

client sessions stall keeping anyone else from accessing the published

application, and the print spooler service hangs, not stops, preventing print

jobs from successfully printing. For a

solution, you can ferret out individual printers and add mappings each time, or

choose to only connect a client’s default printer, or even install a local

printer on the server and disable client printer connections altogether. But troubleshooting printing issues will

continue to consume a better part of your time.

Sure, you can attempt to standardize on the printers being

deployed and drivers used. But models

get phased out and replaced, and drivers get updated by users with proper

rights or local IS staff, etc. It’s not

quite as easy to maintain as one would imagine, especially in large

corporations. Depending on the company

you work for, chances are good that IT doesn’t have the political clout needed

to keep certain departments and users at bay when attempting to

standardize. There may be times when you

can’t tell someone “no” to having a personal printer or “no” to certain brands

and models.

So what is the solution?

I don’t exactly know. Maybe you

can tell me. IT isn’t generally a

revenue generating department so our influence sometimes falls short compared

to a department that is a company cash cow.

Sound off and let me know your experiences!

2 comments
paperjammer
paperjammer

I got something that might cheer you up try www.destroyaprinter.com

wingatemother
wingatemother

Our social services agency is a subnet of the county LAN. The county network administrator has, indeed, informed us that he in no longer going to support print jobs from un-networked printers in our agency. The scenario you describe, with all the rationales for the need for individual desktop printers, along with the increasing print jobs, rings true with us. Having been one of the non-tech-sympathetic workers before becoming supervisor of our internal IT guys, (and having taken a network security course in a desire to understand IT better) I can sympathize with both sides. Our solution? We plan to continue with individual desktop printers that are un-networked for some, with shared networked printers, and run individual lines for individual networked desktop printer to offices of workers who require individual printing, and using our two agency IT guys to trouble-shoot our non-networked printer jobs. We print from MS office documents which can be saved to the network f-drive, from the internet (searching for medical info or client resources, from an AS400 system, and from the state mainframe (an emulator?). What problems can you predict for us?

Editor's Picks