OneDrive in Azure Virtual Desktop: why it struggles, and how to fix it

OneDrive for Business is a poor fit for Azure Virtual Desktop environments by architectural design. The OneDrive sync client assumes a persistent, single-user Windows machine; an AVD session host is often neither, especially in pooled multi-session configurations. Microsoft's own FSLogix (the reason Microsoft bought the company) partially closes the gap by pushing the sync-client state into per-user containers on Azure Files. But five specific problems remain, and each one costs real money in Azure Files Premium storage. Cloud Drive Mapper avoids the whole class of issue by not being a sync client at all: it presents SharePoint, OneDrive and Teams as virtual network drives, streaming content on demand.

Why doesn't the OneDrive sync client work well in AVD?

The OneDrive sync client is built around one core assumption: it is running on a persistent Windows machine used by a single user, keeping a full local mirror of that user's cloud files in sync over time. Every design decision in the client flows from that assumption. AVD session hosts are typically pooled multi-session (many users on one host at once) or personal but non-persistent (single-user but rebuilt from an image on assignment). Neither configuration matches the sync client's operating assumptions.

The symptoms AVD operators report most often: sync loops on login, ballooning FSLogix container sizes, files that appear locally but never propagate to the tenant, files that appear in the tenant but never propagate locally, sign-in failures on shared session hosts, and the general feeling that OneDrive is "there but not really working". None of these are bugs in the classical sense; they are the sync client operating outside its design envelope.

Microsoft acknowledged the problem years ago. Rather than rewrite the sync client from scratch, Microsoft acquired a company called FSLogix that had built a workable workaround, and made FSLogix a free component of the AVD licensing stack.

What does FSLogix solve in AVD, and what does it not?

FSLogix works by redirecting the OneDrive cache into a per-user container (typically a VHDX file on Azure Files Premium, Azure NetApp Files or an equivalent share) that mounts into whichever AVD session host the user lands in. The container persists across sessions, so the sync client wakes up in each new session with the state it had at the end of the last one. Configured carefully, this reduces the most visible sync loops and lets OneDrive present a more stable user experience across pooled hosts.

Configured carefully being the operative phrase. FSLogix is partial cover, not a fix, and five specific problems remain in an AVD deployment:

Sync overhead grows over time (on Azure Files Premium)

Even with Files On-Demand enabled, the sync client still catalogues everything the user is subscribed to, and container sizes climb month over month. What was a minor overhead on day one becomes a real Azure Files Premium cost by day 365, especially when multiplied across the whole user base. See our companion piece The OneDrive sync cache cost in VDI for the multiplier arithmetic across a full estate.

Pooled multi-session hosts amplify container-mount friction

When multiple users share a pooled session host, FSLogix mounts their containers simultaneously as they sign in. Container-mount timing under load produces sign-in delays, occasional mount failures that require the user to try again, and a general sensitivity to Azure Files performance tier that is difficult to plan around.

FSLogix has no clear roadmap

Microsoft acquired FSLogix to close a specific gap. The software receives security updates and stability fixes, but there is no signal that Microsoft is investing in significant new functionality. It exists, it works, and it stays where it is. AVD operators live with that reality.

Uncontrolled OneDrive client updates

The OneDrive sync client auto-updates on the AVD host, which is convenient for consumer scenarios and awkward for enterprise AVD operators with tight change-control processes on their image pipelines. Occasionally an update reshapes behaviour in ways that require immediate response from the AVD team.

No mapped drive letters for desktop applications

Many desktop applications, particularly the line-of-business software common in AVD estates (CAD tools, accounting software, document management systems, healthcare EMR clients, tax-preparation tools), require a real Windows drive letter to save data. The smart-sync folders the OneDrive client creates are not addressable by drive letter, so these applications cannot see the content that lives in them. This is the largest single reason organisations end up looking beyond the sync client for an AVD answer.

These are not bugs to be fixed in a future release. They are permanent conceptual features of the FSLogix + OneDrive design.

How does Cloud Drive Mapper solve OneDrive in AVD?

Cloud Drive Mapper is not a sync client. It presents SharePoint, OneDrive and Teams as virtual network drives with real Windows drive letters, talking directly to Microsoft Graph and streaming file content on demand rather than mirroring it locally. In an AVD context this dissolves the whole class of sync-client problems: no container overhead, no cross-host reconciliation, no auto-update surprises, and applications that need drive letters get them. The Azure Files Premium storage cost that OneDrive sync accumulates in a mature AVD deployment simply does not exist under CDM.

