OneDrive in Omnissa Horizon: why it struggles, and how to fix it

OneDrive for Business is a poor fit for Omnissa Horizon environments (formerly VMware Horizon) by architectural design. The OneDrive sync client assumes a persistent, single-user Windows machine; a Horizon Instant Clone desktop is created on demand from a base image and destroyed when the user logs off. Even Full Clone deployments hit the same fundamental issues on shared session hosts. App Volumes writable volumes and Dynamic Environment Manager handle parts of the story, but the OneDrive sync client remains a source of friction that Horizon-side tuning cannot fully close. 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 Horizon?

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. Horizon Instant Clones are the opposite of that assumption. An Instant Clone desktop is created from a golden image at logon, lives only for the length of the session, and is destroyed afterwards. There is no persistence for the sync client to write against. Full Clone desktops are persistent but often session-shared across a user population.

The symptoms Horizon operators report most often: sync loops on login, ballooning writable-volume 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.

What do App Volumes, DEM (and FSLogix) solve, and what do they not?

Horizon operators have three broad options for persisting the OneDrive cache across sessions:

• App Volumes writable volumes. Attach a per-user VMDK to each Horizon session, redirecting the OneDrive cache into it so state survives Instant Clone destruction. Similar in concept to an FSLogix container.
• Dynamic Environment Manager (DEM), formerly VMware UEM. Manages user-profile settings and can persist some OneDrive configuration; less well-suited to persisting the sync cache itself.
• FSLogix. Yes, Microsoft's FSLogix works in Horizon too. Many Horizon shops run FSLogix profile containers for the OneDrive cache use case rather than using App Volumes writable volumes for it, on the basis that FSLogix is Microsoft's canonical answer to the OneDrive-in-VDI problem.

Whichever of the three approaches a Horizon operator picks, five specific problems remain in the deployment:

Cache growth over time on vSAN or profile-share storage

Even with Files On-Demand enabled, the sync client still catalogues everything the user is subscribed to, and container or writable-volume sizes climb month over month. What was a minor overhead on day one becomes a real vSAN or NFS/SMB profile-share 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.

Instant Clone sessions amplify sign-in friction

When a user connects to a Horizon Instant Clone pool, the desktop is spun up from the golden image, the writable volume or FSLogix container is mounted, and the OneDrive client starts. Under load, mount timing produces sign-in delays and occasional failures where the user has to try the connection again. Adding OneDrive-cache persistence to the mount chain is a compounding source of latency.

Cross-host cache inconsistency in load-balanced pools

Horizon pools distribute users across multiple hosts. When a user's next session lands on a different host with a differently-timed sync state, OneDrive can spend the first minutes of the session catching up or reporting conflicts. Users learn to blame "the desktop" without ever getting a clear cause.

Uncontrolled OneDrive client updates against a locked-down image

The OneDrive sync client auto-updates, which conflicts with the Horizon golden-image discipline that most operators maintain. Updates arrive out of band from the image pipeline; occasionally an update reshapes behaviour in ways that require immediate response from the Horizon team.

No mapped drive letters for desktop applications

Many desktop applications common in Horizon 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 a Horizon answer.

These are not bugs to be fixed in a future release. They are permanent conceptual features of the sync-client-plus-persistence-layer design, regardless of whether the persistence layer is App Volumes, FSLogix or DEM.

How does Cloud Drive Mapper solve OneDrive in Horizon?

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 a Horizon context this dissolves the whole class of sync-client problems: no writable-volume growth, no cross-host reconciliation, no image-pipeline conflict with auto-updates, and applications that need drive letters get them.

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

• Omnissa Horizon (on-premises, both Instant Clone and Full Clone)
• Horizon Cloud on Azure
• Horizon Cloud on AWS
• VMware Cloud on AWS-hosted Horizon estates
• Horizon Apps (published applications)

Because CDM does not maintain a persistent local cache, the local storage footprint inside each Horizon session is a fraction of what an OneDrive sync client plus writable volume or FSLogix container requires, and there is no growth curve over time. That matters most in Instant Clone pools where the writable-volume tier is priced per gigabyte on the vSAN or NFS/SMB profile share, and where the cumulative footprint of a growing sync cache multiplied by concurrent users adds up quickly.

Cloud Drive Mapper is used across Omnissa Horizon 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 Omnissa Horizon?

The OneDrive sync client is designed around a persistent, single-user Windows machine that maintains a local mirror of the user's cloud files. Horizon Instant Clone desktops are created on demand from a base image and destroyed when the user logs off; Full Clones are persistent but often session-shared. Neither matches the sync client's operating assumptions. Horizon operators experience sync loops, ballooning writable-volume sizes, sign-in failures on shared session hosts, and general OneDrive unreliability that no amount of Horizon-side tuning fully resolves.

Do App Volumes and Dynamic Environment Manager solve OneDrive in Horizon?

Partially. App Volumes writable volumes can persist the OneDrive cache across Instant Clone sessions in the same way FSLogix containers do in Citrix or AVD. Dynamic Environment Manager (formerly VMware UEM) handles user-profile settings and can smooth some of the sign-in state. Neither eliminates the fundamental issues: cache growth over time, cross-host inconsistency, uncontrolled OneDrive auto-updates, and applications that need real drive letters. Many Horizon shops actually run FSLogix instead of App Volumes for the OneDrive-cache use case; both approaches face the same underlying constraints.

Does Cloud Drive Mapper work in Omnissa Horizon?

Yes. Cloud Drive Mapper is compatible with Omnissa Horizon (both on-premises deployments and Horizon Cloud on Azure / AWS), and with VMware Cloud on AWS-hosted Horizon estates. It runs on any Windows Server 2016+ infrastructure inside the Horizon-delivered desktop and integrates with the Microsoft 365 tenant natively, using delegated permissions.

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

Yes. That is one of the core reasons CDM exists in Horizon 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, tax-preparation tools) work as they always have. Horizon delivers the desktop; CDM makes the M365 storage inside it look like a network share.

Do we need App Volumes or FSLogix if we deploy Cloud Drive Mapper in Horizon?

Not for the OneDrive use case. Cloud Drive Mapper does not use the OneDrive sync client, so the persistence problem that App Volumes writable volumes or FSLogix containers are closing does not exist under CDM. Most Horizon operators continue running one of them for wider profile-management reasons (Windows profile state, Office cache, application settings) and CDM is compatible with both. The writable volume just gets smaller because there is no OneDrive cache filling it up.

How much vSAN or profile-share storage does Cloud Drive Mapper use inside a Horizon session?

A fraction of what an OneDrive sync client plus writable volume or 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 vSAN, VMFS or the NFS/SMB share hosting user profiles. See The OneDrive sync cache cost in VDI for the storage-multiplier arithmetic across a full estate.

Related solutions

• OneDrive for Business in Citrix (same pattern on Citrix)
• OneDrive for Business in Azure Virtual Desktop
• 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