Windows BranchCache: Hosted and Distributed Cache Design, Publication, and Measurement

BranchCache is a Windows WAN-bandwidth optimization technology. A branch client first obtains content from an approved content source; eligible content can then be cached at the branch so another client can retrieve verified blocks over the local network rather than repeatedly pulling them across the WAN. The mechanism does not turn a branch cache into a writable file server, a general-purpose CDN, a backup copy, or a multi-master replication system. Writes to a source file continue to go to the original content server, and a later request uses content information that validates the source version.

The first design question is not “which command enables BranchCache?” It is “which content server emits BranchCache-compatible content information, which clients are authorized to fetch it, and what cache topology fits this branch?” Microsoft documents content-server support for particular IIS/HTTP(S), BITS-based application, and SMB file-server scenarios. Content fetched directly from arbitrary Internet servers or Windows Update is not automatically cached and shared. For update distribution, a supported WSUS or Configuration Manager content-server design is required; BranchCache is not a universal peer-to-peer Windows Update switch.

BranchCache has two common branch modes. Distributed cache allows clients in a branch to cache content and serve it to peers on the local network. Hosted cache uses a dedicated server in the branch to store content obtained by clients. Hosted cache is operationally easier to inspect and can serve a branch with clients that are not simultaneously present, but it adds a server to size, patch, monitor, and recover. Choose one model per scope based on WAN shape, client population, branch power/network behavior, and service ownership.

Map the content path before enabling a mode

Inventory the source application and protocol, server OS and role service, client OS and edition, Active Directory site topology, branch subnets, firewall path, and the expected cache capacity. Identify which shares or web paths are intentionally BranchCache-enabled and whether source hash publication is configured. Check whether a hosted cache server can be automatically discovered through its Active Directory service connection point (SCP), or whether clients need explicit host configuration. A client can be BranchCache-enabled yet never produce a cache hit if the source server does not publish content hashes or the requested content is not eligible.

Build a content matrix. For every accelerated source, record canonical URL or UNC path, owning team, authentication model, content update frequency, cache security requirements, and a representative file that can be used for testing. The source server authenticates and authorizes clients before they can retrieve content metadata; a local cache does not bypass the original source’s access control. BranchCache uses cryptographic content hashes and a server secret so clients cannot simply invent valid content information for data they were not authorized to access.

Do not confuse content caching with data replication. A BranchCache client cannot authoritatively publish user edits back to a peer cache. If branch users need to write shared files, continue to use the file server’s normal SMB path and permission model. If they need local writable copies that later synchronize, use a product designed for synchronization, such as Work Folders or Offline Files, with a conflict and recovery plan. A cache hit reduces WAN reads; it does not provide write availability when the source is unreachable.

Choose distributed cache or hosted cache deliberately

In distributed mode, client computers share cached blocks with other BranchCache clients in the local branch. This avoids deploying a server but means cache availability follows the participating clients: laptops leave, sleep, run on battery, or disconnect. A file requested by one client may not be available to another if the first client has left or evicted the data. The mode is suitable when peers overlap in time and the organization can accept the resulting cache behavior. Client firewall and local policy must allow the intended peer content traffic within the branch.

In hosted mode, clients retrieve cache data from a designated hosted-cache server. The server stores data obtained through valid client requests, and a domain-joined hosted-cache server can register an SCP so clients in the same AD site discover it. Ensure the site/subnet mapping is accurate; a branch client assigned to the wrong site can discover an unexpected cache server or none. Hosted cache can reduce client churn but creates capacity, maintenance, access, and availability responsibilities for a server.

Neither mode turns BranchCache into a file-system namespace. Do not make a cache server a write target, and do not assume that clearing the local cache removes or repairs source data. Cache eviction is normally a performance event: the next request retrieves the content from the original source again. It is not a data-loss incident unless operators mistake the cache for a backup or authoritative branch replica.

Enable and inspect the client configuration

Use Group Policy for domain-managed fleets when possible so mode, firewall, cache size, hosted-cache discovery, and battery behavior remain consistent. Start with a canary OU and a known compatible content source. The following commands are read-only checks; Get-BCStatus returns a set of status objects, so inspect all fields rather than assuming the first summary line proves the client can find content.

