Azure Files Metadata Caching vs a Local Branch Cache
A service-side metadata cache trims server work. It does not move round trips off your WAN. Compare the two by what they actually shorten.
Two changes get proposed for slow Azure Files access over a VPN, and they shorten different things. Service-side metadata caching makes eligible operations cheaper for the server. A local branch cache moves the bytes and the operations closer to the user. Choosing between them by price list or press release is how a share ends up faster in a benchmark and unchanged at nine in the morning.
Two caches, two different latencies
Both options appear under the word caching, which is where the confusion starts. They sit on opposite sides of the network.
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Microsoft's SMB performance guidance describes metadata caching for eligible SSD shares together with the registration step that goes with it. Eligibility and feature state belong to the actual storage account, so read the current page rather than a preview announcement from two years ago.
Split the wait into three parts
Every slow directory listing has three cost components, and they respond to different fixes. There is service processing time per request, the number of dependent round trips across the VPN, and the payload that has to move. A service-side cache attacks the first. Nothing on the server side attacks the second.
That is why a share can show better service metrics while the user's file picker still hangs for eight seconds.
Where each option earns its place
If the workload is metadata-heavy, with plenty of opens, stat calls and directory enumerations against an eligible SSD share, service-side caching is the cheap experiment. It needs no new infrastructure and no change to how users reach the share.
If the workload is interactive and latency-bound, a supported local-server design with a documented synchronisation model is the honest option. That is a different architecture with its own running costs, not a switch.
What neither option changes
SMB signing and encryption still apply, and they still cost what they cost. Access control still resolves per user, so a cached copy does not simplify authorisation. Consistency between sites still needs a defined model, because branch-local reads and cloud-side writes have to agree about something. And offline access stays a client setting, not a side effect of a server feature.
When someone promises that a service feature removes the WAN round trips, that is the claim to test first.
Measure against the operation users complain about
Time the exact operation rather than a synthetic copy. Measure-Command { Get-ChildItem \\files\projects -Recurse } on a branch client gives a number you can compare before and after, and Get-SmbMultichannelConnection shows whether the client is using more than one path. Put that beside the service-side latency metrics for the same window.
Keep the share, the client location, the VPN path and the security policy constant, or you are measuring your change window instead of the feature. Record file count and size distribution too, because small-file workloads and bulk copies respond to completely different levers.
The result worth having is a change matched to the boundary that was actually slow, with its operating and consistency costs written down. A bigger storage IOPS figure on a slide is not that result.