An overlooked part of content management for ConfigMgr / SCCM is Client Deployment and Client Upgrade.

This is mostly because, organisations hardly feel the hit of pushing out the ConfigMgr client for the first time, or when updating the client to a higher version, having well-connected sites and fast and wide communication paths to most of the network.

I’ve witnessed many times a Client Push take place to a high density of devices, without anyone feeling the burn from it. In the thousands up to the ten’s of thousands.

If we focus on Client Push, in essence, all that is happening is:

  • CCMSETUP.EXE and some ancillary files are copied to each remote device
  • CCMSETUP is spun up as a service, which then determines what files it needs building a BITS manifest, it then fires off the BITS job and brings down the needed content, and finally it kicks off the installations one after the other, leading into Client.MSI

The payload moving through this mechanism isn’t much more than Client.MSI at 30MB, CCMSETUP at a few megabytes, and any prerequisite files needed determined on a device by device basis, around 60MB on average for an x64 device, and a bit more for an x86 device (more prerequisites for x86).

So pushing 60MB out to ten’s of thousands of devices in one go is definitely going to create a surge in network usage, and it’ll have a short life time as it is a small payload, but overall, for most organisations it won’t cause much of an issue. And if it did, it can easily be mitigated against by spreading the deployment using the Automatic Client Upgrade feature, or staging the Client Push manually by selecting off a group of devices to push too at one time. Essentially reducing how many you hit in one go.

However, for a few organisations, this story takes a turn in a different direction. if they have a lot of sites on the end of 1MB or less network connections, which isn’t as rare as it sounds, then sending down 60MB to a bunch of machines will definitely interfere with possibly already over-used network links.

How can you ease that out, for both a first time deployment of the Client, or a Client upgrade?

The answer is to use Automatic Client Upgrade or Client Push, and leverage BranchCache in Distributed Mode.

I could throw together some screenshots to show the technical process of sharing content between BranchCache enabled devices, but the ground is well covered by others, most notability Phil Wilcock from 2Pint software, who breaks down BranchCache to its elements in good humour, and in great detail. You can certainly geek-up on BranchCache from the Microsoft BranchCache Overview here if you like, lots of foundational knowledge there to plunder.

I could show you how to switch on BranchCache with screenshots and a walkthrough but really, it is no more difficult than enabling some Group Policy and targeting the devices with it, that is it. All easily referenced from documentation and ample examples on the internet from Microsoft.

Once BranchCache is enabled in Distributed Mode on the devices, any BITS job will invoke BranchCache, resulting in CCMSETUP’s attempts to download its payload from the Management Point or Distribution Point to be diverted, and instead switched to a local source via peering, that is if the files are in the BranchCache Cache of a device residing on the same subnet as the one requesting the content, if this is not the case, devices will naturally head back to the Management Point or the Distribution Point for the Client files, and store then in their BranchCache Cache, making them capable of responding to future device request for client files.

The only prerequisite needed for getting an optimal experience with BranchCache, and the cool peering that results from using it alongside client deployment, is to pre-cache devices on each subnet.

Try to avoid lid-based devices, portable and with battery, and install the ConfigMgr Client to one or two static\wired machines in a remote location, residing on the other side of a 1MB connection, and then let the rest of the devices get the Client Push a little while after, they will begin peering amongst themselves, sharing client installation files, instead of downloading the same content across the 1MB link.

Obviously, the amount of administrative effort versus user inconvenience has to be weighed up, but if you are in need of bottoming out the network usage induced by a client push or upgrade, this is a low cost (free!) method of achieving it, before moving up to the big boys that cover the Alternative Content Provider scene, such as Adaptiva and 1e, and 2Pint, who heavily leverage BranchCache and SignalR to gain massive network usage savings for low cost.

So, if you have mega-small network links with say, more than 20 or more devices, think about switching on BranchCache and get the free reduction in network usage that comes with it.

It will help, but you’ll need to handle pre-staging which becomes a manual effort, but one well worth going through if not at large scale, just to get the reward … users not complaining winky wink.

Maintaining collections of devices nominated to host the client installation files cannot be easily done due to no Top clause in WQL, if that existed we could list off the Top 1 device in a subnet that meets certain criteria, and client push to the collection to fill up the BranchCache Cache on each subnet, which devices would feed off of, hence why administrative effort is needed.