Get-BCStatus | Format-List *
Get-BCClientConfiguration | Format-List *
Get-BCNetworkConfiguration | Format-List *

netsh branchcache show status
netsh branchcache show configuration

For a lab client that should use hosted cache mode, Microsoft documents Enable-BCHostedClient. The following example shows the state-changing operation in preview form where supported; production deployment should be applied through the approved policy path and tested with the actual hosted-cache discovery model:

Enable-BCHostedClient -ServerNames 'HCS-BR01.contoso.example' -WhatIf

If the client is domain-joined and using SCP discovery, do not also hard-code a different hosted server without a design reason. Check the effective policy, site/subnet mapping, and Get-BCStatus output after the policy refresh. Be precise about whether the client is configured for hosted, distributed, local-only, or disabled mode; a cache-size setting is not evidence that the service mode is correct.

Deploy hosted cache with controlled discovery

For a hosted-cache server, install the BranchCache feature and management tools on a supported server in the branch. Confirm its storage capacity, cache location, network reachability, and administrative owner. On a domain-joined server, the documented Enable-BCHostedServer -RegisterSCP command can register the SCP for automatic discovery. Treat SCP registration as a directory write that requires appropriate permissions and correct AD site design. A server that hosts a cache should not be mistaken for the original content source.

Install-WindowsFeature BranchCache -IncludeManagementTools

# Review the proposed operation before enabling the service.
Enable-BCHostedServer -RegisterSCP -WhatIf

# After approval, apply the operation and verify the resulting status.
Get-BCStatus | Format-List *

Install-WindowsFeature installs the Windows Server feature and changes system state; run it only on the intended host and through a reviewed change plan. Enable-BCHostedServer supports -WhatIf, but the preview does not validate DNS, Active Directory site mappings, firewall rules, or client discovery. After approval and application, verify HostedCacheServerIsEnabled and, when applicable, HostedCacheScpRegistrationEnabled in status output. Then test from a client in the intended site and from a client in a different site to ensure the directory scope behaves as expected.

Size the hosted cache based on working-set reuse, rather than total source repository size. Measure WAN bytes before and after, cache growth, storage latency, and hit behavior for representative workloads. If the server fills or evicts frequently, determine whether the working set is too large for the branch, content reuse is low, or the path is not correctly participating. Increasing the cache size without a baseline can consume valuable storage without reducing WAN use.

Configure content-server publication and authorization

Content servers must generate and publish BranchCache content information according to the workload type. File-server scenarios require the appropriate File Services role service and hash-publication policy. Web servers and BITS-based application servers have their own configuration path. Apply hash publication to the intended shares or content paths; publishing for every shared folder can increase scope and operational overhead. Microsoft documents Group Policy settings to allow publication globally, only on shares where BranchCache is enabled, or nowhere.

Hash publication is part of the security boundary. A server secret contributes to generation of content-specific hashes, and content clients still need authorization at the source. Do not export or rotate the secret casually: clients and servers need compatible configuration for the content hashes to remain usable. If you have to migrate the content service or hosted cache, follow the documented key and cache migration process, protect exported key material, and test with content that is not sensitive.

For a read-only audit of content-server settings, use the current BranchCache module and inspect returned objects:

Get-BCContentServerConfiguration | Format-List *
Get-BCStatus | Format-List *

If a hash is missing, verify the supported source type, role service, share configuration, Group Policy result, file eligibility, and publication timing. Microsoft provides Publish-BCFileContent and Publish-BCWebContent for workflows that prehash supported file or web content and can package it for hosted-cache preloading. These operations should be restricted to approved content and tested for package size and transfer method. A cached copy should never be used as evidence that a client could access the source file under the same authorization context.

Measure whether caching actually saves WAN traffic

Use a known large test file that is within the application’s supported policy and accessible to the test user. Clear any application-level cache in the test method, but do not clear all BranchCache data on a production server to make the test “clean.” Capture WAN byte counters and transfer duration for the first client request; then request the same content from a second client in the same branch. For hosted mode, inspect the hosted-cache state; for distributed mode, ensure the first client remains online and eligible to serve. Compare source-server byte counts, client counters, and packet captures.

