By David,
Printing is the part of an Azure Virtual Desktop project nobody budgets time for, and the part users notice first. The desktops come up, the apps launch, and then on Monday morning someone in a branch office clicks Print and nothing comes out.
It's also one of the most common migration headaches. Citrix and VMware Horizon estates often carry years of print plumbing (universal print drivers, print servers in every site, vendor print add-ons) that doesn't come across to AVD as-is. You have to choose a printing model again.
This guide walks through every option you have for Azure Virtual Desktop printing, what each one costs you in drivers, traffic and operations, and how direct-IP printing lets you run without a print server at all. It's vendor-neutral until the last section, where we show how Atlas Spool approaches the same problem.
The five ways to print from AVD
There are five common models. Most real estates end up running two of them side by side.
1. RDP printer redirection
The user's local printers follow them into the session. When they print, the session renders the job with the Remote Desktop Easy Print driver and sends it back over the RDP connection to the client device, which prints it on whatever printer it can see. In AVD you control this with the host pool's RDP properties (Device redirection → Printer redirection); by default local printers are redirected and the local default stays the default (Microsoft Learn).
- Good for: home workers and laptops printing to the printer on their desk.
- Watch out for: every page travels from Azure down the user's connection and back out to the printer, so large or graphics-heavy jobs are slow on thin links. Thin clients and zero clients often have no printers to redirect. And the printer list depends on the device the user happened to connect from, which makes "the shared printer on floor 2" unreliable.
2. A classic Windows print server
The model most migrating estates already have: a Windows Server runs the Print Server role, hosts the queues and drivers, and session hosts connect to its shared printers through Group Policy or a logon script.
- Good for: central control of queues, drivers and permissions, with tools every Windows admin knows.
- Watch out for: the server is now infrastructure you run in Azure or on-premises, patch, back up and make highly available. If the print server sits in Azure and the printers sit in branch offices, every job crosses the WAN twice: from the session host to the server, then from the server to the printer. Point and Print driver installation was locked down after the 2021 PrintNightmare vulnerabilities, so driver distribution from a print server needs more deliberate configuration than it used to.
3. Microsoft Universal Print
Universal Print is Microsoft's cloud print service. Printers register with Universal Print (natively, if the printer supports it, or through the Universal Print connector running on a Windows machine on-premises), and users add them from Windows like any other printer. Jobs go to the cloud service and then down to the printer.
- Good for: organisations already standardised on Microsoft 365 that want to retire on-premises print servers, with users and printers managed in Entra ID.
- Watch out for: it is licensed per user and included in many Microsoft 365 and Windows Enterprise subscriptions, with a pooled monthly allowance of print jobs per license (Microsoft Learn). Check your own plan's allowance before you size it. Printers without native support still need a connector host on-premises, and every job makes a round trip through the service.
4. Third-party print management
Products such as Vasion Print (formerly PrinterLogic) replace print servers with centrally managed direct-IP printing: an admin console defines printers and deployment rules, and a client on each machine installs them so jobs go straight to the printer (Vasion). Many of these products add features such as pull printing, secure release and usage reporting.
- Good for: large, multi-site estates that want central management without servers, or need secure-release printing.
- Watch out for: another vendor, another agent on every host, and another subscription priced separately from your AVD tooling.
5. Direct-IP printing
The session host prints straight to the printer's IP address over the network, using a standard TCP/IP printer port and a locally installed driver. No server, no cloud relay, no client device in the path.
- Good for: session hosts that have a network route to the printers (site-to-site VPN or ExpressRoute to the branch, or printers in the same virtual network), which is the normal shape of an enterprise AVD deployment.
- Watch out for: done by hand, it doesn't scale. Someone has to install the right driver and create the right printers on every host, keep golden images and running hosts in sync, and remove printers when they're retired.
That last point is the whole problem, and it's what the rest of this guide is about.
Comparing the options
| RDP redirection | Print server | Universal Print | Third-party | Direct-IP | |
|---|---|---|---|---|---|
| Servers to run | None | Print server (often one per site) | Connector host for non-native printers | Usually none | None |
| Where jobs travel | Host → user's device → printer | Host → server → printer | Host → cloud service → printer | Host → printer | Host → printer |
| Driver management | Easy Print on the host, real driver on the client | Central, on the server | Microsoft's IPP-based class driver for native printers | Vendor console | On every host |
| Branch-office traffic | Over the user's connection | Can cross the WAN twice | Through the internet to the service | Direct | Direct |
| Extra cost | None | Server compute, storage, licensing and admin time | Included with many Microsoft 365 plans, with a monthly job allowance | Per-user or per-printer subscription | None, but admin time per host |
| What breaks at scale | Slow jobs on poor links, thin clients | Server patching, HA, Point and Print policy | Job allowance, connector availability | Another agent and contract to manage | Keeping every host's printers and drivers in sync |
The pattern most teams settle on: RDP redirection for home printers, direct-IP for office printers. Office printers sit on networks the session hosts can already reach, so a direct path is the shortest, cheapest and most reliable one. What's left is making direct-IP manageable.
Direct-IP printing explained: RAW, LPR and IPP
A direct-IP printer in Windows is a printer object that points at a Standard TCP/IP port (the printer's address plus a protocol) and a driver. Three protocols cover almost every network printer.
RAW (port 9100)
Also called JetDirect or AppSocket. The host opens a TCP connection to port 9100 and streams the rendered job. There's no queueing protocol on top, just bytes to the printer.
- Use it for: almost everything. It's the default on most office printers and multifunction devices, and the simplest to troubleshoot (if the host can reach port 9100, it can print).
LPR (port 515)
The Line Printer Daemon protocol from the Unix world. The job is submitted with a queue name, which some devices use to pick a print mode or tray.
- Use it for: older devices, print appliances, or printers whose documentation asks for a specific LPR queue name.
IPP (port 631)
The Internet Printing Protocol runs over HTTP. It lets the host ask the printer about its status and capabilities as well as send jobs, and it's the basis of modern driverless printing.
- Use it for: newer printers that support it well, especially where you want richer status from the device.
Rule of thumb: use RAW/9100 unless the device documentation says otherwise. Choose LPR when a device needs a named queue, and IPP when the printer supports it well and you want its status.
Whatever the protocol, the network path has to be open: a route from the session host subnet to the printer subnet, and the printer's port allowed through any firewall or network security group on the way.
Targeting printers: host pools, users and self-service
Once printers are direct-IP, the next question is who gets which printer. In AVD that usually maps onto three layers:
- Host pool. Hosts often already line up with a site or department, such as a London pool or a Finance pool. Give every host in that pool the printers on that floor.
- Specific users or groups. The exceptions: the finance team that needs the cheque printer, the shipping desk with a label printer, the director with a printer in their office. Target these by user or by Entra ID group so they follow the person across hosts.
- Self-service. The long tail: printers some people need occasionally, like the plotter or the meeting-room printer. Rather than push them to everyone, let users add them on demand from a list you've approved.
On pooled host pools, remember that printers are installed on a host that many users share. Assigning per user means installing when the user signs in, setting the right default for that user, and cleaning up afterwards, which is where scripts and Group Policy Preferences start to strain.
How Atlas Spool does it
Atlas Spool is the printing module of Atlas AVD, and it takes the direct-IP route.
The idea is simple: define each printer once, assign it, and let the Atlas AVD Agent already on your session hosts install it. There is no print server and no print relay. Print jobs go straight from the session host to the printer, and Atlas never receives, spools or relays document data.
Define printers once
An admin adds each printer once with Add printer: its name and location, its address (an IP address or a DNS name) and port, the protocol, its driver, and capabilities such as colour and double-sided. Spool installs printers over RAW (JetDirect / 9100) or LPR with a named queue, which covers the office printers and multifunction devices most estates run.
If you already run Atlas Reach, you don't have to type every printer in. The Discovered tab lists the printers Reach agents found configured on your Windows devices, and Convert to Managed turns one into a managed printer in one step. Discovery only reports what's there; it never installs anything.
One driver repository
Every printer installs from the Driver repository: a built-in catalogue of universal drivers from Microsoft, HP, Xerox, Canon, Ricoh, Konica Minolta, Lexmark, Kyocera, Brother, Epson and Zebra, plus your own drivers, registered by name (already on your hosts) or uploaded as a driver package. A printer can only use a driver from the repository, so a mistyped driver name never reaches a host, and every host installs the same driver for the same printer.
When a printer needs an uploaded package, the agent verifies the package before staging it into the host's driver store, then installs the printer from there. Installers (.exe and .msi files) aren't accepted, only driver packages.
Assign by host pool, host, user or group
Assign a printer to a host pool, a specific session host, a user (by UPN), an Entra ID group, or an Atlas Reach device group, and tick Set as default printer where it should be the default. The agent on each host works out which printers apply to it and to the people signed in to it, installs them as direct-IP printers, sets each user's default, and removes printers that are no longer assigned. There's no image to rebuild when a printer is added or retired.
Printers are installed for the whole machine, as Windows printers usually are. On a multi-session host, that means everyone on the host sees the printers assigned to anyone signed in to it, while each user keeps their own default.
Self-service printers
Set an assignment to Self-service instead of Install automatically, and users add the printer themselves: they choose Add printers… from the Atlas Reach tray icon and pick from the printers you assigned to them, with no extra sign-in. Their choices follow them to whichever host they land on.
Per-host rollout health
The agent reports the install state of every printer on every host (Installed, Failed, Pending or Removed) with the error message when something goes wrong. Open a printer and its Rollout health shows each host's state, message and last attempt, so "the printer is missing on host 7" becomes a specific driver or connection error you can fix rather than a ticket you have to investigate. Failed installs are retried automatically, backing off so a broken printer doesn't hammer the host, and retried straight away when you fix the printer's definition.
Pricing
Atlas Spool is available on every Atlas AVD plan, including Community, and billed by use in units, drawn from the same pooled unit allowance as the other metered modules. The pricing page has the current rate.
Which printing model should you use?
- Mostly home or hybrid workers printing to their own printers? Leave RDP printer redirection on and stop there.
- Office printers, and session hosts with a route to them? Use direct-IP. It's the shortest path and needs no servers. Manage it with a tool rather than by hand once you have more than a handful of hosts or printers.
- Already standardised on Microsoft 365 and comfortable with its job allowance? Universal Print is a reasonable way to retire print servers, especially for printers with native support.
- Need secure-release or pull printing? That's where dedicated print management products earn their place.
- Keeping a print server? Put it close to the printers, not in Azure, so jobs don't cross the WAN twice.
Planning a move from Citrix or Horizon? Printing is one of the first things to settle, so it's worth deciding before the pilot. While you're designing the rest, see the top 10 Azure Virtual Desktop mistakes to avoid, how to deploy AVD in under 30 minutes, and how to reduce your AVD costs.
FAQ
Can Azure Virtual Desktop print without a print server?
Yes. RDP printer redirection, Universal Print and direct-IP printing all work without a print server. For office printers, direct-IP is usually the best fit: the session host prints straight to the printer's IP address over RAW (9100), LPR (515) or IPP (631).
Does AVD support printer redirection?
Yes. AVD redirects the client device's printers into the session by default, using the Remote Desktop Easy Print driver. You can turn it off or change it in the host pool's RDP properties.
Why is printing slow in Azure Virtual Desktop?
Usually because of the path the job takes. With RDP redirection, every page goes from Azure down the user's connection to their device. With a print server in Azure and printers in a branch, every job crosses the WAN twice. Printing direct from the session host to the printer removes those extra hops.
Do I need Universal Print for AVD?
No. Universal Print is one option. It suits organisations that already have it in their Microsoft 365 licensing and want a Microsoft-run cloud service. Direct-IP printing reaches the same goal, with no print server, without sending jobs through a cloud service.
Which port should a direct-IP printer use?
Port 9100 (RAW) for most printers. Use 515 (LPR) when a device needs a named queue, and 631 (IPP) for printers that support IPP well.
How do I deploy printers to specific users on a pooled host pool?
Install them based on the signed-in user's identity or group membership, set that user's default, and remove them when they no longer apply. You can script this with Group Policy Preferences or logon scripts, or use a tool that does it for you. Atlas Spool assigns printers by host pool, session host, user, Entra ID group or device group and handles all three steps on each host.
Does Atlas Spool see my print jobs?
No. Print jobs go straight from the session host to the printer. Atlas Spool manages the printer definitions, assignments and install state, and never receives, spools or relays document data.