CDM runs on any Windows Server 2016+ infrastructure and is compatible with the full Microsoft VDI range:

• Azure Virtual Desktop (AVD): pooled multi-session
• Azure Virtual Desktop: personal desktops
• AVD RemoteApp streaming
• Windows 365 Cloud PC
• Azure Stack HCI-hosted AVD

Because CDM does not maintain a persistent local cache, the local storage footprint inside each AVD session is a fraction of what a OneDrive-plus-FSLogix arrangement requires, and there is no growth curve over time. That matters most on pooled multi-session hosts and non-persistent desktops, where the cumulative footprint of a growing sync cache multiplied by concurrent users adds up quickly on the Azure Files bill.

Cloud Drive Mapper is used across hundreds of Azure Virtual Desktop customers to integrate with their Microsoft 365 storage without the OneDrive sync client's operational and cost overhead.

Frequently asked questions

Why doesn't the OneDrive sync client work well in Azure Virtual Desktop?

The OneDrive sync client is designed around a persistent, single-user Windows machine that maintains a local mirror of the user's cloud files. An AVD session host in a pooled multi-session configuration is neither persistent nor single-user; a personal-desktop AVD host is single-user but often non-persistent (rebuilt from an image on assignment). The sync client's fundamental assumptions do not hold, which is why AVD operators experience sync loops, ballooning FSLogix containers, sign-in failures on shared session hosts and the general feeling that OneDrive is only partially working.

Does FSLogix solve OneDrive in AVD?

Partially, and this is Microsoft's own design. Microsoft acquired FSLogix specifically to close the gap between the OneDrive sync client's assumptions and the reality of AVD hosts. FSLogix redirects the sync cache into a per-user container (typically a VHDX on Azure Files Premium) that mounts into whichever session the user lands in. Configured carefully, this reduces the most visible sync loops. But it does not eliminate them, it costs money on the Azure Files bill, and it does not remove the underlying problems around container growth, multi-host reconciliation and applications that need real drive letters.

Does Cloud Drive Mapper work in Azure Virtual Desktop and Windows 365 Cloud PC?

Yes. Cloud Drive Mapper is compatible with AVD (pooled and personal), Windows 365 Cloud PC, and general Windows Server 2016+ infrastructure. IAM Cloud has hundreds of Azure Virtual Desktop customers using CDM to integrate with their Microsoft 365 storage. CDM works with Microsoft's Azure identity and delegated-permissions model natively.

Can Cloud Drive Mapper give AVD users mapped drive letters for their applications?

Yes. That is one of the core reasons CDM exists in AVD environments. It presents SharePoint, OneDrive and Teams content as virtual network drives with real file paths, so legacy desktop applications that expect a Windows filesystem (CAD tools, accounting software, document management systems, healthcare EMR clients) work as they always have. AVD's own smart-sync integration and the RemoteApp streaming Microsoft has been shipping do not solve this specific problem.

Do we need FSLogix if we deploy Cloud Drive Mapper in AVD?

Not for the OneDrive use case. Cloud Drive Mapper does not use the OneDrive sync client, so the sync-container problem FSLogix is closing does not exist under CDM. Most AVD operators continue running FSLogix for wider profile-management reasons (Office Container, Profile Container for Windows profile state, Outlook cache) and CDM is compatible with that. The FSLogix container just gets smaller because there is no OneDrive cache filling it up.

How much Azure Files Premium storage does Cloud Drive Mapper use inside an AVD session?

A fraction of what an OneDrive sync client plus FSLogix container consumes. Cloud Drive Mapper does not mirror content locally; it streams file content on demand and releases it after close. That makes it significantly lighter on Azure Files Premium (the tier most AVD user profiles sit on), which is priced per gigabyte per month at a materially higher rate than SharePoint's own storage. See The OneDrive sync cache cost in VDI for the arithmetic across a full estate.

Related solutions

• OneDrive for Business in Citrix (same pattern on Citrix)
• OneDrive for Business in Omnissa Horizon
• The OneDrive sync cache cost in VDI (the storage-multiplier arithmetic)
• Copilot readiness in VDI environments
• Overcoming the OneDrive 300,000 file sync limit
• Desktop applications and real file paths

← Back to all solutions