If you have moved a clinic, a registration desk or a records team onto Azure Virtual Desktop and the scanner has disappeared, you have probably already found the sentence. It sits in Microsoft’s redirection reference for AVD, under the scanner row, and it reads in full:
“Scanner redirection doesn’t include TWAIN support.” (Microsoft Learn, Redirection over the Remote Desktop Protocol, updated 20 June 2025)
That sentence is doing a lot of work, and the rest of the page does not explain it. This post does. It covers what AVD actually does with a scanner, why that fails for the scanning most organisations do, and the three ways people work around it, including the one we sell. Where a workaround is good enough, I say so.
AVD and Windows 365 redirect a scanner using what Microsoft calls opaque low-level USB redirection. The client does not understand that the device is a scanner. It forwards raw USB request blocks across the RDP connection and lets a driver on the session host make sense of them. Microsoft lists the consequences on the same page:
There is also a platform restriction that matters more than the TWAIN line for most hospital estates. Microsoft’s feature comparison for Windows App shows scanner and USB redirection supported on the Windows client only. macOS, iOS and iPadOS, Android and ChromeOS, and the web client are all listed as unsupported (Windows App feature comparison, updated 29 July 2026). If your endpoint is a Linux thin client or a browser, there is no scanner path into AVD at all, TWAIN or otherwise.
Printing is a one-way push. The session sends a rendered job and does not care what happens next. Scanning is a two-way, stateful conversation. The application in the session opens the device, negotiates capabilities, holds the handle open across a multi-page batch, and streams image data back in real time. TWAIN, the interface almost every document scanner and every EHR or document management scan module speaks, was designed for that conversation to happen on the same machine as the scanner.
Tunnel that conversation over a WAN as raw USB traffic and three things go wrong. Latency between the driver and the device stretches from microseconds to tens of milliseconds and many scanner drivers time out or abort a batch. The driver has to live in the session host image, which in a pooled AVD host pool means a driver per scanner model in the gold image. And the device is locked to one session, which is fine for a private desk and useless for a shared registration workstation where three people badge in over a shift.
None of this is theoretical. The accepted answer on Microsoft Q&A for a local scanner not appearing in AVD is to install the scanner driver on the client, enable the group policy “Allow RDP Redirection of other supported RemoteFX USB devices from this computer,” disable “Do not allow supported Plug and Play device redirection,” and then, in the answer’s own words, “Reboot is mandatory” (Microsoft Q&A, updated 17 November 2025). On the Windows 365 community forum, an administrator running scanning for 100 users on three AVD hosts asked in January 2025 how to do TWAIN scanning in Windows 365, because the per-user licensing of their current tool would be “prohibitively expensive” on Cloud PCs. The thread has zero replies (Microsoft Tech Community, 9 January 2025).
This is the native route and it is the right answer for a small number of cases. If the endpoint is a Windows PC, the connection is on the LAN or a low-latency link, the scanner is a single-user desk device, and you are happy to keep its driver in the session host image, it works. Set the two group policies above on the client, install the driver in the image, reboot, and the scanner appears in the session as a USB device.
Where it stops being good enough: non-Windows endpoints (nothing), shared workstations (device is exclusive to one session), remote sites over a WAN (batch timeouts), pooled hosts with more than a handful of scanner models (driver sprawl in the image), and any scanner whose driver is not certified for the server OS you are running on the host. That last one bites hospitals hard because scanner fleets are old and mixed.
Vasion, PaperCut and LRS all sell scanning that runs on the multifunction printer panel and sends the file to email, OneDrive, SharePoint or a folder. Microsoft’s own version, “Scan with Universal Print,” is in preview as of July 2026 with general availability planned for December 2026; the roadmap describes scanning at a multifunction printer and receiving “an email notification that my scan is ready to download” (Microsoft 365 roadmap item 519572, via M365 Admin, 24 October 2025).
For back-office document capture this is fine, and for some teams it is better than desktop scanning. What it does not do is originate the scan inside the patient record or the case file. The user scans at the copier, walks back, finds the file, and attaches it to the right chart by hand. Every step of that is an error and a delay, and in a registration or ED workflow the whole point of scanning the insurance card or consent form at the desk is that it binds to the correct record at capture. If that binding matters to you, this option is not a substitute for scanner redirection, and waiting for Universal Print scanning will not change that.
The third option is software that presents a virtual TWAIN (and WIA) scanner inside the session and handles the conversation with the physical scanner on the endpoint over the RDP virtual channel, compressing the image data rather than tunnelling raw USB. The scanner driver lives on the endpoint, where the manufacturer intended it, and the session host image carries one virtual driver instead of thirty real ones. Because the device is addressed per session rather than per USB port, shared workstations work, and because the protocol is built for latency, WAN sites work.
Several products do this, and if you are evaluating them the questions to ask are the same for all of us: which endpoint operating systems have a client (Windows only, or Linux thin clients too), whether TWAIN and WIA are both presented in the session, how licensing works when session host VMs are rebuilt (a real issue on AVD, where hardware IDs change with every host), whether the same product also handles printing so you are not running two agents, and what the price is without a sales call.
This is what ScrewDrivers does. [Engineer: confirm and complete. The current tricerat.com scanning page states support for Citrix, Omnissa Horizon, RDP, Azure and IGEL, a universal virtual scanner driver in the session, and up to 10x faster black-and-white and up to 4x faster colour scanning; please replace with the exact current ScrewDrivers version number, the supported AVD/Windows 365 configurations, the Linux thin-client clients we ship today, and any honest limits, for example scanner classes or Windows App configurations we do not cover. If we cannot state something with a version number, leave it out.] Scanning and printing run in the same agent under concurrent-user licensing, which for an AVD host pool means the licence follows the user, not the VM.
Four questions decide which of the three options you need, and you can answer all of them in an afternoon:
If you get through the four questions and option 1 covers you, use it; it is already paid for. If it does not, the cost of finding that out after go-live is a registration desk that cannot scan on a Monday morning, so it is worth finding out now.