A Geek’s Guide to reduce the network impact of Windows 10 Updates (and other packages) with ConfigMgr
Windows 10 updates, both the scheduled updates from Microsoft as well as updates of Windows 10 apps, can put a significant load on your network. At least if you compare it with what a Windows 7 client does. Add that to all you normal deployments, images, applications etc. and you’ll find yourself running down the hallway, chased by folks from the network group :)
But no worries, hope is not lost. With ConfigMgr, you can greatly reduce the network impact by embracing peer to peer solutions.
Peer Cache, BranchCache, and a touch of Express Installation Packages
In a previous post: A Geeks Guide to Peer Cache in ConfigMgr Current Branch, I explained how to setup ConfigMgr for Peer Caching to greatly reduce the network impact of not only Windows 10 updates, but in fact all packages that ConfigMgr is using. In this post: How can I use Express Updates when patching Windows 10 with Quality Updates in System Center Configuration Manager (Current Branch), Microsoft MVP Niall Brady (@ncbrady) shows how to configure the Express Installation packages introduced in ConfigMgr 1702.
Peer Cache and BranchCache - Better together
In this guide, you learn how to configure BranchCache for ConfigMgr, because BranchCache and Peer Caching are better together. For example, unlike BranchCache, Peer Caching happily works over subnets (it’s limited to boundary groups). BranchCache on the other hand is using Data Deduplication techniques, and will happily share content between clients even if there is a local DP on the same subnet. Something the current implementation of Peer Caching does not do. Shorthand, when combining BranchCache with Peer Cache, you get the best of both worlds :)
Step-by-step guide – Setup BranchCache for ConfigMgr Current Branch
The following is a quick guide to setup BranchCache for ConfigMgr Current Branch, and how you can verify that it actually works.
Friendly reminder: BranchCache and Peer Caching are better together, so make sure to also configure Peer Caching: A Geeks Guide to Peer Cache in ConfigMgr Current Branch
Creds: A shoutout totally goes to @ozthe2 for one of the early write-ups on using BranchCache with ConfigMgr.
The guide in this post covers five simple steps to get it going:
- Step 1 – Enable BranchCache on the Distribution Points
- Step 2 – Enable Data Deduplication on the Distribution Points
- Step 3 – Configure BranchCache on the clients
- Step 4 – Configure your ConfigMgr packages to use BranchCache
- Step 5 – Verify that it works
But first… a little bit of background.
Introduction to BranchCache
BranchCache is available in Windows 7 / Windows Server 2008 R2 or later versions of Windows (I better mention that it has limited support via BITS 4.0 in Windows Vista and Windows Server 2008 before the good folks at @2pintsoftware crack down on me :) ). However, if you are still deploying Windows Vista or Windows Server 2008, in the year of 2017, please stop :)
Anyway, like Peer Caching, BranchCache is a technology for optimizing network bandwidth, or simply put: It helps you download content in distributed environments without killing the network. Now, BranchCache comes in two flavors:
- Distributed Cache Mode. The mode that ConfigMgr supports, and in this mode clients are sharing content with other clients.
- Hosted Cache Mode. This when you are using local servers to cache content for the clients. Since this is not used with ConfigMgr, I won’t mention this mode any more in this guide.
How BranchCache works in Distributed Cache mode (with ConfigMgr)
BranchCache may look pretty simple at a first glance, but once you go behind the scenes there is quite a lot of things going on to make this work. That being said, you don’t need to be a super-expert on BranchCache to use it. Once configured correctly, it behaves nicely without much need for maintenance, and when your manager asks “what’s in it for us”, you simply answer that it makes everything go faster, and it reduces the network traffic on our WAN links. And it’s free. Solution sold. :)
Tip: If you really want to learn BranchCache in-depth, Mr. Andreas Hammarskjold (@andhammarskjold) presented a pretty shiny session at Microsoft Ignite. It’s one of those sessions you probably are going to watch a few times, and it’s not because it’s not a good presentation, it’s simply because there is a lot of info to take in (it is a good presentation). Here is a link to the session: Dig deeply into BranchCache: learning from the experts.
Back on track. The simplified version of how BranchCache works in distributed cache mode is like this:
- A ConfigMgr client requests a file on a BranchCache enabled distribution point (DP), and as part of that process, the client tells the DP that it’s BranchCache capable.
- The DP responds, and since it was told the client was BranchCache capable, it won’t provide the file to the client, but rather a collection of content identifiers, that define the content the client wanted. In this case a file.
- After receiving the content identifiers, the ConfigMgr client then tries to find a local computer (peer), on the same subnet, that already has the content (again the file).
- If another ConfigMgr client has the content, the first ConfigMgr client will download the file from it’s peer.
- If the first ConfigMgr client can’t find a local peer with the content (on the same subnet), it will once again contact the DP, this time saying it’s not BranchCache capable.
- Since it’s a “normal” file request from a “normal” ConfigMgr client, the DP happily hands over the file to the client, which puts the file in its local cache, ready to be requested by another client.
In my lab, I have two sites; New York (192.168.1.0/24) which has a local DP, and Chicago (192.168.4.0/24) which does not have a local DP.
- New York: With the CM01 DP, has five clients: W10PEER-0001 – W10PEER-0005.
- Chicago: With no DP, has five clients: W10PEER-0006 – W10PEER-0010.
Note: To setup a lab with multiple routed networks I recommend using a virtual router instead of the typical NAT switch in Hyper-V or VMWare. It can be based on either Linux or Windows, and you can find a step-by-step guide here: http://deploymentresearch.com/Research/Post/285/Using-a-virtual-router-for-your-lab-and-test-environment.
The lab network.
Step 1 – Enable BranchCache on the Distribution Points
To enable BranchCache on a DP you should do two things: The first one, enabling the ConfigMgr BranchCache feature itself, is mandatory. The second, configuring Data Deduplication on the DP is highly recommended since it both reduces the disk footprint for your packages, and it pre-calculates all checksums that the DP is using when clients are requesting content. Let’s start with the configurations you do in the ConfigMgr console.
1. Using the ConfigMgr console, in the Administration workspace, right-click your DP (CM01 in my example), and select Properties.
2. In the General tab, select the Enable and configure BranchCache for this distribution point check box, and click OK.
Note: The preceding steps will actually install the BranchCache feature on the server.
Enabling BranchCache on your DPs.
Step 2 – Enable Data Deduplication on the Distribution Points
As you learned previously, adding Data Deduplication to your DPs is really smart for BranchCache. This is how.
1. On your DP, using Server Manager (or PowerShell), add the Data Deduplication role (in File and Storage Services / File and iSCSI Services).
2. Reboot the DP if needed. Server Manager (or PowerShell) will let you know if it’s needed :)
Adding the Data Deduplication role.
3. Using Server Manager / File and Storage Services / Volumes, on the disk volume having the Content Library (SCCMContentLib folder), right-click CM01, and select Configure Data Deduplication.
4. In the Volume Deduplication Settings dialog box, select General purpose file server, and select to deduplicate files older than 1 day.
Warning 1: Since ConfigMgr only supports Data Deduplication on the Content Library (SCCMContentLib folder) and the SMSPKGx$ folders, make sure to enable Data DeDuplication only on that volume. If you have other ConfigMgr folders, like the installation folder (if this is also your site server), SQL folders (also if this your site server), a Remoteinstall folder (WDS), package sources etc., they must be excluded.
Warning 2: Read Warning 1 again. Make sure to only deduplicate ConfigMgr folders that are supported, and possibly non-ConfigMgr folders that you KNOW can be deduplicated (such as a MDT Lite Touch Deployment Share for example).
Excluding folders from Data Deduplication.
Step 3 – Configure BranchCache on the clients
To enable BranchCache on your clients, you create a group policy object.
1. Using Group Policy Management, create a group policy named Enable BranchCache.
2. Edit the Enable BranchCache group policy, and in the Computer Configuration / Policies / Administrative Templates / Network / BranchCache node, enable the following policies:
- Turn on BranchCache
- Set BranchCache Distributed Cache Mode.
- Set age for segments in the data cache: 90 days (default is 28 days)
Note: The Set age for segments in the data cache policy is not available for Windows 7 clients.
Enabling BranchCache in group policies.
3. Still in the Enable BranchCache group policy, in the Computer Configuration / Windows Settings / Security Settings / Windows Firewall / Windows Firewall with Advanced Security node, add the the firewall rules below using the predefined templates, and configure them for domain profile only.
- BranchCache - Content Retrieval (Uses HTTP)
- BranchCache - Peer Discovery (Uses WSD)
- BranchCache - Content Retrieval (Uses HTTP)
- BranchCache - Peer Discovery (Uses WSD)
4. Save the Enable BranchCache group policy and link it to the OU(s) where you have your ConfigMgr clients.
The inbound firewall rules for BranchCache (for the ConfigMgr clients).
Step 4 – Configure your ConfigMgr packages to use BranchCache
Once you have configured the server and client side of things, you need to configure your packages to have BranchCache enabled.
- To enable BranchCache for legacy packages, you configure their deployments. In the deployment Distribution Points tab, select the Allow clients to share content with other clients on the same subnet check box.
- To enable BranchCache for application model applications, you configure their deployment types. In the deployment type Content tab, select the Allow clients to share content with other clients on the same subnet check box. This is enabled by default, so chances are you don’t have to do this :)
Configuring a legacy package (it’s deployment) to use BranchCache.
Configuring an application model application (it’s deployment type) to use BranchCache.
Step 5 - Verifying that it works
Now it’s time to verify it works. In my example, I deployed a few packages configured for BranchCache to a collection containing my clients.
Once you see clients start to download content, you can fire up good old performance monitor and add the following two counters from the BranchCache node:
- BITS: Bytes from cache
- BITS: Bytes from server
Note: If the BranchCache node doesn’t show up even though the group policy has applied, simply reboot the machine and they will be there :)
Adding the BranchCache performance counters to a client.
A ConfigMgr client showing some BranchCache traffic.
You can also checkout the various BranchCache PowerShell commands. For example, Get-BCDataCache represents the BranchCache data cache.
Having fun in PowerShell.
After waiting for 24 hours, you can see the clients reporting their download history both in the ContentTransferManager.log, and by going to the Monitoring workspace and select the Distribution Status / Client Data Sources node.
Note: There is an unsupported / undocumented way to shorten the upload interval for lab and demo scenarios, but until the ConfigMgr team says it is ok to publish those details, I’ll wait :)
The ContentTransferManager.log reporting client data source info to ConfigMgr.
New York site
Below, you see the Client Data Sources for the New York site. This environment has both Peer Caching and BranchCache configured, but since the New York site has a local DP (same subnet), Peer Caching is never going to be used.
The Client Data Sources node for the New York site.
Below, you see the Client Data Sources for the Chicago site. Again, this environment has both Peer Caching and BranchCache configured, but since the Chicago site has a no local DP, you will see a mix of BranchCache and Peer Caching being used.
The Client Data Sources node for the Chicago site.
A little bit of SQL
You can also check the info in the database directly by querying the ClientDownloadHistorySources table:
Select * from ClientDownloadHistorySources
Or, why not use one of the ready-made views: vSMS_ClientDataSourcesContent.
There is also a ready-made ConfigMgr report for the client data sources, but as of now it seems to be a bit broken.
Written by Johan Arwidmark