No. Native Remote Desktop has no built-in scanner redirection. Windows RDP and Remote Desktop Services automatically redirect printers, drives, and the clipboard, but there is no equivalent mechanism for TWAIN or WIA scanners. To scan inside a remote session you must either redirect the raw USB device (unreliable for most business applications) or install dedicated scanner-redirection software.
This post explains the real reason scanning over Remote Desktop fails, why no version of RDS ships a "scanner equivalent" to Easy Print, and where USB device redirection, network scanners, and mobile apps are genuinely good enough versus where you need a dedicated redirection layer. We've spent over a decade troubleshooting TWAIN and WIA redirection inside RDS, Citrix, and VDI environments for more than 30,000 companies, and the same handful of root causes come up in almost every support ticket.
Why Native Remote Desktop Has No Scanner Redirection
The most common misconception we see is that scanning "should just work" the way printing does. It doesn't, and the reason is architectural rather than a missing setting.
When Microsoft built device redirection into RDP, they solved printing thoroughly. RDP Easy Print exposes a universal print driver inside the session, so the server can render a print job without the physical printer's driver ever being installed server-side. Drive redirection, clipboard, audio, smart cards, and serial ports each got their own handling through RDP virtual channels. Scanners never did. There is no "Easy Scan," no universal scanner driver, and no scanner redirection toggle in any version of Remote Desktop Services, from Windows Server 2008 R2 through Server 2025.
How RDP device redirection actually works
Remote Desktop multiplexes everything over a single connection using virtual channels. The device redirector (RDPDR) carries file system, printer, port, and smart-card traffic. Printing rides on top of that with the Easy Print driver doing the translation. Each redirected device type required Microsoft to define both a protocol extension and a server-side consumer that line-of-business applications could talk to.
Scanning was never given that treatment. There is no scanner channel in RDPDR and no server-side virtual scanner that applications can enumerate. So when a document management system running on the terminal server asks the operating system "which scanners are available?", the answer is whatever is physically attached to the server, which in a datacenter is nothing.
Why TWAIN and WIA make scanner redirection hard
Scanning is a fundamentally different problem from printing. Printing is a one-way push: the application generates a job and hands it off. Scanning is an interactive pull, and it's stateful.
A scanner is driven through one of three driver models. TWAIN is the dominant standard for business document capture; the application opens a Data Source Manager, negotiates capabilities (resolution, color depth, duplex, ADF vs flatbed), and pulls images back through a live session with the driver. WIA is Microsoft's consumer-oriented imaging stack, common on all-in-one inkjets. ISIS is a high-throughput model used by production scanners in capture-heavy environments.
All three assume the driver and the physical hardware live on the same machine as the application. The driver holds open device handles, maintains capability state across a multi-page batch, and streams image data in real time. You cannot simply forward that the way you forward a print job, because the conversation is bidirectional and latency-sensitive, and the driver state is bound to a specific session. This is the technical reason a generic "share my device" approach falls short for anything beyond a single flatbed page.
Why Won't My Scanner Work in Remote Desktop?
The symptom is almost always the same: the scanner works perfectly on the local PC, but inside the remote session the line-of-business application's scanner dropdown is empty, or it lists a scanner that throws an error the moment you press Scan.
.png)
The root cause is that the application is running on the server, and the server has no driver for, and no path to, the scanner sitting on the user's desk. The TWAIN Data Source Manager on the server enumerates server-side data sources only. Nothing bridges the gap between the user's local USB or network scanner and the TWAIN/WIA stack the application is querying remotely.
A pattern we see repeatedly: an administrator installs the scanner's driver on the terminal server hoping that exposes it. It doesn't, because the hardware still isn't physically present there. Worse, vendor driver installers on a multi-user server frequently create per-machine services and tray helpers that conflict across sessions, since most scanner drivers were never designed for concurrent multi-user use.
Can't I Just Use USB Device Redirection?
USB device redirection (RemoteFX USB redirection in RDS, or the equivalent in Citrix and VMware Horizon) can forward a raw USB device into the session. In theory the scanner appears as if plugged into the server. In practice it's unreliable for TWAIN-dependent business applications, and here is specifically why.
First, generic USB redirection forwards the device at a low protocol level, which means the matching vendor driver still has to be installed on the server, with all the multi-user conflicts described above. Second, raw USB redirection is sensitive to latency and bandwidth; scanners move large bursts of data and many models time out or corrupt batches when the USB conversation is tunneled over a WAN. Third, per-session device handle isolation means a device redirected into one session is exclusively owned by that session, so it can't be cleanly shared, and reconnects often leave a stale handle that blocks the next scan until the service is restarted.
Real-world examples where this bites hardest:
- Fujitsu ScanSnap and fi-series scanners rely on their own manager software and tightly coupled drivers; ScanSnap in particular expects its local manager to be running and rarely behaves over raw USB redirection.
- Kodak and Canon imageFORMULA production scanners push high page rates through ISIS or proprietary drivers and overwhelm a tunneled USB link.
- Signature pads and handheld barcode scanners that present as HID devices sometimes redirect, but document scanners almost never do so cleanly.
USB redirection can work for a single low-volume flatbed in a low-latency LAN. For an EMR, a DMS, or an accounting package that lives on a TWAIN dialog all day, it's a frequent source of support tickets.
When Native or Alternative Approaches Are Enough
We are not going to claim every scenario needs dedicated redirection software. Several alternatives are genuinely sufficient, and choosing the simplest one that meets your needs is the right call.
.png)
| Approach | How it works | Good fit when | Where it breaks down |
|---|
| Network scanner scan-to-folder / scan-to-email | The device scans to an SMB share, FTP, or email; the remote app picks the file up afterward | You only need the file on the server, your scanner has a network interface, and the workflow tolerates a two-step "scan then import" | The line-of-business app needs to drive the scanner directly through a TWAIN dialog; no live preview, duplex control, or page-by-page capture |
| Mobile scanner app | Phone camera app produces a PDF, synced to cloud storage the session can reach | Occasional, low-volume capture; remote/field staff with no dedicated scanner | Quality and consistency for archival documents; no integration with the capture screen of business software |
| USB device redirection | Raw USB forwarded into the session (RemoteFX / Citrix / Horizon) | Single flatbed, low volume, low-latency LAN, and you accept installing the vendor driver server-side | TWAIN-heavy apps, WAN links, multi-user servers, production and ScanSnap-class scanners |
| Dedicated scanner redirection (e.g. TSScan) | A virtual TWAIN scanner on the server maps to the user's local device; image data is compressed and carried over the RDP virtual channel | The app must scan directly through its own TWAIN/WIA interface, across any network, on a multi-user server | Adds a per-server software layer (overkill if scan-to-folder already solves it) |
The honest summary: if your scanner is a networked multifunction device and your users are fine scanning to a folder and then importing, you may not need any redirection product at all. The redirection problem only becomes worth solving when an application itself has to acquire the image, which is the norm in regulated, integrated workflows.
When Dedicated Scanner Redirection Makes Sense
The case for dedicated redirection is strongest when the scan has to flow straight into a specific screen of a specific application. Healthcare staff scanning patient records into an EMR press a Scan button inside the EMR; the document must land on the correct patient chart, often with duplex and OCR settings the app controls. Legal teams scanning signed contracts, accounting firms running high-volume document batches, and banks capturing checks and KYC documents for DocuWare, M-Files, or SharePoint all depend on the application driving a TWAIN source directly. Scan-to-folder breaks that integration; the user loses the in-app preview, the page-level controls, and the automatic indexing.
This is the gap dedicated redirection fills. Rather than forwarding raw USB, it installs a virtual TWAIN scanner on the server that any application can select like a local device. When the app starts a scan, the request is relayed to a small client on the user's PC, the local driver does the actual acquisition, and the resulting image is compressed and streamed back through the RDP virtual channel, with no vendor driver on the server, no open USB ports, and no per-session device conflicts.
.png)
TSScan implements exactly this model. It enumerates the user's local imaging devices, presents them server-side through a TWAIN-compliant virtual scanner, and uses Microsoft Virtual Channel technology so all traffic stays inside the existing RDP/Citrix/PCoIP connection. Because images are compressed before transit, it works over WAN links as well as LAN. It also covers cases raw USB redirection struggles with, including ScanSnap devices (which work through their local manager), and supports output to PDF, TIFF, JPEG, and BMP along with duplex capture. Licensing is per terminal server rather than per device or per client.
How it compares to other redirection tools
TSScan, RemoteScan, and FabulaTech Scanner for Remote Desktop all solve the same core problem, presenting a server-side virtual scanner that maps to a local device, and any of them is architecturally sound compared to raw USB redirection. They differ in licensing model, protocol coverage (RDP, Citrix, VMware, PCoIP, vWorkspace), client platform support, and compression behavior on constrained links. TSScan's distinguishing points are its per-server (rather than per-seat) licensing, lifetime updates on a one-time license, and Mac as well as Windows client support. If you are evaluating, the practical test is simple: run a trial of each against your actual scanner and your actual line-of-business application over your real network, because driver edge cases, not feature lists, decide the outcome.
A Note on Bandwidth and Image Size
.png)
A frequent surprise is how much raw data scanning generates, which is why compression in the virtual channel matters so much. A single A4 page scanned at 300 DPI in 24-bit color is roughly 25 MB uncompressed (about 8.7 megapixels × 3 bytes). A 50-page color batch is therefore well over 1 GB of raw image data before any compression. Drop to 300 DPI grayscale and each page falls to about 8 MB; bitonal (black-and-white, fax-style) capture is closer to 1 MB per page; push up to 600 DPI color and you are near 100 MB per page.
The lesson is twofold. First, match color depth and resolution to the document: 200-300 DPI bitonal or grayscale is plenty for text archival, and choosing it cuts transfer volume by an order of magnitude. Second, any redirection method that does not compress aggressively before sending data across the link will feel slow on a WAN, which is precisely where raw USB redirection tends to time out and where a compressing virtual-channel approach earns its place.
FAQ
Not with native Remote Desktop alone. Windows RDP redirects printers, drives, and the clipboard but has no scanner redirection. You can scan over a remote session by redirecting the USB device (unreliable for most business apps), by using a network scanner's scan-to-folder workflow, or by installing dedicated scanner-redirection software that presents a virtual scanner on the server. The right choice depends on whether your application needs to drive the scanner directly.
No version of Remote Desktop Services, from Server 2008 R2 through Server 2025, includes scanner redirection. Microsoft built the Easy Print universal print driver for printing but never built an equivalent for TWAIN, WIA, or ISIS scanners. The operating system on the server only enumerates scanners physically attached to that server, which in a datacenter is none. This is a deliberate architectural gap, not a configuration you've missed.
Because the application is running on the server, and the server has no driver for and no connection to the scanner on your desk. The TWAIN Data Source Manager on the server lists server-side data sources only, so the scanner dropdown comes back empty. Installing the scanner driver on the server doesn't help, because the hardware still isn't physically present there. A bridge between your local device and the server-side imaging stack is required.
You can forward a raw USB scanner with RemoteFX USB redirection or the Citrix/Horizon equivalents, but it's unreliable for TWAIN-dependent applications. The vendor driver still has to be installed on the multi-user server, batches time out or corrupt over higher-latency links, and per-session handle isolation causes stale-device errors after reconnects. It may work for a single low-volume flatbed on a fast LAN, but it's a common source of support tickets for production and ScanSnap-class scanners.
No. TWAIN assumes the driver, the hardware, and the application all live on the same machine, with a live, stateful, bidirectional session between the app and the driver. Native RDP provides no channel to relay that conversation between the server-side application and a locally attached scanner. Dedicated redirection software solves this by creating a TWAIN-compliant virtual scanner on the server and relaying acquisition to a local client.
The native limitation is the same across all of them: none provides built-in scanner redirection, but dedicated redirection products do support these platforms. Tools that use a server-side virtual scanner over a virtual channel typically cover RDP, Citrix, VMware Horizon/PCoIP, and Azure Virtual Desktop. Confirm the specific protocol and client OS you use is supported before deploying, since coverage varies by product.
Use an approach that keeps the driver local. A network scanner's scan-to-folder workflow needs no server driver at all, since the device writes the file to a share the session can read. Dedicated redirection software also avoids server-side drivers: the local client performs the acquisition with the local driver, and only the resulting image crosses the connection. Both avoid the multi-user driver conflicts that plague server-side driver installs.
It depends entirely on resolution, color depth, and compression. A 300 DPI 24-bit color A4 page is about 25 MB uncompressed, so a 50-page color batch exceeds 1 GB of raw data; grayscale drops that to roughly 8 MB per page and bitonal to about 1 MB. Choosing the lowest acceptable settings and using software that compresses before transit are what make WAN scanning practical. Uncompressed approaches are usually what feel "too slow" to users.
ScanSnap is a frequent pain point because it depends on its own manager software and tightly coupled drivers, and it rarely behaves over raw USB redirection. Dedicated redirection tools can support it. TSScan, for example, works with ScanSnap when the ScanSnap Manager is installed and running on the local PC and a compatible scan engine is selected. If you rely on ScanSnap in a remote environment, verify ScanSnap support explicitly rather than assuming general TWAIN support covers it.
Summary
Native Remote Desktop cannot scan because no version of RDP or Remote Desktop Services includes scanner redirection. There is no Easy Print equivalent for TWAIN, WIA, or ISIS devices, and raw USB redirection is unreliable for the business applications that drive scanners directly. For simple cases, a network scanner's scan-to-folder workflow or a mobile app may be all you need. When an application must acquire the image itself, as in EMR, DMS, legal, accounting, and banking workflows, a dedicated redirection layer that presents a server-side virtual scanner over the RDP virtual channel is the reliable answer.
Learn more about scanning over Remote Desktop with TSScan!
