Installing, sharing and securing a printer

Why this matters

Installation is where printer problems are created, and most of them are created by accepting defaults. A printer connected by whatever method was easiest, with whatever driver the operating system found, shared from whichever machine happened to be nearby — that combination produces support calls for years.

The exam asks about connection methods, driver types, sharing models and printer security, and each of those is a decision with a defensible answer. Printer security in particular is under-appreciated: a network printer is a computer with storage, an operating system and, frequently, a copy of every document anyone has sent it.

This is the applied lesson for the printers objective, so it is where the decisions live rather than the components.

The lesson

Drivers and page description languages, and what happens when the wrong one is used

A driver converts what the application wants onto the page into instructions the printer understands. The instruction language is a page description language, and the two that matter are:

• PCL, which is widely supported, fast, and relies on the driver doing more of the work.
• PostScript, which is device-independent and handles fonts and vector graphics precisely, favoured where layout fidelity matters.

Many printers support both, and many operating systems also offer a generic class driver that works without a manufacturer download.

The symptoms of the wrong driver are distinctive and worth recognising because they look like hardware faults:

• Pages of garbage characters — the printer is receiving a language it does not understand. Classic wrong-driver signature.
• Wrong fonts or wrong spacing — a substitution happening because the expected font is unavailable.
• Features missing: no duplex option, no tray selection, no stapling. The generic driver does not know the device has them.
• Everything prints but very slowly, often because the job is being sent as a large bitmap rather than as page instructions.

The correct driver is the manufacturer's, for that model and that operating system version, and on 64-bit Windows a shared printer may also need the 32-bit driver available for older clients.

Connecting by USB, by network, and by wireless, with the trade-offs of each

• USB. Simplest, fastest to set up, one machine only. Right for a personal printer at a desk. The limitation is that sharing it requires that machine to be switched on.
• Wired Ethernet. The right answer for any shared or business printer. Reliable, fast, and independent of any workstation. Give it a reservation rather than a static address where possible, for the reasons in lesson 11 — and note that a printer whose address changes is a printer that every client loses at once.
• Wireless. Convenient where cabling is impractical. Slower, subject to every wireless problem in lesson 41, and the source of "the printer disappeared" calls when the access point or the passphrase changes.
• Bluetooth. Short range, single device, used by portable and label printers.
• Infrastructure-free wireless — the direct modes offered by most modern printers — which let a device connect straight to the printer. Convenient, and it creates a second wireless network that is worth knowing exists.

Cloud and mobile printing services let a device print without being on the same network. They are convenient and they send the document via a third party, which is a decision rather than a default.

Sharing from a workstation against sharing from a print server

Workstation sharing attaches the printer to one machine, which shares it. Cheap, quick, and it makes that workstation a dependency: if it is asleep, off, or busy, nobody prints. It also means one user's machine is processing everyone's print jobs.

Print server sharing — a dedicated server, an appliance, or the printer's own network interface — removes that dependency. Clients connect directly or through a queue managed centrally. Drivers can be distributed from the server, which solves the "everyone has a different driver version" problem.

Direct network printing, where each client holds its own queue pointing at the printer's address, is the simplest for small offices. No server, no single point of failure, and the cost is that driver and configuration changes must be made on every client.

Choosing from a scenario:

• One user, one printer → USB.
• A few users, no server → network printer, direct queues.
• Many users, or centrally managed drivers, or accounting and quotas → print server.
• A printer that must work when a particular PC is off → never workstation sharing.

Secure print, user authentication, and why a printer is a device on your network

A network printer is a networked computer. It has an operating system, storage, a web interface, and frequently default credentials. The exam expects a technician to treat it accordingly.

The controls that matter:

• Change the administrative password. Printer web interfaces are routinely left on defaults, and they expose configuration, address books and sometimes stored documents.
• Update firmware. Printers receive security fixes and almost never get them applied.
• Disable unused protocols and services. Many printers ship with a long list of enabled protocols, most of which nobody uses.
• Secure print, also called pull printing or follow-me printing: the job is held until the user authenticates at the device. This solves the single most common real-world printer confidentiality failure, which is confidential documents sitting in the output tray.
• User authentication and accounting, which restricts who may print what, and produces per-user or per-department volume records.
• Audit logs, which record who printed what and when.
• Hard drive handling. Many multifunction devices store scanned and printed documents. That storage must be encrypted where the device supports it, and sanitised before disposal — a leased multifunction device returned with its drive intact is a genuine and recurring data breach.

Print queues: what a stuck job actually blocks, and how to clear one properly

A queue holds jobs and releases them to the printer in order. A job that fails in a way the spooler does not recognise sits at the head of the queue and blocks everything behind it, which is why "nobody can print" is so often one bad job rather than a printer fault.

The correct sequence to clear one:

1. Try cancelling the job normally. Often enough.
2. If it will not cancel, stop the print spooler service.
3. Delete the spool files from the spool directory. Jobs exist as pairs of files there, and removing them removes the queue's contents.
4. Start the spooler again.
5. Reprint.

Deleting spool files while the service is running does not work, because the service holds them open — which is why step 2 comes before step 3 and why people who skip it conclude the job is undeletable.

Related faults worth distinguishing:

• Printer shows offline while powered and reachable. Usually the client's view: the queue has marked it offline after failures and will not retry. Clearing the offline flag, or removing and re-adding the queue, resolves it.
• Jobs vanish with no output. Frequently printing to the wrong queue — two similarly named printers, one of which does not exist any more.
• Jobs print on the wrong device. The default printer, or a shared queue redirected by a policy.
• Access denied when printing. A permissions issue on a shared queue rather than a device problem.

The general lesson that carries into domain 5: a printer complaint is a queue complaint until the queue has been ruled out, and ruling it out is faster and cheaper than any hardware test.