Microphone forwarding to an RDP server on Windows
Introduction
A remote desktop session plays server sound on the local computer by default, but it carries nothing in the opposite direction. Audio capture redirection has to be enabled on both sides: the client offers the local microphone to the session, and the server accepts the offered device. This tutorial covers the client configuration in Remote Desktop Connection, the services and policies the server needs, the registry value that controls the feature, and the check that proves the microphone actually reached the session.
Audience level: Intermediate
Estimated completion time: 30 minutes
End goal: By the end of this tutorial, the local microphone appears in the remote session as the Remote Audio recording device, and applications running on the server record from it.
Prerequisites
- Version coverage: Windows Server 2022 (build 20348) and Windows Server 2025 (build 26100) on the server side. Other releases are outside the scope of this tutorial.
- Server installed with the Desktop Experience option. The Windows audio stack is absent from Server Core installations, and audio capture redirection does not work there.
- Remote Desktop Session Host role service on the server. Step 3 covers how to confirm it.
- Local computer running Windows 10 or Windows 11 with Remote Desktop Connection (
mstsc.exe) version 10.x. - A microphone connected to the local computer and recognized by local Windows.
- Administrator rights on both machines. Editing the registry, Group Policy, and service startup types requires an elevated session.
- Network access to the RDP listener of the server, TCP port 3389 or the custom port configured on the host.
- Assumed knowledge: Server Manager, the Services console, Local Group Policy Editor, and Registry Editor.
Audio capture redirection travels inside the encrypted RDP connection and opens no additional port. The RDP listener itself remains the exposed surface, so restrict TCP 3389 in Windows Defender Firewall to the addresses your users connect from instead of leaving it open to the whole internet.
Step 1: Allow microphone access on the local computer
Windows privacy settings can block microphone access for every application on the machine, including the remote desktop client. Confirm the local state first, because a blocked microphone produces no redirected device and no error message.
In the search box on the taskbar, type Microphone privacy settings and open the result.
Set Microphone access to On, then set Let apps access your microphone to On.
Both toggles now report On, and the microphone is available to local applications.
Step 2: Enable audio recording redirection in Remote Desktop Connection
This is the client half of the feature. Without it the server never receives a capture device, no matter how the host is configured.
Press Win + R, then run the remote desktop client:
mstsc
The Remote Desktop Connection window opens in its compact form. Click Show Options to expose the configuration tabs, then open the Local Resources tab.
In the Remote audio group box, click Settings. The Remote Desktop Connection audio dialog opens with two groups: Remote audio playback and Remote audio recording.
Under Remote audio recording, select Record from this computer. Under Remote audio playback, keep Play on this computer so that server sound continues to arrive on the local speakers. Click OK.
Return to the General tab and click Save As to store the connection in an .rdp file. The audio choice is a per-connection setting, and an unsaved dialog reverts on the next launch.
.rdp file in a text editor to confirm them, or to set them without the dialog.
audiocapturemode:i:1 audiomode:i:0
audiocapturemode:i:1 enables capture from the local device and redirects it into the session. audiomode:i:0 keeps playback on the local computer.
Step 3: Confirm the Remote Desktop Session Host role service
Microphone redirection is a Remote Desktop Session Host feature, so the host needs the RDS role service rather than plain administrative remote access. The full walkthrough of Add roles and features in Server Manager, from Role-based or feature-based installation through Confirmation, is already documented step by step in Microphone forwarding to RDP server - Mac OS. Follow that installation there and return here for the microphone-specific configuration.
To check the current state on the server, open PowerShell as Administrator and query the role service:
Get-WindowsFeature RDS-RD-Server
Expected output:
Display Name Name Install State ------------ ---- ------------- [X] Remote Desktop Session Host RDS-RD-Server Installed
An [X] marker and the Installed state mean the role service is present. Available means it is not installed yet, and the installation from the linked tutorial has to be completed before the microphone can appear.
Installing the Remote Desktop Session Host role service starts the RDS licensing grace period and requires a restart. Plan the step for a maintenance window on a production host.
Step 4: Start the audio and redirection services on the server
Two services on the host handle the redirected device. Windows Audio (AudioSrv) builds the audio endpoints inside the session, and Remote Desktop Services UserMode Port Redirector (UmRdpService) handles redirection of local client resources into the session. Their stock state differs between releases. On Windows Server 2022, Windows Audio is set to Manual and stopped, so it has to be switched to Automatic and started. On Windows Server 2025, the same service is already Automatic and running out of the box, and this step changes nothing for it. UmRdpService is set to Manual and already running on both releases, which is the correct state and needs no change, as long as it is not Disabled.
Press Win + R and open the Services console:
services.msc
On Windows Server 2022, locate Windows Audio, open its properties, set Startup type to Automatic, then click Start. On Windows Server 2025, the service already reports Automatic and Running, so confirm the state and leave it alone. Repeat the status check for Remote Desktop Services UserMode Port Redirector. Its stock Manual startup type is correct, because the session host starts it when a client with redirected resources connects, but it must not be Disabled.
The same result is available from an elevated PowerShell prompt:
Set-Service -Name AudioSrv -StartupType Automatic
Start the service in the current boot:
Start-Service -Name AudioSrv
Both commands are safe to run on either release. On Windows Server 2025 they report success and change nothing, because the service already holds the target state.
Confirm the state of both services:
Get-Service AudioSrv, UmRdpService | Select-Object Name, Status, StartType
Expected output:
Name Status StartType ---- ------ --------- AudioSrv Running Automatic UmRdpService Running Manual
UmRdpService reports Running with a Manual startup type on both releases, and that is the expected state even before any client connects. The value to watch for is Disabled in the StartType column, because redirected devices never reach the session while the service stays disabled.
Step 5: Allow audio recording redirection in Group Policy
Two policy settings govern the audio channels of a session. Audio recording redirection is blocked by default on Windows Server, which is the most common reason a correctly configured client still sees the device for playback but records nothing from it.
Press Win + R and open the Local Group Policy Editor:
gpedit.msc
Navigate to the following node:
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection
Set Allow audio recording redirection to Enabled. Set Allow audio and video playback redirection to Enabled as well, so that playback and capture behave consistently in the session.
Apply the policy without waiting for the refresh interval:
gpupdate /force
Both settings now report Enabled in the policy list.
In a domain, the same two settings live under Computer Configuration\Policies\Administrative Templates\... in Group Policy Management Console. A domain policy overrides the local one, so verify the effective setting with gpresult /h C:\gpreport.html when the host is domain joined.
Step 6: Set the fDisableAudioCapture registry value
fDisableAudioCapture controls whether the host accepts a redirected capture device. A value of 0 permits microphone capture to be redirected into the session, and a value of 1 blocks it. The value lives in two independent locations, and mixing them up is the usual source of confusion.
The policy from Step 5 writes its own copy under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. That branch is managed by Group Policy and takes precedence when a session is established.
The per-listener value under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp is separate. Group Policy does not touch it: enabling Allow audio recording redirection and running gpupdate /force leaves it exactly as it was. Check and set it on its own, and do not expect the policy to correct it.
Registry edits take effect immediately and are not versioned. Export the key before changing anything.
reg export ` "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" ` C:\rdp-tcp-backup.reg
Read the current value from an elevated PowerShell prompt:
Get-ItemProperty -Path ` "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" ` -Name fDisableAudioCapture
Expected output:
fDisableAudioCapture : 0 PSPath : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\... PSChildName : RDP-Tcp
On a clean Windows Server 2022 or 2025 installation the property is present and already reads 0, so the usual outcome of this check is that nothing needs changing. If the value reads 1, or if the command reports that the property does not exist, set it to 0:
Set-ItemProperty -Path ` "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" ` -Name fDisableAudioCapture -Type DWord -Value 0
The same key is reachable in Registry Editor at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, where fDisableAudioCapture is a DWORD value.
A value of 0 lets every application in every session record from the connected client microphone. Enable it only on hosts where the users who log on are trusted, and leave it at 1 on shared servers that do not need audio input.
The listener reads the value when a session is established. Existing sessions keep the old behavior, so restart the server to apply the policy and the registry change together:
Restart-Computer
Verification
Reconnect with the saved .rdp file from Step 2, then check the recording device inside the session.
Press Win + R and open the sound control panel:
mmsys.cpl
Open the Recording tab. A device named Remote Audio is listed, its state reads Default Device or Ready, and it is not marked Disabled.
Speak into the local microphone and watch the level indicator next to Remote Audio. Movement in the indicator means audio is arriving from the client, which is the proof that redirection works end to end. A device that appears for playback but never moves on the Recording tab points to the recording-redirection policy in Step 5 being disabled, to the local privacy settings from Step 1, or to a microphone muted on the client.
For an application-level test, open Voice Recorder on the server, record a few seconds, and play the result back. Applications that let the user pick an input device have to select Remote Audio explicitly, since many of them keep the first enumerated device instead of the system default.
Reverting changes
Set the recording option in the client back to Do not record under Remote audio recording, or set audiocapturemode:i:0 in the .rdp file, to stop offering the microphone from a single client.
To close the feature on the server, restore the registry value:
Set-ItemProperty -Path ` "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" ` -Name fDisableAudioCapture -Type DWord -Value 1
Set Allow audio recording redirection back to Not configured in gpedit.msc, then run gpupdate /force. Return Windows Audio to its original startup type if the host does not need audio for anything else:
Set-Service -Name AudioSrv -StartupType Manual
Stop the service in the current boot:
Stop-Service -Name AudioSrv
Leave UmRdpService at Manual. It serves drive, printer, and port redirection as well, and disabling it affects far more than audio.
Removing the Remote Desktop Session Host role service requires a restart and drops all RDS session configuration on the host. Remove it only if it was installed for this tutorial alone and no published applications depend on it.
Troubleshooting
No audio devices are installed in the session, or the Recording tab is empty
Work backwards through the chain: the Remote Desktop Session Host role service (Step 3), AudioSrv running (Step 4), the policy enabled (Step 5), fDisableAudioCapture at 0 (Step 6), and the client set to Record from this computer (Step 2). A single missing link removes the device entirely rather than degrading it.
Remote Audio appears for playback but not for recording, or the device is listed on the Recording tab yet the level indicator never moves
This is the signature of a host where playback redirection is allowed and capture is not. Recheck Step 5 first, since the recording-redirection policy is the usual cause, then Step 6, and confirm with gpresult /h C:\gpreport.html that no domain policy overrides the local setting.
The device appears and then disappears after a reconnect
The audio choice was changed in the dialog but never saved to the .rdp file. Repeat the Save As action at the end of Step 2.
An administrative connection carries no capture device
Sessions opened with mstsc /admin connect to the console session instead of a Remote Desktop Services session, and audio capture redirection is not available in them. Connect without the switch.
The microphone works in one application only
The application is bound to a specific input device rather than the system default. Select Remote Audio in the audio settings of that application.
Conclusion and next steps
The local microphone now reaches the remote session as Remote Audio, and applications on the server record from it as they would from a locally attached device. The configuration spans four layers, which is worth remembering when a working setup breaks: the client offer, the host role service, the two services, and the policy with its registry value.
For other local hardware in a session, Connecting a USB webcam to an RDP Remote Desktop covers RemoteFX USB device redirection, which uses a different mechanism and different policies. Clients on Apple hardware follow Microphone forwarding to RDP server - Mac OS, where the server side is identical and only the client permissions differ. If the RDP listener is reachable from the internet, review the port and firewall scope in Change Windows Server RDP Port before adding audio input to the session.
Document Version: 2.3
Last Updated: August 2026
Owner: Technical Documentation Team
