Azure Virtual Desktop local drives not showing: a troubleshooting checklist
Check AVD client support, host-pool drive selection, effective policy, and the saved-file destination before changing your file workflow.
Read the video transcript
0:00 — Your PC’s drives are missing in the AVD session
In the AVD session, File Explorer shows only the host's own disk. The PC's USB drive E: is not there.
0:08 — Record what the user actually connects with
Write down the endpoint, client, and resource for one affected user. Browser access offers upload and download, not the same drive experience.
0:17 — Inspect which drives the host pool selects
In the host pool's RDP properties, Device redirection controls drive selection. An empty drivestoredirect value selects no drives.
0:27 — A stricter policy on the session host wins
If Do not allow drive redirection is Enabled on the session host, a permissive host-pool setting cannot override it.
0:36 — Reconnect, then prove it with a test file
After the approved change, open a fresh connection, find the drive, save a harmless test file, and check it on the PC.
0:47 — Need the PC’s folders inside published apps?
TwinPane, on its own connection outside RDP, can map the PC's own folders into a published app's dialogs. Pilot it on one host and one PC.
When a local drive is missing inside Azure Virtual Desktop, identify which layer is responsible before changing settings. A supported client, the intended drive selection, and the effective policy must agree.
This checklist is for an administrator investigating an affected AVD desktop or published application. The video is an illustrated walkthrough: its Windows and host-pool screens are mock-ups, not recordings of the Azure portal or a live session. Microsoft references were checked on 27 September 2026.
1. Record the client and connection type
Capture the endpoint OS, client name and version, and whether the user opens a full desktop or a published application. Compare that combination with Microsoft's Windows App feature matrix. Browser access provides upload/download functionality; do not expect the same local-drive experience as a native client.
For the investigation, write down a single affected user, host pool, session host, and local drive. This makes the before-and-after result easier to reproduce than changing multiple users and devices at once.
2. Inspect the host pool's intended drive selection
In the Azure portal, open the relevant host pool's RDP properties, then Device redirection. Review Drive/storage redirection against your organization's intended access. Newly created host pools disable drive redirection by default. Microsoft's configuration guide documents the controls.
The RDP property reference describes drivestoredirect:s:<value>:
- An empty value selects no drives.
*selects all drives, including those connected later.DynamicDrivesselects drives connected later.- Specific drive letters can limit the selection.
These are configuration meanings, not a recommendation to expose all drives. Preserve the approved scope and follow Microsoft's syntax for the configuration surface you use.
3. Check effective policy on the session host
Inspect the applied Intune or Group Policy setting Do not allow drive redirection. Enabled blocks redirection. A permissive host-pool setting cannot override a stricter restriction. Review effective policy, including endpoint restrictions, rather than relying only on a portal setting. See Microsoft's configuration-priority explanation.
If the restriction is intentional, document the user's requirement and ask the policy owner which transfer workflow is approved. A different tool also needs that approval.
4. Apply the approved configuration and retest
Follow Microsoft's configuration and testing instructions, including session-host restarts for policy changes. Check the configured drive in a fresh remote connection. A disconnected local network drive must be reconnected locally, then the remote session reconnected.
Use a harmless file with a distinctive name. In a full desktop, inspect remote File Explorer; for a published app, inspect its file picker. Save to the intended destination, then verify the file in local File Explorer. Record the actual result and the host used.
This test distinguishes a missing drive from an application that cannot select it, a folder permission issue, or confusion about which machine owns a similarly named folder. Those are different problems and need different fixes.
5. Decide whether built-in drive access solves the task
If the user can now select the required drive and complete the approved workflow, keep that working solution. If the requirement is instead to open a remote file in a local Windows application or present familiar local folders inside published apps, evaluate that separately.
TwinPane uses its own connection outside RDP, with Server on the Windows host and Client on the local Windows PC. The video illustrates local folders becoming available in a published application's dialog. It does not demonstrate a change to AVD's RDP policy or establish compatibility with every application.
Read the AVD workflow overview and drive-redirection comparison. An approved pilot should cover one test host, one Windows PC, the actual application, and a harmless file. Confirm the Client/Server connection, destination, and local opening before expanding.
Keep a useful escalation record
Record the client/platform, host pool and host, affected drive, effective restriction, application, expected destination, and observed result. Include whether a fresh connection changed the behavior. Keep credentials and customer files out of screenshots used for support.
For files that exist but landed on the wrong machine, see RemoteApp saves to the server instead of my PC. For the same symptom in Citrix sessions, see Citrix client drive mapping not working. To evaluate TwinPane, start a 30-day trial for up to five devices and review rollout pricing, which starts at 20 paid devices.