display top 6 recent blogpost


Enabling BranchCache in SCCM Quickly and Easily


A few months ago, I posted on Twitter about my success with deploying BranchCache. That post sort of blew up, and somehow I ended up offering to write a blog post about it… I have seen a lot of blogs about setting up BranchCache, however, most of them end up using something outside of the built-in tools that ConfigMgr provides. This post will focus on setting up BranchCache using only the built-in solutions in ConfigMgr. BranchCache is very powerful and can be configured at a much deeper level than what ConfigMgr provides out of the box, however, I didn’t feel that I needed that level of configuration for my environment. I should also mention that this is literally my first blog post, so please, be gentle!

The Post that Brought Me Here


What is BranchCache?

BranchCache is a technology built-in to Windows since Windows 7 and Server 2008, it is a peer-to-peer technology designed to reduce the workload on distribution servers by allowing clients to share content between themselves. BranchCache is a very powerful technology with many options, but what really motivated me to set it up in my environment was how simple it is to turn on in ConfigMgr. Again, BranchCache has many more advanced settings and options than what I mention here, but those are not required to have a BranchCache setup that significantly reduces the load on your distribution points and network infrastructure.



Example of BranchCache and PeerCache working together

Before getting into how to configure BranchCache, a few quick words on a similar technology, PeerCache. PeerCache is an SCCM (not Windows), technology that functions in a similar way to BranchCache, however there are a few differences:

  • PeerCache uses the SCCM content store for it’s content on the client machine
  • PeerCache content is free to be shared outside the client’s subnet (but won’t cross to different Boundary Groups)
  • PeerCache requires the client to be reachable by it’s FQDN
  • PeerCache works in an SCCM distributed WinPE with little to no extraconfiguration
  • PeerCache SuperPeers should be carefully selected to ensure the best results

I am not going to go over the configuration of PeerCache in this article, the targeting of SuperPeers and other options makes it a bit more cumbersome to set up. However, both BranchCache and PeerCache can be set up at the same time, and having both enabled can lead to even less downloads coming from your distribution points and less traffic over the WAN.


How to enable BranchCache using SCCM

Enabling BranchCache in an SCCM Environment is easy, and consists of 2 main steps: Enabling it on the Distribution Points, and enabling it for clients.

Enabling BranchCache on a Distribution Point

Enabling BranchCache on Distribution Points

First, you will want to enable BranchCache on at least one distribution point. I started with turning it on for just one distribution point in my environment. After seeing good results, I enabled it on the rest of the Distribution Points. To enable the BranchCache setting on a distribution point, you can do the following:

  1. Open up the ConfigMgr Console
  2. Head to the “Administration” tab and click “Distribution Points”
  3. Right click and select “Properties” on the Distribution Point where you want BranchCache enabled
  4. In the “General” tab, check the box for “Enable and configure BranchCache for this distribution point”, then click “Apply” and “OK”

Enabling BranchCache on ConfigMgr Clients

Once BranchCache is enabled on at least one Distribution Point, you can turn it on for your ConfigMgr clients.

Enabling BranchCache in Client Settings

The easiest way to configure BranchCache for your clients is through Client Device Settings. Because we are configuring BranchCache through Client Settings, the configuration can be rolled out as quickly or slowly as you want. For my environment, I tested a small subset of systems before rolling it out everywhere. Within a week of rolling out BranchCache everywhere, I was seeing huge amounts of data being shared through BranchCache. If you have concerns about congestion from Wi-Fi devices sharing their content (I received a few questions on this, but have not seen any issues myself), you can exclude, for example, all laptops from the collection that BranchCache is enabled on.
To turn on BranchCache for your clients, do the following:

  1. Head to the “Administration tab in the ConfigMgr Console
  2. Open “Client Settings” and either right click and select “Properties” for the appropriate Client Settings you want to modify or create a new set of Client Settings. (I started by creating a new set of settings, and eventually moved the BranchCache configuration to the Default Settings)
  3. Put a check on the “Client Cache Settings”, then navigate to the “Client Cache Settings” page that appears.
  4. Set the following settings on the “Client Cache Settings” page:
    1. Configure BranchCache – Yes
    2. Enable BranchCache – Yes
    3. Maximum BranchCache cache size (percentage of disk) – 10 is the default, choose whatever amount is good for your environment.
    4. If you want other Client settings to manage the cache size, make sure to set “Configure Client Cache Size to “No” here
    5. Click OK to accept these settings
  5. Right click the client settings you just created and select “Deploy”
  6. Choose the device collection to deploy these settings to
  7. You are done! Now it is time to watch the data savings!


How to tell if BranchCache is working?

The easiest way to check that BranchCache is actually working is right in the ConfigMgr Console! Head to “Monitoring” -> “Distribution Status” -> “Client Data Sources”. From there you can see where clients are downloading from based on Boundary Group. After BranchCache was enabled in my environment, I simply checked this page daily to see how well things were working out.

Note: You may have to turn on the “Client Peer Cache” feature in “Administration” -> “Updates and Servicing” -> “Features” in order for the Client Data Sources dashboard to show up (Thanks to Bert in the comments for pointing this out!).

Content Distribution View in the SCCM Console


If you want to ensure the client setting is set on your clients, the following command run in an admin powershell session on a client will be able to tell you that:

Get-WmiObject -Namespace root\ccm\policy\machine -class ccm_superpeerclientconfig


Andrew Jimenez

Twitter: @AndrewJimenez_

DHCP Failover and Recovery


I recently had an issue with a Domain Controller that was unresponsive at a remote site. Since it was just a virtual machine with no special settings, I punted and rebuilt the server. After I did all the recommended steps for removing a DC from Active Directory and was already configuring the new server, I remembered that I had setup DHCP Failover for this site. I would be lying if I did not say a twinge of panic set in at that moment. I had setup DHCP Failover in hot standby mode almost five years ago and had not not given it a second thought. Fortunately, the process was so simple that I did not even need to use PowerShell. I deleted the old Failover Relationship and then recreated it. The detailed steps are below.

Delete Old Failover Relationship

First on the active DHCP server, open DHCP Manager. Right click on IPv4 and choose Properties

On the Failover tab, select the failover relationship and click Delete.

Click OK to confirm the deletion.

The Failover Relationship is deleted. Note that you will see failure messages if the partner server cannot be reached. Click Close.

Create New Failover Relationship

Now that the old failover relationship is removed, we can recreate it. Obviously, you will need to repair or rebuild the DCHP failover partner server first. Once the partner server is ready, open the DHCP Manager on the active server. Right click on the scope and choose Configure Failover.

Select the Scopes and click Next.

Click Add Server.

Type the server name or select it from the list of authorized DHCP servers. Click OK.

Click Next.

Configure Failover Options for your environment. You may need to choose a new Relationship Name if the previous DHCP Failover was not successfully deleted. Click Next.

Confirm the settings and click Finish.

Once the DHCP Failover is created click Close.

DHCP Failover is easy to configure and easy to recover. I was surprised at how smoothly I was able to add and delete the partnerships using Windows Server 2016 and 2019. I repeated the process several times as I wrote this article. I would suggest creating a DHCP failover partner especially if you have a remote site with little or no IT support staff. I was fortunate that I had setup DHCP Failover at this site several years ago. Of course, in my case better monitoring software would have helped alert me to the server failure sooner. Hopefully, I will be writing about installing and configuring monitoring software soon.

You may need to rely on PowerShell to remove a Failover Relationship. The commend Remove–DhcpServerv4Failover will delete the specified partnership. A complete list of PowerShell commands can be found here:



Ben Dumke