Microphones don't reach RDS sessions out of the box — Microsoft's own docs say audio recording redirection is not allowed by default when connecting to Windows Server. Pithflow doesn't need it: dictation runs on your local PC, and only the cleaned-up text enters the session, the way your typing and pasting already do.
Because Windows Server ships that way, twice over. Microsoft's RD Session Host audio documentation is blunt: "By default, audio recording redirection is not allowed" when connecting to a Windows Server host. And even before policy enters the picture, the Windows Audio service — which the doc instructs admins to start manually — isn't running on a typical server. So Win+H inside the session opens its panel, waits politely, and hears a microphone that, as far as the server knows, does not exist. The long-running Microsoft Q&A threads about unrecognized microphones in Remote Desktop sessions are this default, encountered one confused user at a time.
They can — it's two changes per host: start the Windows Audio service and enable Allow audio recording redirection under Computer Configuration › Administrative Templates › Windows Components › Remote Desktop Services › Remote Desktop Session Host › Device and Resource Redirection. But look at what that buys. Every user's raw audio now streams across RDP into a server shared by the whole team, session hosts need the change rolled out and maintained, and Microsoft's current redirection guidance adds a trap for layered environments: where host pool settings and Group Policy both apply, "the most restrictive setting is the resultant behavior." After all that, the recognizer waiting at the end is still plain Win+H — no punctuation intelligence, no cleanup, no tone control. It's a lot of plumbing for a mediocre faucet.
By never asking the server to hear anything. Pithflow runs on your local PC: hold the hotkey, speak, and it captures the audio locally, runs AI cleanup on the transcript, and delivers the finished text through the keyboard and clipboard forwarding your RDP client already provides — the text goes onto your local clipboard and is pasted into the focused field in the session, with a typed-keystroke fallback. The session host receives input indistinguishable from you typing. No agent on the server, no policy change, no Windows Audio service. This is the same architecture behind Pithflow's remote desktop dictation support generally; the terminal-server case is just its purest form.
Here's the dependency, stated plainly every time we describe this: the paste path rides on RDP clipboard redirection. Microsoft's policy reference for Do not allow Clipboard redirection notes that RDS allows clipboard redirection by default — but hardened hosts enable that policy, and where they do, pasting into the session is blocked and Pithflow falls back to typed keystrokes. Don't take a landing page's word for how your host is configured, ours included: pilot one seat first and let a real dictation answer.
| Prerequisite | Win+H in the session | Pithflow (local capture) |
|---|---|---|
| "Allow audio recording redirection" enabled | Required (off by default, per Microsoft) | Not needed |
| Windows Audio service running on the host | Required | Not needed |
| Per-host rollout and maintenance | Yes — every session host | No — install per user PC |
| Raw audio crossing RDP | Yes | Never — text only |
| Works when clipboard redirection is blocked | Unaffected | Paste path blocked — pilot one seat first |
Yes — Terminal Services became Remote Desktop Services with Windows Server 2008 R2, and 'terminal server' survives as the everyday name for an RD Session Host: one Windows Server that many users log into over RDP at once. Everything on this page applies to both names, because it's the same technology.
No. Pithflow installs on each user's local Windows PC — the machine running the RDP client. The session host needs no agent, no policy change, and no Windows Audio service tinkering. Sessions receive text through the same input path as everyone's normal typing and pasting.
Then Pithflow's primary delivery — placing the finished text on your local clipboard and pasting into the session — is blocked, leaving the typed-keystroke fallback. Microsoft's policy reference says RDS allows clipboard redirection by default, but plenty of hardened hosts flip it. Test with one seat on the free tier: one dictation into your real session settles it.
The architecture does. AVD and Cloud PCs speak RDP, and Microsoft documents the same 'Allow audio recording redirection' machinery for them, layered with host pool RDP properties where the most restrictive setting wins. Pithflow doesn't depend on any of it — if you can type into the remote window, dictated text can arrive the same way.
The host only ever receives text. Audio capture, transcription, and cleanup all happen off-host — on the user's machine and Pithflow's cloud pipeline — so from the server's point of view a dictation is a paste or a burst of keystrokes, the same load as typing fast.
Free tier: 2,000 words a week, no card. Installs on your PC — the server never changes.
Full background on the architecture: remote desktop dictation guide.
