Easy Print covers most printers with zero driver work - but label printers, special trays and some older models expose its limits. The fallback is an exact driver match on the server. Done carelessly it is also the fastest way to crash printing for the whole office. Here is the careful way.
Understand the bargain first. With Remote Desktop Easy Print, the server never loads your printer's real driver. With driver matching, the server maps the redirected printer to the identically named driver installed on the server, and you gain the printer's native features - but the server now runs third-party driver code for every job. On a shared RDS server, print drivers are the single most common cause of spooler crashes. That does not make this route wrong; it makes it a route to walk one step at a time.
If none of these is true, stay on Easy Print. "The real driver must be better" is a feeling, not a diagnosis, and on multi-user servers the stability of the built-in route wins most arguments.
Matching is by driver name string, not by printer model marketing name. Check the driver name on the client first: printer Properties > Advanced tab shows the driver in use, for example HP LaserJet Pro M404 PCL-6 (V4). The server needs a driver with that exact name for the server's architecture. A near-identical name from a different driver package will not match, and the printer silently falls back or fails. Download the driver from the printer manufacturer's own site for the server's Windows version - never from driver-download aggregator sites.
On a production server, install the driver package, not the full consumer software suite with its updaters, pop-ups and extra services.
printmanagement.msc) > your server > Drivers > right-click > Add Driver, and point the wizard at the extracted INFrundll32 printui.dll,PrintUIEntry /ia /m "Driver Name" /h "x64" /v "Type 3 - User Mode" /f C:\Drivers\printer.infgpupdate /force, and test with a fresh loginWhere the console offers driver isolation settings, setting a suspect driver to Isolated mode contains its crashes to its own process instead of the shared spooler - a sensible seatbelt for exactly this experiment.
Some printers - very old models, host-based GDI devices with fragile drivers - will never be safe citizens on a shared server. The professional answer there is not a fourth driver attempt; it is moving the problem out of the driver system entirely. That is the TSPrint approach from the video: the server never loads the printer's driver at all, the job is rendered and handed to the client, and the unstable driver only ever runs on the one PC it belongs to. Recognising which problem you have is the whole skill.
See the video for the driver-free alternative in action - TSPrint printing to a client printer without any server-side driver at all.
▶️ Watch Full VideoEither the policy still prefers Easy Print (disable Use Remote Desktop Easy Print printer driver first and run gpupdate), the driver name does not exactly match the client's driver name, or the session was already logged in. Matching happens at logon - test with a fresh session.
Modern Windows servers are 64-bit and need the 64-bit driver with the matching name. Supporting additional architectures is possible in Print Management, but a very old 32-bit-only printer is usually a better candidate for the TSPrint route than for driver archaeology.
Restart the Print Spooler service, remove the offending driver in Print Management (Drivers node, and its package), and re-enable Easy Print preference. Then check the PrintService/Admin log to confirm the crash signature is gone before users reconnect.