The OneDrive sync cache cost in VDI: the storage multiplier

SOLUTION GUIDE

The OneDrive sync client keeps a local cache of the SharePoint and OneDrive content each user can reach. On a laptop that cost is invisible: the disk was paid for already. In a VDI environment, where user profiles sit on premium server storage such as Azure Files Premium, vSAN or the equivalent, that same cache is duplicated once per user across the whole VDI estate. Multiply a per-user cache footprint by hundreds or thousands of users and the total server-side storage cost of running OneDrive sync in VDI can be several times the SharePoint content itself. This is the piece of the business case that gets left out of most VDI-with-OneDrive designs, and it is where Cloud Drive Mapper's streaming model makes a direct cost difference.

Why VDI changes the sync-cache equation

The OneDrive sync client was designed for a persistent, single-user Windows machine with its own local disk. In that context the cache is free: the machine has spare disk, the user is one person, the duplication is one-to-one with no wider consequences. Everything about the sync client's architecture flows from that assumption.

VDI breaks two of those assumptions simultaneously. First, user profiles do not sit on cheap local disk; they sit inside a profile container (FSLogix, Citrix Profile Management, or the platform equivalent) on premium server storage that is billed per gigabyte. Second, the sync cache is per user, and a VDI estate has many users. The invisible cost on a laptop becomes a visible, multiplied cost on the VDI storage bill.

What the OneDrive cache actually holds

The OneDrive sync client stores several things in each user's profile:

Placeholder metadata for every file the user can reach, whether hydrated or not (file names, sizes, timestamps, folder structure, sync state)
Thumbnails for images, videos and Office documents
Hydrated file content for every file the user has opened (or that Files On-Demand has pre-fetched)
Internal sync database (SQLite) tracking what has been synced, what is pending, what is in error
Search index entries covering the local cache
Working temp files during upload and download operations

Even with Files On-Demand enabled (which is now the default), the per-user footprint is not just placeholders. Every image thumbnail is duplicated per user. Every hydrated file is duplicated per user who has opened it. Every sync-state database is duplicated per user, growing with the number of files each user has visibility of.

Published data-points from the FSLogix community

Real-world VDI deployments have accumulated a decade of guidance on how big to expect OneDrive-inclusive profile containers to be. The consistent published data-points:

