Best Practices for self-hosted Evolution Printer configuration

Evolution payroll service bureaus who host their own servers — that is, not on the SaaS environment — universally have printers defined in VMR, but I've observed widespread differences in how each bureau implements things.

Recall that any given printer might be used directly from the Evolution server, or it might be printed from a staff member's workstation, and even though the same physical printer is used, they won't be defined the same way.

This post attempts to offer some best practices.

Install the "Print Management" tool

The standard control-panel applet does a serviceable job managing printers, but on newer Windows systems it's far easier to use the Print Management tool via the "Print and Document Services" role via the Server Manager. Print Management is essentially the professional version of the consumer-ish/toy control panel printer applet.

Request Broker machine should have only locally-installed printers

Windows allows for installation of two kinds of printers, local, and network shared, and it's unfortunate that the terminology gets confusing here.

A Network Shared printer is where the printer and all the drivers and configuration are defined on a central machine — perhaps the main fileserver or domain controller — and other servers or users install printers that forward the print jobs to that server.

Network shared printers have names like \\MYSERVER\HP9050, which are structured like other network resources such as file shares. In this case, MYSERVER is the name of the print server machine, and HP9050 is the printer's shared name. These can typically be installed by any user (including those without admin rights) because they are generally trusted by the domain administrator.

The Evolution Request Broker should not use this kind of printer: instead it should use a printer that's locally installed on the RB machine itself by an administrator, as an unfortunately-named TCP/IP Network Printer; this is still considered a local printer as far as the Windows print system is concerned.

Technically it may be possible to actually use network-shared printers for VMR printing, but this is strongly dis-recommended. Evolution printing—especially checks—are highly sensitive to specific printer and driver settings, and once the settings are configured properly on the RB machine, they won't be impacted by any changes made on the main printserver.

Collateral damage of this practice is that VMR printers typically have to be installed twice: once on the RB machine, and again on the main printserver (where they can be shared to the rest of the users).

Request Broker machine should have only VMR printers installed

Though an enterprise might have many printers, including many dedicated to payroll, the RB machine should only have printers defined that are configured for printing in VMR. Do not include other printers, even if they are used more broadly for payroll, because these extra printers pollute the Evolution VMR printer configuration.

Do not share printers from Request Broker

Many bureaus use the RB machine as a de facto print server for the entire network, and though it technically doesn't break anything, it makes it far more difficult to migrate to a new Request Broker machine when the old one ages out. Having a long list of shared printers—and users who use them—is yet another thing you have to sort out when moving the RB.

Because moving the Request Broker is painful enough as it is, it's wise not to make it harder by doubling up as a print server for the rest of the office.

Disable RDS Printer Redirection on the RB machine

A useful feature of the Remote Desktop protocol is that it can bring a client's desktop printer (perhaps working at home) to the logged-in server at the office by temporarily installing the home printer driver on the server. Then,

Then, if the user wants to print something from the server, her home printer is available via a printer named like: HP LaserJet 4100 (from HOMEPC) in session 2. This works really well and is very, very useful for remote workers.

But not for VMR: though those printers are uninstalled when the user logs out of the RDP session, if the user restarts Evolution services—perhaps after installing an update—we find that the Request Broker can detect that printer and store it in the VMR configuration. This is cluttersome.

The mechanism for disabling "Client Printer Redirection" depends on the version of Windows server, but resources are readily available via Google or Bing.

For HP-branded printers, Always use the "Universal PCL" driver

It seems compelling to use model-specific drivers when available, but this has proven to make things much more difficult than by using an HP Universal PCL driver that you obtain from the HP support website.

There are two reasons for this difficulty:

• Moving to a new Request Broker machine virtually always means changing operating systems, and it's very common that the "same" driver for the new OS doesn't work the same as the "same" driver for the old OS. This is very painful.
• Replacing a printer with one of a different model means a lot of reconfiguration of trays and settings and the like.

I've found over the years that the Universal PCL drivers are far more consistent, both across operating systems, and between different models of HP printers, and though you can't avoid re-testing VMR after a printer or RB change, it's just far easier when the same driver is used; the driver developers

As a side note, a longstanding bit of Evo printing lore is "Use the PCL 5e" driver, and though there was a good reason for this many years ago, it's no longer the case, and you can use either the PCL5 or the PCL6 driver for pretty much any printer (though some older printers can't do PCL6).

There is no reason not to install both PCL5 and PCL6 drivers on the RB machine and use whichever version works best for any given printer; occasionally you may have to switch back and forth to get some combinations of trays and media right. You probably don't need to install any other print drivers for HP machines.

Pick a good naming scheme for printers, and stick with it

When a new printer is brought into the building, some thought should be given to a good name. Best are names that correspond closely to what you call them in practice, and though "The printer next to Steve's office" is not a great actual name, it's better than "PRINTER7" that doesn't tell anybody anything.

For Evolution VMR printers, names like CHECKS1 or REPORTS3 are reasonable choices, given that VMR printers are typically in packout rooms. For non-VMR printers, "Main Office Printer" or "HP4050-Steve" could work.

Whatever scheme you choose, Stick with it. I recommend putting a label on the printer with its actual name, then use that everywhere you install the printer: on the Evo RB machine, on the central printserver, or the share name on the network.

It's very confusing to see "HP 4050 LaserJet 5e" on the RB machine, but shared as "REPORTS3"; there is almost never a good reason to use the default name offered by the Windows printer installation wizard.

Avoid using DHCP for printer IP address assignments

Every TCP/IP printer needs an IP address—of course—and some bureaus simply plug in a printer, allow it to acquire an IP address from DHCP, and use it that way. This works, but it pollutes the DHCP address space and makes it more difficult to replace a printer with a new one.

Either use the front panel to configure a proper IP address outside the normal DHCP range, or allow the printer to get a DHCP address and then telnet to the printer and change it.

When that HP9050 dies and you replace it with the another of the same model, it's going to have a different MAC (Ethernet) address and will this acquire a different IP address from DHCP, possibly orphaning the old IP. This ultimately gets sorted out, but it's just a lot of confusion that doesn't have to be.

It's possible to use DHCP with reservations such that a given device will always get the same IP, and to change that reservation if the underlying device does; this will also help getting the printer into DNS (with a consistent name-to-IP mapping).

Put all printer names in DNS

I've long been a stickler for a well-functioning DNS (Domain Name System) environment, and pretty much every device on a network needs a name. Servers, printers, firewalls, anything that has an IP address should have a name, and though Windows servers and many DHCP clients register names automatically, dumb devices do not (or they use an unhelpful default name such as "NPI852100".

By defining every device with a name in DNS, both forward and reverse, it makes network troubleshooting much easier.

In addition, doing this robustly gives a nearly free IP address allocation survey by looking at the PTR records for the primary LAN; it will show which addresses are available and which are not, this saves a lot of effort maintaining a separate spreadsheet or the like.

These guidelines are not etched in stone, and there are good reasons for deviating from them in some circumstances, but it's worth considering these in light of the rationale given.

I believe many of these practices may apply to customers on the SaaS environment, whether classic or AWS, but I haven't really dug in enough yet to know.

As a bit of background, I used to write print drivers for a living, so my technical knowledge of the Windows printing system is fairly extensive.