Test a content update as well as a repeated read. After the source file changes, the server should provide content information that corresponds to the current version. A second client must retrieve and validate the new blocks rather than silently trusting stale bytes. Test a permission change too: a cache must not let a client who has lost access continue obtaining content that the source would deny. Use a controlled test account and confirm that the original server is still the authorization authority.

Define the hit ratio carefully. A BranchCache status counter is not automatically an application-level cache hit metric; determine whether it counts blocks, bytes, requests, or service state for the installed OS version. Measure the expected business outcome as WAN bytes avoided per workload and time saved, and record first-fetch and subsequent-fetch behavior. A high hit ratio for a rarely used test file may be irrelevant to the branch’s actual traffic.

Troubleshoot zero hits, failed discovery, and slow reads

If clients never use the hosted server, verify the service is enabled, SCP registration succeeded, client and hosted server belong to the expected AD site, subnet-to-site mapping is correct, and client policy selects hosted mode. Check DNS, firewall, service state, and connectivity from the exact client subnet. If hosted mode is healthy but a particular file does not cache, investigate the source protocol, hash publication, share configuration, content eligibility, and access control.

If repeated access is slower than the original WAN transfer, inspect the hosted cache disk, CPU, LAN path, and cache lookup overhead. A cache can be less efficient when the branch has few repeated reads or the content changes constantly. Compare request size, WAN latency, LAN latency, source server utilization, and cache storage performance. Disable or narrow a poor-performing policy through a controlled rollback rather than adding more cache infrastructure without evidence.

If content is stale or an authorization concern is suspected, treat it as a security and data-integrity incident. Capture user identity, source path, timestamps, policy, content hash version, and the exact client/cache/server involved. Verify the content directly from the original source and compare it to the client copy. Do not wipe caches, rotate secrets, or reset the service before preserving enough evidence to understand the problem.

For a hosted-cache replacement, restore service configuration and cache data only through a supported path. The cache is derived and can normally be repopulated, so a bare cache backup may not justify the complexity of restoring it. Preserve BranchCache server keys securely if the design requires them, but distinguish key recovery from cache-data recovery. A missing cache should increase WAN reads, not alter the authoritative file contents.

Secure cache and key operations

BranchCache cache contents and metadata are protected by the protocol’s hash and secret model, but administrators should still treat cache servers and key exports as sensitive infrastructure. Restrict local admin access, secure cache storage, patch server and client systems, scope firewall rules to required interfaces and protocols, and protect key backups with strong encryption and access controls. Do not send cache packages or key files over an untrusted channel without encryption and integrity validation.

Cache transfer packages can contain the selected source content. Classify, encrypt, and transfer them according to the sensitivity of that data. Limit prehash/preload jobs to the minimum content needed, keep the package retention short, and verify its checksum after movement. A host that imports a package becomes a content cache; it does not gain a new authorization policy for the source files.

Operational acceptance and rollback

Before rollout, prove the source role and protocol are supported, hash publication is scoped correctly, clients use the intended mode, hosted-server discovery follows the AD site design, cache size fits capacity, and firewalls permit only necessary peer or hosted traffic. Test first read, repeat read, updated content, denied user, disconnected hosted server, and the branch’s expected client departure/sleep behavior. Measure WAN bytes and user-visible duration with a repeatable baseline.

Set rollback thresholds such as no measurable WAN savings, excessive client CPU, unexpected peer traffic, cache growth beyond capacity, incorrect discovery, or content-integrity concern. Preserve policy exports, event logs, source-file checksums, packet captures, and before/after network counters. Disable BranchCache using the approved policy or cmdlet path; do not delete source data or treat Clear-BCCache as a repair for an authorization defect.

BranchCache is valuable when many clients repeatedly read supported content across constrained links. The sound operating model is to preserve the origin server as the authority, publish content hashes deliberately, choose distributed or hosted mode based on branch behavior, verify authorization remains intact, and measure bytes saved with real traffic. That keeps a performance optimization from being mistaken for replication, offline authoring, or backup.

Related:

Sources: