I’d like to share a brief story — one with an important lesson — which happens to be true. Recently, a global professional services firm decided to accelerate its move to the cloud. For them, Azure Virtual Desktop (AVD) seemed the obvious choice.
They had thousands of users. They had seasonal workforce spikes. They had a mandate to reduce their on-premise infrastructure fast.
AVD checked all the boxes, but what no one expected was that printing—an afterthought in early planning—would nearly derail the rollout.
The AVD Rollout That Looked Perfect on Paper
Early pilots were smooth. Login times were fast. Applications behaved. The desktop team declared success. Then the business users went live.
Then Output Became the Bottleneck
Within days, familiar complaints surfaced—only louder this time:
- “My documents are going to the wrong printer.”
- “Printing worked yesterday but not today.”
- “Every time I log in, I see different printers.”
- “This session crashed when I tried to print.”
The root cause wasn’t AVD itself. The problem was a legacy on-premise Windows print architecture that was colliding with a new cloud-native desktop model. This environment still relied on session-host-based Windows print servers and hundreds of vendor-specific drivers. It also brought a relic from the legacy environment into the new cloud desktop environment: printer mappings that were tied to devices that no longer existed.
LRS Changes Output for a Cloud Desktop World
Instead of trying to “fix printing” inside AVD, the team reframed the question. What if the printing function didn’t belong in the desktop at all?
They implemented an enterprise output management platform designed to sit outside the virtual desktop layer. The shift was architectural, not cosmetic.
Soon, printing was decoupled from AVD sessions. Azure virtual desktop hosts no longer managed printers and queues, which helped eliminate driver chaos and host-specific configuration drift. Decoupling print from the desktop also enabled standardized queue installation, wherein queues provided during login were based on user, group, subnet or computer name.
This was a first step in the right direction, but there were other benefits to externalizing the print management function. For example, hundreds of printer drivers were reduced to fewer than ten drivers, resulting in smaller images, faster host provisioning, and a large decrease in man hours to support desktop printing.
As a result of these changes, output became more policy-driven. Instead of relying on Windows mappings, output was routed based on user role and workflow. Application context determined delivery. Better yet, users stopped thinking about printers entirely… which is exactly the goal.
IT staff regained visibility over their print processes, and for the first time, the organization could answer questions like:
- Who is printing the most?
- From which applications?
- To which destinations?
- Where are failures occurring?
Output stopped being a black hole. As a result, AVD adoption accelerated. Once printing was stabilized, AVD host pools scaled cleanly and login times continued to decrease. There was a sharp decrease in printing-related support tickets, which meant the desktop team spent less time firefighting and more time optimizing their environment.
What began as a risk to the project – the print process – became a force multiplier.
The Bigger Lesson
AVD projects don’t fail because of particular workflows. Rather, they fail because without a print infrastructure like LRS, they still rely on Windows print spooling based on technology from the 1990’s. LRS brings your enterprise into the future by creating a bulletproof print infrastructure. Our software is built from the ground up with security, efficiency, fault tolerance and reliability in mind.
TL;DR — with LRS in the mix, AVD can live up to its full promise.