Citrix Profile Container default: 50 GB per user (Citrix's provisioned ceiling, industry planning default)
Optimised steady state: around 6 GB per user for a Teams + OneDrive + Outlook container combined
Fresh OneDrive Files On-Demand run before shrink: can bloat to 11 GB per user
After aggressive FSLogix shrink scripts: around 800 MB per user for the OneDrive-only cache portion
Microsoft's general FSLogix Profile Container guidance: plan for under 15 GB per user

A working estimate for VDI capacity planning: the OneDrive cache portion of a well-optimised profile container is about 1% of the total shared content the user can reach in the best case, closer to 3-5% in most steady-state deployments, and can grow into double-digit percentages without careful shrink discipline.

The multiplier arithmetic

Take a mid-size scenario: a firm with 100 VDI users, a 100 GB shared SharePoint library that most users can reach. Everyone runs OneDrive sync with Files On-Demand enabled inside FSLogix containers on premium storage. Plausible per-user cache figures, with the resulting total-estate storage impact:

Scenario	Per-user cache	Total VDI storage cost (100 users)	Multiplier vs SharePoint source
OneDrive sync, aggressively shrunk	~1 GB	100 GB	1× (duplicates the source)
OneDrive sync, tuned steady state	3-5 GB	300-500 GB	3-5× the source
OneDrive sync, unmaintained	~11 GB	1.1 TB	11× the source
Cloud Drive Mapper (streaming)	~0 GB	~0 GB	0× (no per-user duplication)

Scale to 500 users and those numbers become 500 GB, 1.5-2.5 TB, 5.5 TB, or ~0 GB respectively. At 1,000 users the multiplied cost of the unmaintained case reaches 11 TB of premium VDI storage to serve 100 GB of SharePoint content. The same 100 GB served by CDM to 1,000 users still takes essentially no server-side storage.

Where the money actually leaks

The cost of the multiplier is not the SharePoint storage; SharePoint content is included in Microsoft 365 licensing. The cost is the VDI-side profile storage, which is priced per gigabyte on the premium tiers VDI depends on for acceptable performance:

Azure Files Premium (typical AVD user profile storage) is priced per provisioned gigabyte per month, at a materially higher rate than Azure Blob or SharePoint storage
vSAN or all-flash SAN storage backing Citrix / Horizon profile shares carries the enterprise premium-storage cost per gigabyte per month
Cloud-hosted Citrix DaaS and Horizon-on-VMware-Cloud arrangements have per-gigabyte storage line items in their pricing

Every gigabyte of duplicated OneDrive cache lives on that tier. The multiplier applies to the highest-cost storage tier in the estate.

Why Cloud Drive Mapper does not incur the multiplier

CDM presents SharePoint document libraries as mapped drive letters and streams file content on demand from Microsoft 365. There is no persistent per-user cache to accumulate, no per-user metadata database sitting inside a profile container, no per-user thumbnail duplication. When a user opens a file, CDM streams the content for that file to the session. When the user closes the file, the content is released.

The total server-side storage cost of running CDM across the whole VDI estate is essentially zero, regardless of whether the estate has 100 users, 500 users or 5,000 users. SharePoint content sits once in SharePoint. There is no duplication into VDI storage.

When the multiplier matters most

Not every environment feels the OneDrive cache cost the same way. The multiplier is largest where:

The VDI estate is large. Cost scales linearly with user count; small estates see a small multiplier bill
Shared SharePoint content is large and broadly accessible. The multiplier compounds when many users can reach the same big libraries
Profile storage is premium tier. Azure Files Premium, vSAN, all-flash SAN. Standard tiers make the multiplier cheaper but slower
OneDrive is not actively pruned. Storage Sense, shrink scripts and disciplined selective sync all reduce the multiplier; environments without them accumulate
User turnover is high. New users start empty and grow; churn does not release the accumulated cache

For a 20-user practice with a 10 GB SharePoint site the multiplier is a rounding error. For a 2,000-user enterprise with a 500 GB SharePoint estate on Azure Files Premium, the multiplier is a serious line on the infrastructure bill that most business cases never surface.

Making the case in your VDI business plan

When costing a VDI deployment that will serve SharePoint content to users, work the multiplier into the storage line-item:

Estimate the average per-user OneDrive cache size for your environment (default to 3-5 GB unless you have data)
Multiply by user count to get total VDI-side storage overhead attributable to OneDrive sync
Price that at the per-gigabyte rate of your profile-storage tier
Compare against the CDM alternative: same functionality with essentially zero additional VDI-side storage requirement
The difference is the storage cost of running OneDrive sync in VDI, over and above whatever you were going to spend on VDI anyway

Cloud Drive Mapper eliminates the OneDrive sync cache multiplier in VDI. SharePoint content sits once in SharePoint, reachable by every user at zero additional server-side storage cost.

Start a 30-day free trial How Cloud Drive Mapper works →

Frequently asked questions

Why is the OneDrive sync cache a bigger issue in VDI than on a laptop?

On a laptop, the OneDrive cache sits on a disk the business already paid for. In VDI it lives inside the user's profile container (FSLogix, Citrix Profile Container or equivalent), which sits on premium server storage that gets billed per gigabyte. The cache is duplicated once per user in the estate. On a laptop that duplication is invisible; in VDI it is a real line item, and it multiplies with headcount.

How much cache does each VDI user actually accumulate?

Published FSLogix guidance and community deployment notes point at a range: about 800 MB per user in the best case after aggressive shrink scripts, around 3-5 GB per user in most steady-state deployments, and 11 GB or more per user in unmaintained environments where OneDrive has hydrated a lot of the user's accessible content. Citrix's default Profile Container VHDX is provisioned at 50 GB per user, which sets the industry's planning ceiling even where actual use is lower.

Does Files On-Demand solve this?

It reduces the per-user cache from the full content size to something proportional to metadata plus what the user has hydrated. It does not eliminate the per-user duplication. Every user still has their own metadata store, their own thumbnail cache, and their own set of hydrated files. Multiply across the estate and the total server-side storage cost remains a multiple of the SharePoint source content, even with Files On-Demand enabled.

What is the actual multiplier we should plan for?

As a working estimate, a well-optimised deployment where each user's OneDrive cache is around 1% of the shared content they can reach still costs 1 GB of VDI storage per user for every 100 GB of accessible SharePoint content. Across 100 users that is 100 GB of VDI storage duplicated for the same 100 GB of SharePoint source. Realistic 3-5% cache footprints (which most tuned FSLogix guides plan for) mean the total server-side cost is 3-5 times the SharePoint source content. Unmaintained estates go higher.

How does Cloud Drive Mapper compare?

CDM does not maintain a persistent local cache of files. Each user session mounts SharePoint content as a mapped drive and streams file content on demand from Microsoft 365 rather than syncing a local mirror. Total server-side storage for CDM across the whole VDI estate is essentially zero (small session-level working memory only). The same 100 GB of SharePoint content serves 100 users, or 1,000 users, without duplicating a byte into VDI storage.

Sources for the cache-size data-points

Model the cost against your own VDI estate

The fastest way to see the storage difference is to try CDM for 30 days on a subset of the VDI estate and compare the profile-container growth against the OneDrive-sync equivalent.

Start a free trial Request a demo