BranchCache for VPN File Shares: When It Helps, When It Doesn't

Someone on the team says the file share over the VPN is slow, and the first suggestion is always a cache. Before adding BranchCache to the remote-access design, separate the complaint into one of three shapes: repeated downloads of unchanged content, uploads, or metadata-heavy browsing through folders with thousands of entries. BranchCache addresses the first shape on supported content and does nothing useful for the other two. That is not a limitation to work around; it is the comparison you should run before spending a week on deployment.

The same share, three different complaints

A branch office where eight people open the same unchanged training video is the case the feature was designed for. The first retrieval crosses the WAN, the content is cached near the readers, and later retrievals of the same unchanged file are served locally. The benefit is real and it is narrow: same content, unchanged, multiple readers.

A laptop uploading a new recording through a home connection is the opposite case. There is no previously cached copy of a file that does not exist yet, so the upload follows the same constrained path it always did. A download cache does not remove an upload, and no placement choice changes that.

The third shape is the one that disappoints people because it looks like a download problem. Opening a directory with tens of thousands of files, sorting it, and reading metadata is a stream of small operations, not a repeated transfer of one large object. Caching the file bodies does nothing for the enumeration.

Distributed cache: a VPN pool is not a branch LAN

In distributed mode, client computers share cached content with each other, and Microsoft documents that mode as operating within a single subnet. A VPN client pool is not a subnet in that sense even when all the addresses look contiguous: peer discovery, client-to-client reachability and permission to exchange cache data are separate questions, and the usual remote-access design answers all three with "no".

You can make the pool behave like a branch LAN by allowing client-to-client traffic, but that is a security decision, not a caching one. Most remote-access designs isolate clients from each other precisely so that one compromised laptop cannot reach another, and trading that isolation for a cache hit is a bad exchange unless the peers are already trusted equals.

For a single roaming user, distributed mode has nobody to share with. The cache can still serve that one client's repeated reads, but that is a client-side cache benefit, not a branch placement benefit, and it is worth saying so before anyone expects the office to get faster.

Hosted cache: placement decides whether it helps

A hosted cache puts the shared cache on a server, which is the only mode that makes sense across subnets and the only one that works when clients cannot talk to each other. The immediate question is where that server sits. A hosted cache reached across the same constrained link as the origin has moved the bytes, not the problem.

Place it close to the readers, give it an owner, and size its disk for the working set rather than for the whole share. Microsoft's BranchCache overview describes both modes and the client behaviour, including the part people forget: clients still contact the origin for authorization and content information before using cached data.

Deployment is three roles planned together, not one checkbox. The origin server publishes hashes for the content, the hosted cache is enabled and discoverable, and the clients are configured to use it. On the server side that is recognisable in PowerShell:

Enable-BCHostedServer -RegisterSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode, HostedCacheServerList

On the client, either point it at named servers or let it discover them through the service connection point; then confirm the mode it actually selected rather than assuming the policy applied:

Enable-BCHostedClient -ServerNames cache1.corp.example -UseSCP
Get-BCStatus | Select-Object BranchCacheIsEnabled, ClientMode

What still reaches the origin

Caching does not remove authorization. A client with no permission to read a file does not gain access because someone else cached it, and the origin still answers the authorization question and provides the content information that makes the cache lookup possible. If the origin is unreachable, the cached copy alone does not become an offline share.

Content changes also break the assumption quietly. A file that is re-saved, re-encoded or touched by a backup product may no longer match the cached hash, and the next read goes back to the origin. That is correct behaviour, and it is why a cache whose working set churns every hour delivers little.

Eviction is the third limit. The cache is finite, so a large working set pushes older content out, and the benefit depends on rereads happening before eviction rather than after. Sizing the cache for the whole share is the usual way to be disappointed by a deployment that was technically correct.

Accept it with two retrievals and one upload

Test the right three flows and write down what each one shows. First retrieval of a representative file from a client, measured at the origin link as well as at the user's clock. Second retrieval of the same unchanged file from a second client in the same placement group. One upload of a new file, which should show no improvement and confirms the cache is not being credited for something it never did.

If the second retrieval still crosses the origin link for the bulk of the bytes, the cache is not being used, and the cause is usually a client in the wrong mode, a missing hash publication on the origin, or a hosted cache on the wrong side of the constrained link. Those are three different fixes, and only one of them is about network placement.

Then state the conclusion in the same shape as the original complaint: repeated downloads of unchanged content from this origin to these readers are served by this cache. Everything else about the share is untouched, including uploads, folder enumeration and the offline story, which still needs its own answer.