Home › Topics › Printer Support › Drivers & Queues

Printer Drivers, Queues and Defaults Done Once

Wednesday, 14:00, at Bluewater Bank. The printer in the Harbour Street branch has died, the replacement has arrived, and Marcus has driven out to install it. It takes him twelve minutes. Then he discovers that the branch's twenty-three desktops were each connected directly to the old printer's network address. Each had its own copy of a driver installed by whoever set the machine up. Not one of them can see the new device. He works through them one at a time. By the time he reaches the eleventh, the first has rebooted into an update and lost its connection again. The branch manager has asked, politely, whether the bank really needs a printer specialist to visit every time a printer is replaced.

The bank does not, and the reason Marcus is still there at six is that nobody ever did the printing once. Doing printing once means a central queue on a print server for every printer. One driver per model is held on that server and handed out to every machine that connects. Defaults are set on the queue rather than on each desk, and names say where the printer is. Each person gets the queues near them without a visit. It is a day or two of work for a small organisation. It converts a hundred private arrangements between desks and printers into a handful of things the desk controls. This article is part of our Printer Support series. It is the one that stops the fixes in the triage flow from being done forty times over.

It starts with the print server's job in plain words, then why direct connections multiply tickets. Next come one driver per model, sensible defaults, and queue names people can find. After that: mapping queues to people by location, the device's own accounts for scanning, and rolling the standard out without a riot. It ends with a short war story and the queue standard to copy.

The Print Server's Job in Plain Words

A print server is a computer on the network that owns the printers on behalf of everyone else. It can be a dedicated machine or a role on a server that already does other things. On a small network, it can be a well-behaved desktop that never gets switched off. The hardware matters far less than the idea. For each printer it holds four things. The queue is the line of jobs waiting for that printer. The one copy of the driver is the software that turns a document into the printer's language. The defaults include settings such as two-sided and black only. It also holds the printer's address, so that nobody else needs to know it. A machine that wants to print connects to the queue, and the server hands it the driver and the defaults automatically. One source. Many copies, all the same.

Think of it as the post room in an old office building. Nobody on the fourth floor needed to know which courier went to which city; they put the letter in the post room's tray and the post room knew. Take the post room away and every desk has to keep its own list of couriers, and when a courier changes, every list is wrong at once. That is the only analogy this article needs, and it is the whole case for the server. The alternative is not "no server". The alternative is a hundred small servers, one per desk, each maintained by nobody.

The server also gives the desk a place to look. When nobody on a floor can print, the shared queue on the server shows the stuck job at the head, the paused state or the error. It does this in one screen, which is the second test of the triage flow. Without a server, that information exists only on the printer's own small panel and in the private queues of twenty machines. The technician's first move is a walk. A print server is, among other things, the thing that makes a printer ticket answerable from a chair.

Why Direct Connections Multiply Tickets

A direct connection is a machine printing straight to the printer's network address with its own driver and its own queue, no server involved. It is how most small networks start, because it is the quickest way to make one machine print today. It is also how Marcus came to spend an afternoon in Harbour Street. Each direct connection is a private arrangement: a driver somebody chose, installed on a date nobody recorded, pointing at an address that will change when the printer does. Twenty-three desktops meant twenty-three arrangements, every one of them a visit when anything about the printer changed.

Direct connections also hide the queue. When the printer refuses a job from one machine, that job sits in that machine's private queue, invisible to the desk. The printer carries on serving everyone else. The ticket says "only I can't print" when it means "my machine has a job stuck in a queue only I can see". Multiply that by the number of machines and the desk is diagnosing twenty small queues instead of one. And they drift. Two neighbouring machines set up a year apart end up with two different drivers for the same printer. One prints a forty-page job as forty pages of symbols. "It works on mine" is the sound of a direct connection.

The honest edge is that a direct connection is the right answer in a few places. Those places include a single-user device on a desk that only one machine will ever use, and a printer in a site with no server and three staff. Another is a specialist label printer driven by one application. For those, a direct connection with a fixed address and a note in the knowledge base is cheaper than a queue. The standard at the end of this article allows them, by exception, with a name against each. Everything else goes on the server.

One Driver Per Model

The rule is one driver per printer model, held on the server, and no driver installed by hand on any machine that connects to a queue. When a machine connects, it pulls the server's copy; when the server's copy is updated, every machine picks up the new one on its next connection. The desk then has one driver per model to know, test and update, instead of one per machine to discover. A desk that supports six models supports six drivers. A desk that lets each machine choose supports as many as it has machines, and does not know which.

