2Pint BranchCache Administrator Guide
Introduction
The aim of this document is to assist Administrators in understanding and implementing Microsoft BranchCache and associated technologies in order to maximize the benefits of this often overlooked Windows Service.
This document focusses on Distributed Mode BranchCache over HTTP. This is the most commonly used mode of operation when BranchCache is used for Content Distribution via Microsoft ConfigMgr/WSUS etc.
So what is BranchCache? Here’s a nice description from the Microsoft Protocol docs on the subject:
“The goal of the Content Caching and Retrieval System is to decrease WAN network use. This is accomplished by caching content that has been retrieved over a WAN link (or any high latency link) from a content server by a set of actors (computers, applications, or people) connected to a local area network (LAN) and making it available for subsequent use within the LAN environment in a secure and effective manner. The overall effect is to reduce WAN traffic and therefore increase application performance.”
In other words, it’s WAN accelerator, which caches content locally to avoid unnecessary round trips to the data source by allowing clients on the same subnet to retrieve content from peer systems. **IT DOES NOT DOWNLOAD STUFF**
Or:
“It makes your network go faster”
High Level Concepts
BranchCache Distributed Cache Mode
“In Distributed Cache mode, BranchCache-enabled Windows clients cache copies of files downloaded from content servers (such as Configuration Manager Distribution Points) and make them available to other clients (peers) when requested. Distributed Cache mode is especially beneficial for locations that do not have a local server, but works equally well in large subnets with well-connected WAN links.”
Pros
Requires no local BranchCache server
Reduces the load on existing content servers by using P2P to share content
Integrates with Windows Server Deduplication to save even more WAN bandwidth
Easily configured and managed via Group Policy and/or ConfigMgr
Cons
Limited to a single subnet. So if, for instance you have separate subnets for wired vs wireless clients you will effectively have 2 distributed caches and content may well be copied twice to that location.
High mobility can mean that content can ‘go missing’ if a user has cached content (to a laptop for instance) and then relocates.
Initially requires two copies of content to be stored – one in the content download location and one in the BranchCache cache. (the content can be deleted and still be retrieved from the BranchCache cache)
Basic Operation
PC1 performs a ‘Get’ Request – but downloads the Identifiers (hash) that describe the content.
PC1 performs a local broadcast to see if anyone else has this content. If they do, PC1 will get it locally from peers. If the content is NOT local, PC1 will go back to the server and get the content. Once downloaded, the content is then available to peers on that subnet.
PC2 performs a ‘Get’ Request – but downloads the Identifiers (hash) that describe the content.
PC2 performs a local broadcast to see if anyone else has this content.
PC1 has the content, so PC2 will transfer it locally from PC1.
BranchCache Theory
“Buckle up – there aren’t many screen shots.”
This section can be a bit ‘dry’, but it’s worth sticking with the clever theory behind BranchCache as it helps you to understand where the heck your data went when you get to play with it.
BranchCache Versions
The first, and one of the most important items to consider and understand before you implement BranchCache is the two different versions. They behave differently, don’t necessarily play well together, and are an important factor in any BranchCache implementation.
At the time of writing, BranchCache is available on Windows Server 2008 R2 / Windows 7 Clients and later
- We’ll refer to this as Version 1 BranchCache
It’s also available on Windows Server 2012/2016 versions, and Windows 8/10/11 clients.
- We’ll refer to this as Version 2 BranchCache
BranchCache ‘Content’ Explained
“BranchCache Does Not Care About Files!”
The BranchCache Content Server is responsible for slicing up content into chunks. It’s these chunks that are requested and downloaded by BC clients, not files. It works slightly differently (and more efficiently) in Version 2 than Version 1.
The Hash (or Content Identifier)
“No Hash = No Content!”
The BranchCache Content Server generates Hashes for content that is requested by clients. This hash, or Content Identifier is then used to locate content from other peer systems.
Important
BranchCache Content Server will only generate the Hashes for content at the time of the request. It’s fairly fast at doing this, but on a very busy server, with many content requests per second, a ‘Hash Generation ‘queue may form. This can mean that a client system which requests content will not be able to utilize BranchCache as the hash is not available yet, and the client will simply download the content and cannot place it into the BranchCache cache or locate the content on peer systems. Hashes can be pre-generated to mitigate this, and this is explained in a later section.
You don’t really need to know this but.. here’s what a BranchCache Hash consists of:
Server Secret – Shhh. Used as a key in order to create a content-specific hash that is sent to clients.
Hash of Data (Hod)– the juice, the magic, the stuff dreams are made of. It’s what BranchCache uses to make sense of the files it needs to download.
Segment Secret – Used as the encryption key to generate the Segment ID (along with the HoD)
Segment ID – Used to locate the content once the Hash is downloaded
Segments and Blocks
BranchCache’s currency is Segments. You can think of a segment as a ‘Unit of Discovery’. That is to say, it’s what the BranchCache client asks for when it’s on the hunt for requested data once it has the Hash for that content.
In V1 - within that segment there are Blocks, which are the ‘Unit of Download’. So these are the individual chunks of data that are downloaded once the segment is found. Chopping things up like this means that the network isn’t clogged by these 32Mb segments flying around in one lump.
In V2 however it changes quite significantly. Read on.
Windows 7/WS2008R2 (Version 1.0)
Content is divided into Segments, which is further divided into Blocks. A Segment is a Binary string of 32Mb - and the last segment of a file can of course be less than 32Mb unless the content divides into exact 32Mb chunks. The Block Size for Version 1.0 is 64k –again the last block can be smaller for obvious reasons. The important thing to remember here is that if a file has a change at the beginning of the file, with V1.0 content, you would invalidate the entire segment because all of the block sizes are fixed and would therefore change. So a change in a file results in at least a 32Mb download (in files bigger than 32Mb of course!)
Windows 8.x/WS2012 (Version 2.0)
V2.0 does away with these fixes size blocks, because the segment ‘chunking’ algorithms used result in variable block sizes of 32-128k. So we really don’t have the same distinction of Segment and Blocks. V2.0 uses Deduplication algorithms – to determine those block sizes.
So in a file change scenario with V2 and its use of variable block sizes, it’s more likely that the blocks later in the file will still be the same, and only those blocks that have changed need to be downloaded.
V2 also uses the Deduplication technology introduced in WS2012/16 but this will be covered later in this document, as it’s freaking awesome. Basically duplicate blocks of data are not downloaded by V2 BranchCache which makes for massive savings across files with identical data blocks such as WIM files or Documents etc.
The BranchCache Caches
“Where’s My Cheese?”
The BranchCache Cache is a database of content, and/or hashes of content. Simple.
BranchCache Maintains two caches, both on the Content Server and Client. It’s important to learn to distinguish between the two. By default, these are located at:
%WINDIR%\ ServiceProfiles\NetworkService\AppData\Local
The Publication Cache – \PeerDistPub folder
The is the HashCache – where generated hashes are stored.*
Content Server – the Hash Cache is populated is content requests come in to the server.
Client System – the Hash Cache is usually empty, unless content is injected (imported).
*If Windows Server Deduplication is enabled, the BranchCache HashCache can be empty, as BranchCache (V2) is designed to utilize the Deduplication Chunk Store.
The Republication Cache – \PeerDistRepub folder
This is the DataCache – where content is stored (and hashes that were downloaded by the client – but mostly content)
Content Server – Usually empty (unless the content server itself is a client), as the content server only needs to generate the Hashes of the data. The Content is already stored (as files).
Client System - The data cache will be populated with downloaded BranchCache content.
Security
Here is a typical BranchCache operation from a security viewpoint.
Server authenticates the client and performs authorization checks.
Server transmits content information structure to the client only if the client has access. Transfer happens over the accelerated protocol –HTTP/S etc.
Client uses content information structure to calculate:
-segment id (public)
-encryption key (private)
Client multicasts the segment id to find a peer with the data.
Client downloads encrypted blocks from a peer and decrypts them with the encryption key
Cached data is stored in encrypted form in the BranchCache Cache
The above is Out-Of-The-Box behaviour. No further security configuration is required.
Note: Data in the Cache is not encrypted on Windows 7 but is on Windows 8 and above. But on even if it’s not encrypted on Windows 7 you cannot browse this info and need a high privilege account to access it. Data transferred over the wire is encrypted. Data in the Cache is not stored by file but by hash. So even if you know the name of the file you can’t get the data. In order to get to the data, you need to be admin and have the hash which is protected by the login to the IIS server.
BranchCache Configuration
Cache Management
The simple rule for cache management is that on Content Servers you need to configure the HashCache, and on Clients it’s the DataCache. So here’s what you can configure with regards to the cache.
Location (V1/V2)
You don’t have to accept the defaults for BranchCache cache location – you can move it to another drive for instance.
Size (V1/V2)
Size does of course matter in the BranchCache world.
Default 5% of disk space for the Data Cache, and 1% for the Hash Cache – on both Content Servers and Clients.
TIP: For servers , you can calculate the size of the Hash Cache that you might need. Hashes are around 1/2000th the size of the original content, so if you know the total content that the server will be providing you can set the cache size accordingly. In a mixed (V1/V2) client environment – bear in mind that you will need double the space as V1 and V2 hashes are different.
Segment Age (V2 Only)
This applies to the data cache only, and specifies the default age in days for which segments are valid. The default is 28 days and you can increase this to 9999 if you so wish.
BranchCache Cache in Windows 10
Windows 10 clients can now benefit from dynamic cache resizing. This means that you can set a large Data Cache size – safe in the knowledge that the Cache will dynamically shrink if the system experiences a Low Disk Space event. Segments in the cache will be removed based on the ‘last accessed’ date, so that content that is frequently used will be left alone, while the older segments will be removed first..
Configuring the Cache Size
V1/2 – Using Netsh.exe
Specifies the size of the local cache as either a percentage of the size of the hard disk where the cache is located or as an exact number of bytes.
Syntax:
For the DataCache:
For the HashCache:
V2 – Using PowerShell
Use Get-BCStatus to see the current Cache locations and sizes:
To configure the HashCache with PowerShell, you need to get the WMI instance, and feed it to the set-bccache cmdlet. See below:
To do the same for the DataCache:
Changing the Cache Locations
In some cases you may want to change those default Cache locations – easy peasy:
V1/2
Remember that the default location is - %WINDIR%\ServiceProfiles\NetworkService\AppData\Local\PeerDistRepub
And the HashCache?
Remember that the default location is - %WINDIR%\ServiceProfiles\NetworkService\AppData\Local\PeerDistpub
V2
In PowerShell it’s a case of supplying the old and new cache locations
To change the DataCache location:
To change the HashCache location:
Setting the DataCache Segment Age
Only available in V2 – in V1 it is set to a default of 28 days. This applies to the data cache only, and specifies the default age in days for which segments are valid. The default is 28 days and you can increase this to 9999 if you so wish.
PowerShell – pretty simple
Pre-Generating Hashes
V2 Only (2Pint Software Free Tools can be used for V1)
To ensure that BranchCache Hashes are always available to clients (remember, No Hash = No Data), you can use the BranchCache PowerShell cmdlets to pre-generate hashes on the BranchCache Content Server.
Note: If using Data Deduplication in Windows Server 2012/16, the Deduplication service will create the hashes for you. So this configuration will not be required.
To generate hashes on a content server, in this case a Microsoft Configuration Manager Distribution Point:
The -Recurse switch forces hash generation for content within folders and subfolders under the root folder in the command.
Tip: If you are frequently adding content you may want to run this command daily as a scheduled task.
Optimizing BranchCache in a Mixed Client Environment
Sometimes you may have V1 and V2 clients within the same subnets. This can be complicated but the rules are as follows.
If you do nothing, the worst that can happen is that you will have two downloads of the same content per subnet. One will be shared by V1 clients and one by V2 clients.
V1 and V2 clients cannot ‘peer’, because the BranchCache Hash and Databases are different
V2 Clients Can however, download V1 hashes. This is called ‘downgrading’ and means that you will only need one download per subnet but you will not be able to take advantage of Deduplication.
Enabling BranchCache Version Support
Using Policy
Set the ‘Configure Client BranchCache Version Support’ policy for clients of Windows 8 and above. Set it to ‘Windows Vista with BITS 4.0 installed, Windows 7, or Windows Server 2008 R2.’ The Windows 8/10 clients will then only download V1 hashes.
Using PowerShell
Enable-BCDowngrading This will set the client into V1 mode.
Disable-BCDowngrading Will reset things back to V2
Enable BranchCache on Client Systems
To enable BranchCache to function on a Windows System, the following items must be configured.
The BranchCache Service must be configured for the correct mode (Distributed Mode for the purposes of this document)
The Windows Firewall must be configured to allow BranchCache Peer Content Retrieval and Discovery.
There are quite a few ways to enable BranchCache in Distributed Mode on clients systems. The most common are described below.
Using Microsoft Configuration Manager Client Settings
From Configuration Manager you can configure some BranchCache settings from within the Client Settings node in the Configuration Manager Console. This configures local policy, and enables BranchCache in distributed mode. You can also configure the data cache size this way, but not the Segment Age setting.
Using Group Policy
In the Group Policy Management Editor console, expand the following path: Computer Configuration > Policies > Administrative Templates: Policy definitions (ADMX files) retrieved from the local computer, Network, BranchCache.
Click BranchCache, and then in the details pane, double-click Turn on BranchCache. The policy setting dialog box opens. In the Turn on BranchCache dialog box, click Enabled, and then click OK.
To enable BranchCache distributed cache mode, in the details pane, double-click Set BranchCache Distributed Cache mode. The policy setting dialog box opens.
In the Set BranchCache Distributed Cache mode dialog box, click Enabled, and then click OK.
This method alone does not configure the Windows Firewall for BranchCAche however and this must be performed seperately.
Configure Windows Firewall with Advanced Security Inbound Traffic Rules
In the Group Policy Management console, right-click the BranchCache client computers GPO that you created previously. Click Edit. The Group Policy Management Editor console opens.
In the Group Policy Management Editor console, expand the following path: Computer
Configuration > Policies > Windows Settings > Security Settings, Windows Firewall with Advanced Security, Windows Firewall with Advanced Security – LDAP…, Inbound Rules.
Right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens.
In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Content Retrieval (Uses HTTP). Click Next.
In Predefined Rules, click Next.
In Action, ensure that Allow the connection is selected, and then click Finish.
Important
You must select Allow the connection for the BranchCache client to be able to receive traffic on this port.
To create the WS-Discovery firewall exception, again right-click Inbound Rules, and then click New Rule. The New Inbound Rule Wizard opens.
In Rule Type, click Predefined, expand the list of choices, and then click BranchCache – Peer Discovery (Uses WSD). Click Next.
In Predefined Rules, click Next.
In Action, ensure that Allow the connection is selected, and then click Finish.
Important
You must select Allow the connection for the BranchCache client to be able to receive traffic on this port.
Repeat the above steps for Outbound rules, i.e allowing the following.
Using Netsh.exe
The below command will set the BranchCache service to distributed mode and also configure the Windows Firewall in one go:
Using PowerShell
The following PowerShell command will set the client to use BranchCache in distributed mode.
This will also configure the BranchCache service in distributed mode and also configure the Windows Firewall.
Configure BranchCache in Configuration Manager
Setting up BranchCache with ConfigMgr is relatively easy. BranchCache can be enabled for all deployment types withing ConfigMgr, and will work seamlessly providing that the Distribution Points are all ’BranchCache Enabled’, and Deployments are BranchCache enabled at creation time.
Enable BranchCache on ConfigMgr Distribution Points
To enable and configure BranchCache on a Distribution Point, it’s a simple as checking the following box on the Distribution Point properties.
Enable BranchCache for Deployments
All BranchCache enabled deployments should be configured to ’download content from distribution point and run locally.’
Additionally:
Software Update Deployments: Download Settings Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’
Package Deployments: Distribution Points Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’
Application Deployments: Content Tab on the Deployment Type – complete the checkbox ’Allow clients to share content with other clients on the same subnet’
Task Sequences (Current Branch Only): Distribution Points Dialog – complete the checkbox ’Allow clients to share content with other clients on the same subnet’
Testing Downloads via BITS and BranchCache
This section applies to ConfigMgr but works equally well without. Just use a different content source for testing.
Create and distribute a Package containing some files (small and large to test all scenarios).
Then you need to get the Package ID – which looks like XYZ12345.6 (XYZ being the sitecode, and it will only have the .x version stamp if it’s been updated at some point), and a file within the package which you will use as the source for the download. Once you have that, just create your URL and put it into the PowerShell below. Once you execute the script – it will prompt you for credentials, so use a relevant domain account with sufficient rights to download the content..
Then – all being well, BITS will connect to the DP, and download the content.
Import-Module BitsTransfer
# URL to file on DP
$source = "http://server.domain.local:80/ SMS_DP_SMSPKG$/CEN00000.0/filename.exe "
# Local file path here
$dest = "C:\Temp"
$Job = Start-BitsTransfer -DisplayName '2Pint Job' -Authentication Negotiate -Credential domain.local\administrator -Source $source `
-Destination $dest -TransferType Download -Priority Normal -Asynchronous -RetryInterval 60
while (($Job.JobState -eq "Transferring") -or ($Job.JobState -eq "Connecting") -or ($Job.JobState -eq "TransientError") -or ($Job.JobState -eq "Suspended") ) `
{ sleep 5;} # Poll for status, sleep for 5 seconds, or perform an action.
Switch($Job.JobState)
{
"Transferred" {Complete-BitsTransfer -BitsJob $Job}
"Error" {$Job | Format-List } # List the errors.
default {$Job | Format-List } # Perform corrective action.
}
Checking the results
On the DP server – Check the BranchCache Kernel mode perfmon counters for:
BranchCache aware HTTP requests
Total Hash generations Accepted (if it’s a new file and no other clients have requested it yet)
Total Hash Retrievals Accepted
The above counters will tell you if BranchCache is functioning, and that your http requests are making it through
Note: If are you using De-Duplication on the volume that stores the packages on the DP, you won’t see any Hash creation stats in perfmon because it is likely using the Deduplication chunk store hashes.
On the Client
Check the BITS Event Log – Applications And Services – Microsoft – Windows – BITS-Client-Operational
Event 3 – BITS Job is created
Event 59 Your file gets added to the BITS job
Event 60 – File is copied – you can check to see if the peerProtocalFlags is set (it should be 1 if you are BranchCaching)
Event 4 – Job done, and you can see how much was copied from the DP vs Peers
BITS Optimization and Bandwidth Throttling
Although this document describes BranchCache operations, in most Content Distribution scenarios, the Background Intelligent Transfer Service BITS) performs the actual download. BITS is heavily integrated with BranchCache, and can be optimised for BranchCache enabled downloads.
BITS Policy
there are 2 Group Policies that provide fairly granular control of BITS bandwidth usage during working / non-working days/hours and during scheduled maintenance days/hours.
These are the only BITS policies that you should consider using, as they are the most recent and efficient available.
TIP:Do NOT use the ConfigMgr Client Setting BITS policy as it is old and not configured for optimal BranchCache downloads.
The 2 GPOs can be found under Computer Configuration -> Administrative Templates -> Network -> Background Intelligent Transfer Service
1 Set up a maintenance schedule to limit the maximum network bandwidth used for BITS background transfers
2 Set up a work schedule to limit the maximum network bandwidth used for BITS background transfers
The Work Schedule
This is the general day to day BITSPolicy setting used throughout your network.
This policy setting limits the network bandwidth that Background Intelligent Transfer Service (BITS) uses for background transfers during the work and non-work days and hours. The work schedule is defined using a weekly calendar, which consists of days of the week and hours of the day. All hours and days that are not defined in a work schedule are considered non-work hours.
If you enable this policy setting, you can set up a schedule for limiting network bandwidth during both work and non-work hours. After the work schedule is defined, you can set the bandwidth usage limits for each of the three BITS background priority levels: high, normal, and low.
You can specify a limit to use for background jobs during a work schedule. For example, you can limit the network bandwidth of low priority jobs to 128 Kbps from 8:00 A.M. to 5:00 P.M. on Monday through Friday, and then set the limit to 512 Kbps for non-work hours.
If you disable or do not configure this policy setting, BITS uses all available unused bandwidth for background job transfers.
The Work Schedule is shown above. Of particular note, is the checkbox at the top left of the ’Options’ pane, entitled ’Ignore bandwidth limits if the source and destination are on the same subnet’. This box must be checked as it allows BranchCache-enabled BITS transfers between Peers on the same subnet to transfer at higher speed (up to 60Mb/s). If this is not checked, Peer-to-peer transfers will only happen at the current throttled speed.
The Maintenance Schedule
This policy setting limits the network bandwidth that Background Intelligent Transfer Service (BITS) uses for background transfers during the maintenance days and hours. Maintenance schedules further limit the network bandwidth that is used for background transfers. This means that it overrides the work schedule and these values take presence.
If you enable this policy setting, you can define a separate set of network bandwidth limits and set up a schedule for the maintenance period.
You can specify a limit to use for background jobs during a maintenance schedule. For example, if normal priority jobs are currently limited to 256 Kbps on a work schedule, you can further limit the network bandwidth of normal priority jobs to 20 Kbps from 8:00 A.M. to 10:00 A.M. on a maintenance schedule.
If you disable or do not configure this policy setting, the limits defined for work or non-work schedules will be used.
The bandwidth limits that are set for the maintenance period supersede any limits defined for work and other schedules.
BITS and BranchCache FlashCrowd Events
A Flashcrowd event occurs when BITS/BranchCache are clever enough to detect that it’s downloading a segment that has been requested by many other clients. BranchCache generates a message to the BITS service – to the effect that you will see a burst (usually 15) of Events in the BITS event log with an ID of 208. This tells the BITS client to wait’, because someone is downloading the content that is being requested and it may be available soon.
The net result of this is that even if you have a ConfigMgr deployment where all of the clients execute the content download at the same time, all is not lost.
Tweaks
You can also configure BITS Flash-Crowd behavior via the registry so that those back-off intervals can be increased – which you may want to tweak if your clients are on the end of a particularly slow WAN link.
There are 3 entries that count are here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\ MaximumBackgroundCacheRetries
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\ MaximumForegroundCacheRetries
These values determine the number of retries depending on whether the BITS job in question is a FOREGROUND or BACKGROUND priority job.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS\CacheRetryIntervalMsec
This next value determines the interval between the retries, so in reality you may want to just edit this, which will increase the overall back-off period. By default, this is set to 1000 (1 second) So you can double the back-off just by changing this to 2000
Other BITS Tips
When using a speed over 2048 Kbit/s set the policy to use Mb instead of Kb. It just works better.
If you are on Windows 7, always apply https://support.microsoft.com/en-us/kb/2863374 Fixes an issue where BITS can ignore Policy and goes as fast as it can.
BITS stops doing BranchCache if it didn’t get the hash data the first 3 attempts. This is hardcoded.
Always use a BITS policy for BranchCache downloads! It just works better..
BranchCache and Windows Server Data Deduplication
One of the most advance features of BranchCache with V2 was the integration with Data Deduplication in Windows Server 2012/16. With this new innovation, BranchCache can perform deduplication on an actual transfer and on its own Cache storage. In addition, BranchCache will use the Deduplication chunk store for hash retrieval, which saves on processing time and resource.
What is Data Deduplication?
Deduplication is used to improve storage utilization and can also be applied to network data transfers to reduce the number of bytes that must be sent across the wire. In the deduplication process, unique chunks of data, or byte patterns, are identified and stored during a process of analysis. As the analysis continues, other chunks are compared to the stored copy and whenever a match occurs, the redundant chunk is replaced with a small reference that points to the stored chunk. Given that the same byte pattern may occur dozens, hundreds, or even thousands of times (the match frequency is dependent on the chunk size), the amount of data that must be stored or transferred can be greatly reduced.
Deduplication Evaluation
To aid in the evaluation of datasets Microsoft created a portable evaluation tool. When the Deduplication feature is installed, DDPEval.exe is installed to the \Windows\System32\ directory. This tool can be copied and run on Windows 7 or later systems to determine the expected savings that you would get if deduplication was enabled on a particular volume. DDPEval.exe can be run on a Content Server and the output will tell you of the potential savings.
Certain types of data are particularly suited to deduplication as there are many common data block within the structure. Examples are .WIM files, Word Documents, Driver Libraries etc.
Deduplication Configuration
Configure and run DeDuplication on a ConfigMgr Distribution Point
Because BranchCache uses the DeDupe chunk store to get hashes we need to ensure that when Deduplication runs, it is considering all files. You can do this by running the following PowerShell.
We don’t want to DeDupe ALL of the folders however. ConfigMgr doesn’t like you to DeDup the Content Source folders (not supported), all we really want to hit is the Content Library itself (the \SCCMContentLib folder at the root of the drive), and we can do this by excluding the other ConfigMgr folders that we don’t want, namely the SMSPKG,SMSPKGSIG and SMSSIG$ folders
So the above snippet with configure DeDupe to include all files, except those in folders that we excluded. It the runs the necessary Deduplication jobs on the volume and places the hashes in the chunk store ready for BranchCache clients to access.
Reporting on BranchCache Success
Although BranchCache works well in reducing WAN traffic it’s often difficult to tell when it is or isn’t working. Here are some methods of measuring BITS and/or BranchCache performance.
Event Log
The BITS Event Log provides information as to where the BITS download data originated from. Event 4 – on completion of a download will provide this info.
BranchCache Performance Counters
One way to check if BranchCache is being used is to monitor the BranchCache performance counters, these three counters in particular:
Retrieval: Bytes from cache—This shows how much data is being obtained via BranchCache instead of directly from the source server.
Retrieval: Bytes from server—This shows how much is being obtained directly from the source server, not from BranchCache.
Retrieval: Bytes served—This shows how data from the local machine's BranchCache has been sent to other BranchCache clients. This saves other clients from obtaining the data from the original source.
TIP: In Testing, you can reset the BranchCache perfmon counters using the following PowerShell cmdlet:
Reset-BC -ResetPerfCountersOnly
There is a full list of the counters with descriptions here:
https://technet.microsoft.com/en-us/library/dd637826(v=ws.10).aspx
2Pint Reporter Toolset
This can give you a more graphical representation of a download in real-time. (shown n below)
You can download this free tool from http://2pintsoftware.com/products/branchcache-reporting/
Summary
That’s all for now, hope it was useful. This is very much a work in progress and we plan to add further docs around BranchCache as and when we get the time. Any ideas on what you would like to see next? Ping us over at: http://2pintsoftware.com/ping-us/
Appendix A
BranchCache Netsh.exe commands:
https://technet.microsoft.com/en-us/library/dd979561(v=ws.10).aspx
BranchCache PowerShell Cmdlets:
https://technet.microsoft.com/en-us/library/hh848392(v=wps.620).aspx
MSDN Peer Distribution APIs:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd407951(v=vs.85).aspx
Last updated