Where several models come from the same maker, a single driver that covers the whole family is usually offered. It is worth using even at the cost of a feature or two on the fanciest device. One driver across four models is four fewer things to go wrong. Test it on each model before trusting it, on the machines people actually use and with the documents they actually print. That includes the finance team's wide spreadsheet, the marketing team's full-bleed brochure, and the envelopes printed by the one person who uses them. The family driver that handles plain text perfectly and mangles the envelope is a ticket waiting to be raised. It will come from the one person who will not understand why it worked last month.

A driver change is a change, in the sense the change management series uses the word. It alters something shared and can break printing for everyone on a queue at once. It deserves a note saying what was changed, when, and how to put it back. The rollback is the previous driver, kept on the server, and the test is a page from one ordinary machine after the change. Desks that treat a driver update as a tick-box update it on a Friday at five. It is not malice; it is the belief that drivers are small. They are small the way a fuse is small.

Sensible Defaults, Set on the Queue

The defaults are the settings a job gets when the person pressing print changes nothing. Most people change nothing, so the defaults decide what the organisation prints. Set them on the queue, on the server, once, and every machine inherits them. The sensible set is short: two-sided, black only on devices that can do colour, the standard paper size, the main tray, and a single copy. Colour, single-sided and the special tray are then choices a person makes on purpose, in the print dialog, for the job that needs them. The brochure that goes out to a client still looks like a brochure.

The savings are real and are measured in consumables and in tickets, not in a currency this article will not use. A device that prints two-sided by default uses roughly half the paper on long documents and halves the tray refills, and the "load paper" messages that come with them. Black-only by default makes colour cartridges last a season instead of a month. That removes a class of consumables ticket and a class of argument about who printed the holiday photos. And identical defaults across every machine remove the "it came out different on hers" ticket entirely, because there is no "hers" any more; there is the queue.

Changing defaults is visible and needs announcing. The morning after two-sided becomes the default, the desk gets "the printer is printing on the back of the page" from a dozen people. They have never looked at the print dialog and should not have to. A short notice the day before, with one sentence on how to print single-sided when it matters, converts those tickets into nothing. The shape of a notice that lands is in Planned Maintenance Notices, which is a grander name than a default change deserves and the right format anyway.

Queue Names People Can Find

The name of the queue is the only part of the printing system most people ever see. On most networks, it is chosen by whoever set up the first printer, in a hurry, from the model number. A list of queues called by their model numbers is a list that nobody except the desk can read. It produces a whole category of ticket: "it printed on the wrong printer". The wrong printer was the one with the similar name on the next floor. A name that says where the device is removes that category. Nobody chooses "Floor 2 East, by the kitchen" by mistake when they sit on floor three.

A naming convention is three or four parts in a fixed order: site, floor or area, a landmark or team, and the device's type, with colour marked when it matters. The table below shows one convention on a fictional estate, with the technical name the server uses and the display name a person sees. Model numbers do not appear in either, because the model will be replaced and the location will not. A queue that keeps its name through a replacement is a queue nobody has to reconnect to. Put the same name on a label on the front of the physical device. Then the person standing at it and the person choosing it from a list are looking at the same words. The on-printer card in the physical article carries it.

Technical nameDisplay nameWhat it tells the personThe mistake it prevents
HQ-2E-KITCHEN-MONOHQ Floor 2 East, by the kitchen (mono)Site, floor, landmark, black onlySending a colour job to a mono device and raising a quality ticket
HQ-2W-FINANCE-COLOURHQ Floor 2 West, Finance (colour)The team the device sits withFinance printing on the other side of the floor and walking
HQ-G-RECEPTION-MFPHQ Ground, Reception (print and scan)That it scans tooScanning tickets raised against the wrong device
BR12-COUNTER-MONOBranch 12 Harbour Street, counter (mono)The branch and the spotA branch job landing at head office
WH-GOODSOUT-LABELSWarehouse goods-out, label printerA special-purpose devicePick lists sent to the label printer and vice versa
HQ-1N-HR-SECUREHQ Floor 1 North, HR (held until released)That the job waits for the personA confidential letter sitting in an output tray

Keep the list short enough to read. A person who is offered forty queues will choose the top one, and the top one is alphabetical, not nearest. Mapping, which is the next section, is how most people see only the three or four queues that are theirs. A clean naming convention and a short list between them end most of the wrong-printer tickets without anyone touching a driver.

Mapping Queues to People by Location

Mapping is giving each person the queues near them automatically. That way, a new starter, a desk move or a replaced printer never needs a visit to connect anything. The usual way is a rule on the directory or on the machine's management profile. It says: people in this group, or machines in this site, get these queues, and this one is the default. Finance gets its floor's two devices with the mono one as default. The Harbour Street branch gets the counter device and nothing else. The warehouse gets the pick list queue and the label printer. The rule does the connecting, the server supplies the driver, and the person finds the right printer already there on their first morning.

Mapping by location rather than by person is what makes it survive. People move; floors do not. A rule tied to the floor or the site keeps working when the team is reorganised, which happens more often than printers are replaced. It means the role profile for a new starter can say "printers: by location" and nothing more. Hot desks are the awkward case. A person who sits in a different place each day needs either the queues for every place they might sit or a default that follows the machine's location. Giving them every queue makes a long list. Some management tools can make the default follow the machine's location, and many cannot. The honest answer for a small desk is to give hot-deskers the whole building's short list and a naming convention good enough to choose from.

Mapping also retires the old direct connections, and this is the step people skip. A machine that has both a mapped queue and its old direct connection will print to whichever is the default. That is usually the old one. This lasts until the day the old printer's address changes and the ticket says "only I can't print". The rollout removes direct connections as it adds mapped queues, machine by machine, and the standard says no new direct connection is created without a named exception. Old connections do not expire. They wait.

The Device's Own Accounts

A multifunction device that scans to e-mail or to a folder has accounts of its own. It has a sign-in on the mail service it sends from, and a sign-in on the file service it writes to. Those accounts have passwords. The passwords expire, or get changed by someone tidying up the directory who did not know a printer used them. The device stops scanning with no message to anyone. The queue standard therefore names an owner for each device's accounts, records which accounts each device uses, and puts the expiry on a calendar. A password that expires on a Saturday is a scanning ticket on Monday from everyone on the floor. Use a dedicated account for the device, never a person's. The person leaves, their account is disabled, and the printer stops scanning on the day of their leaving drinks.

Remember: put every printer on a central queue, with one driver per model held on the server. Set defaults on the queue, use a name that says where the device is, and map queues by location. No direct connections and no hand-installed drivers without a named exception.

Rolling It Out Without a Riot

The standard is rolled out one floor or one site at a time, and the order inside each is fixed. Create the queues on the server with the new names and defaults. Test from one ordinary machine, then map the queues to the floor's people. Visit or remotely touch each machine once to remove its direct connections. Announce before each step that affects what people see. Keep the old queue names alive as aliases for a couple of weeks where the tool allows it. That way, a person who had the old one saved still prints. Retire them with a notice. Measure printer tickets for the floor the quarter before and the quarter after, by device, using the census from the first article, so that the result is a number rather than an impression.

Track the rollout as one piece of work with a ticket per floor. Each holds its own checklist, test result and the date its direct connections were removed. All are linked to one parent ticket for the project. If you run QuerySolv, linking the per-floor tickets to the parent means the whole programme has one history. The machine that was missed shows up as the floor ticket that never closed. In any tool, the point is that a rollout with no record is a rollout nobody can finish. Nobody can say which machines are done. Expect the tickets to rise for a week after each floor and fall after that. The rise is people meeting the new names. The fall is the point.

A Short War Story: Sixty Direct Connections at Redbrook Engineering

At Redbrook Engineering, a firm of structural engineers with a drawing office, the main floor's printer was replaced on a Tuesday by a technician called Lauren. She installed the new device in twenty minutes and then found sixty machines connected directly to the old address. Each had one of three different drivers for the same model that three different technicians had favoured over the years. She and a colleague spent the rest of Tuesday and all of Wednesday at desks, about thirty hours between them. The drawing office, whose scaled plans printed at the wrong size from one of the three drivers, raised eleven tickets in the following fortnight. Only then did anyone work out that the problem followed the driver and not the machine. Lauren set up a print server over the following month. It had one queue per device with the location in the name, one driver per model, defaults on the queue, and queues mapped by floor. The next printer replacement, a year later, took her twelve minutes and no visits at all. The thirty hours had been the price of never having done it once. The eleven drawing-office tickets were the interest.

The Queue Standard

The standard below is a one-page agreement, written once and kept with the desk's other standards, that says how every printer on the network is set up. Section A is the rule for queues and connections, B for drivers, C for defaults, and D for names. E is for mapping, F for the device's own accounts, and G for exceptions, which must be named. H says how a change to any of it is made. It is deliberately short, because a standard that runs to eleven pages is a standard nobody has read. Fill in the blanks for your own estate and treat every printer that does not match it as a ticket waiting to happen, which it is.

THE QUEUE STANDARD — ONE PAGE
Owner: ______________________   Agreed on: ____________   Print server(s): ______________________

A. QUEUES AND CONNECTIONS
   Every shared printer has one queue on the print server. Machines connect to the queue, never to the device.
   Every printer has a fixed network address, recorded here or in the device register: ______________________
   Direct connections exist only by named exception (section G).

B. DRIVERS
   One driver per model, held on the server; machines receive it on connection. No hand-installed drivers.
   Family driver used where it covers several models: yes / no   Tested on: ______________________
   A driver change is a change: note, test page from one ordinary machine, previous driver kept for rollback.

C. DEFAULTS (set on the queue)
   Two-sided: yes    Colour: off by default on colour devices    Paper: ______    Tray: ______    Copies: 1
   Exceptions to defaults, by queue: ______________________________________________

D. NAMES
   Pattern: SITE-FLOOR/AREA-LANDMARK/TEAM-TYPE    Example: ______________________________
   Display name says site, floor, landmark and whether it is mono, colour, scans, or holds jobs.
   No model numbers in names. The same name is on the label on the front of the device.

E. MAPPING
   Queues are given by location (site, floor or group), with one default per location. Rule lives in: ______________
   Hot-desk and roaming staff receive: ______________________________
   Direct connections are removed from each machine as its mapped queues are added.

F. THE DEVICE'S OWN ACCOUNTS (scanning)
   Each scanning device has a dedicated account on the mail service and the file service, never a person's.
   Owner of device accounts: ______________   Expiry dates on the desk calendar: yes / no

G. EXCEPTIONS (one line each, with a name and a review date)
   Device ______________  Reason ______________________  Approved by ______________  Review ________
   Device ______________  Reason ______________________  Approved by ______________  Review ________

H. CHANGES TO THIS STANDARD
   Proposed by ______________  Agreed by ______________  Date ________  What changed: ______________________

Marcus wrote the first draft of Bluewater Bank's standard in the branch car park at ten past six, on the back of the delivery note for the printer. He had just lived through section A. Harbour Street's twenty-three desktops were mapped to a central queue the following week. When the next branch printer died, eight months later, the technician who replaced it was back at head office before lunch. Nobody asked whether the bank needed a specialist.

Frequently Asked Questions

We have ten people and two printers. Do we really need a print server?
You need the idea more than the hardware. One machine that is always on, holding the two queues and the two drivers, is a print server. It means a replaced printer is one change rather than ten visits. If even that is too much, give both printers fixed addresses and write the driver and settings down in the knowledge base. Accept that each change is a round of the office.
Some of our printers accept jobs from the operating system's built-in driver with no maker software at all. Is that enough?
For plain printing, often yes, and it removes a driver to manage. The queue on the server still earns its place for the defaults, the name, the mapping and the single place to look when the queue sticks. Use the built-in driver on the server's queue where it does the job. Use the maker's driver only where a feature such as a finisher or a special tray needs it.
What about people working from home with their own printers?
A home printer is outside the standard: it is the person's own device on their own network, connected directly. The desk's support for it is whatever the remote-work policy says, which for most desks is none beyond a knowledge base article. The office queues are reached from home only over the remote connection, and most desks do not map them to home machines at all. Say this plainly in the scope so the question stops arriving as a ticket.
Users complain that the new names are long. Should we shorten them?
Shorten the display name, not the information. "Floor 2 East, kitchen (mono)" is shorter than the full form and still says where and what. The test is whether a person on floor three could pick the wrong one by accident; if the name passes that test, it is short enough. Model numbers and serial numbers can go entirely.
How do we handle the person who insists on their own driver for a special application?
As an exception in section G, with their name, the reason, who approved it and a review date. If the application genuinely needs a feature the shared driver lacks, the exception is legitimate; if it is habit, the review date is when it ends. One named exception is fine. Twenty unnamed ones are the situation the standard exists to end.
A driver update broke printing for a whole floor. What should we have done differently?
Treated it as a change. Write a note saying what was being updated and why. Print a test page from one ordinary machine and one from the fussiest application on that floor before leaving the update in place. Keep the previous driver on the server so rollback is a few minutes. Do updates early in the day and early in the week. Then the people who will notice are at their desks and the technician who did it is still in the building.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.