​Branch Cache Vs. Peer Cache Vs. Delivery Optimization Vs. Distribution Points

branch cache

Throughout the various iterations of ConfigMgr (SCCM), we have seen numerous technologies integrated into the management platform. These integrations were either directly or indirectly built to help administrators tackle the challenges presented when managing thousands of devices in an enterprise at scale.

The current wave of these which I want to talk about are primarily aimed at addressing 3 critical areas:

  1. Efficient deployment and management of Windows devices
  2. Mechanisms to streamline existing ConfigMgr infrastructure
  3. Effective utilization of WAN bandwidth

So firstly, why do we need to think or address these areas?

Organisations are often more globally dispersed with 10’s if not 100’s of offices spread throughout different regions. These remote offices put an ever-increasing strain on the infrastructure and networks required to operate in these scenarios. ConfigMgr is a scalable solution, however, in the past this would typically mean that IT departments would continue to deploy Distribution Points to each of the regional offices to provide management and Software deployment services for endpoints at each of these locations. The issue becomes that this approach can frequently introduce just as many problems for IT as it intends to solve, thus increasing the infrastructure footprint when organisations are generally looking to reduce infrastructure and move away from on-prem services and solutions. Finally, if you don’t deploy the Distribution Point infrastructure and perhaps opt for remote software deployment services, then this will inevitably only increase the strain on organisations Wide Area Network (WAN) links often causing congestion with a whole host of application and business services all fighting for a piece of the available (and sometimes limited) bandwidth. This ultimately, doesn’t help IT or the business drive efficiencies.

Keeping pace with new trends

One key area that brings this topic into sharp focus has been the trend of the “as a Service” (aaS) model, and specifically Windows 10. Windows 10 is delivered leveraging the Windows as a Service (WaaS) model. Unlike Operating Systems of the past that would have a pre-defined life-cycle and interim updates to maintain stability and security, this means that Windows 10 will be perpetually updated on an on-going basis much like we experience with other technology platforms such as our smartphones. In my opinion, this is a largely positive move as it will provides far greater control on which version(s) can exist; and by ‘exist’, I mean ‘be supported’. It enables Microsoft to introduce new features incrementally, ensuring ongoing support for technological changes can be satisfied. But, as we have seen, the operating system improvements in sophistication and complexity also means an increase in the size of updates required to service and maintain the core system. One area where this has presented a challenge in the Enterprise space is understanding how organisations will maintain this ongoing change, and a key aspect of this is the systems used to managed and maintain these systems today ConfigMgr.

As they also recognise that simply deploying more hardware isn’t going to work anymore, Microsoft has been working hard to provide alternatives to the traditional ‘just deploy more hardware’ solution. They are opting to adopt software-defined solutions to help organisations with this technology change.

That’s a good thing, right? Well… yes. However, I also believe that Microsoft is also driving these solutions in the knowledge that adopting software-defined solutions will be the most effective way for organisations to adopt and embrace a Win10 (WaaS) operating platform.

The Good the Bad and the Ugly (you decide)

From my point of view, there are now three clear alternatives to deployment of traditional infrastructure (hardware-based distribution points) and these are:

1. Branch Cache

Branch cache technology was originally introduced into the Windows Server platform as a way for file servers to cache recently accessed files providing faster load times for end-users to access files and content. More recently, this tech has also been integrated into ConfigMgr allowing administrators to leverage this caching solution for software-based content at each site where it doesn’t necessarily stack up to deploy a traditional Distribution Point. Unfortunately, there are some drawbacks to this method with the primary one being that this solution is largely a ‘black box’ with very few options for configuration and, more importantly. no easy way of monitoring what content is cached.


  • Easy to set-up
  • Can handle non ConfigMgr content types
  • Supports de-duplication


  • No management or reporting interface (difficult to know what content is cached)
  • Requires separate cache location for ConfigMgr for content storage (duplicated cached content)
  • Doesn’t natively support WinPE out of the box
  • Limited to Subnet based discovery broadcasts (problematic in wireless networks where broadcast may be disabled)

2. Peer Cache

Microsoft’s recent integration enables ConfigMgr clients to share content with other Peer cache enabled clients. This now utilizes the LEDBAT transport to efficiently manage network activity during a caching event to ensure that the network doesn’t become saturated when sharing content.


  • Directly integrated in ConfigMgr, so any enabled device can perform this function
  • Supports partial content download, so client can serve content as soon as the first blocks are available
  • Utilizes the efficient LEDBAT data transfer technology to reduce network congestion


  • Client peering scoping is limited to ConfigMgr client site boundary groups which can become complex to manage due to the number required and can limit peering capabilities down to smaller groups of end-points
  • ConfigMgr scheduled deployments can cause multiple end-points peering from origin sources, reducing the peering efficiency achieved

3. Delivery Optimization

Microsoft’s integrated peering solution introduced into the Windows 10 platform is a peer-to-peer client update service that uses both local and remote end-points (via the internet) to deliver Win10 updates and Windows store applications.


  • Integrated directly into the OS, easy to enable / configure
  • Standalone solution not requiring ConfigMgr integration (great for SMB’s)
  • No upfront costs


  • Only supports Win10 endpoints
  • Limited ‘use case’ for content deployment (only supports Updates and Store Apps)
  • No centralized management (no reporting or analytics)
  • No control over content
  • Requires extensive boundary configuration

No such thing as a free lunch

Now don’t get me wrong, the Microsoft tools and integrations to solve the challenge of providing efficient deliveries while reducing and simplifying your ConfigMgr infrastructure are very effective, but as you might start to see, no single solution can act as holistic solution to solve this problem. In fact, from many discussions with customers and working at the coalface on this, I have come to realise that you will most likely need to implement all these technologies in parallel as point solutions to achieve a successful outcome.

Well that’s alright. After all, they are free to use?

You have probably heard the phrase “No such thing as a free lunch” and when we are presented with this potential offer, we should be thinking “what’s the catch”?

All of us in both our professional and personal lives are offered free (at the point of use) software, services and offers. However, sometimes we need to consider ‘does free really mean free’? Often what we need to do is take a step back and examine the bigger picture to the problem we are trying to solve. If we accept free services do these have a catch and/or a drawback? When evaluating these free solutions, I recommend considering the following aspects:

  • Does the solution provide all the capabilities and features we require to address the problem?
  • Are there going to be hidden costs further down the line?
  • Is the solution going to require additional work or effort on our side?
  • Do we have enough time, knowledge and resources to support the additional effort required to manage any functional deficits?

The Toolbox Vs. the Contractor

Given the above, we can all sometimes solve a problem by ourselves utilizing a ‘Do It Yourself’ approach. In my personal life, I have been going through a house refurbishment, so I’ll use that analogy here. I have often asked myself “Do I just DIY this, or do I need to bring in the professionals?”. I go through a very similar thought process to consider the upsides and downsides to each option. Some considerations when pondering the DIY approach:

  • Up-skilling – Will I need to build my knowledge around the area of work I’m looking to take on?
  • Time – Do I have the time to invest in doing the job myself, as it will take me more time than a professional to achieve the same task?
  • Outcome – Will I be happy and/or satisfied with the result? Will it be delivered to the standard required?
  • Risk – Are there significant risks associated with undertaking the work? Would a professional with proven experience mitigate these?
  • Cost – Considering the possible mistakes and/or overlook of the previous considerations, will doing the work myself really save me money?

So, it certainly makes sense to me that we make the same evaluations in our commercial / professional lives. Yes, we can do a job ourselves, but we may not achieve the desired outcome or to an acceptable standard, and this I think is certainly true when considering the free Microsoft solutions. Do you muddle through and hope for the best outcome whilst increasing your operational overheads and perhaps not achieving your strategic goals, or do you engage and procure a premium solution that delivers all the functionality and capabilities required to ensure a successful outcome? Sometimes, letting the professionals take care of it can add immense value to your organisation by leveraging their many years of expertise and importantly delivering all the functional specifications in a single ‘one stop shop’ solution.

Closing summary

There are many options to consider when re-defining your ConfigMgr infrastructure. What is clearly apparent is that a traditional approach of simply deploying more and more Distribution Points won’t help to scale your infrastructure to meet the demands of the modern workplace, WaaS and the on-going servicing and maintenance demands these changes will make on your environment.

The post ​Branch Cache Vs. Peer Cache Vs. Delivery Optimization Vs. Distribution Points appeared first on Kollective Technology .

To view our Partner blog, click here

A Day In the Life of a Kollective for ConfigMgr Admin


Do you have trouble delivering software and OS updates, patches, and applications to remote corners of your enterprise network? Are you tired of tying up the network when large packages are pushed? We think there is a better way. Follow along as we take you on journey to show you what your network could be. A journey we like to call “A day in the life of a ConfigMgr Admin.”

“Set it and forget it” with K4CM

Your company recently installed Kollective for ConfigMgr (K4CM). The Kollective integration is enabled through SCCMs Alternate Content Provider API, also known as ACP. Once our publisher is installed on your site server and our agent on your endpoints, it is “set it and forget it.”

Let’s imagine your organization went live with our system yesterday, and you hit send on a software update package at the end of the workday. When you get to the office this morning, you are anxious to see how your package delivery performed. You login to the Kollective platform and here is what you see:

The package has been distributed across the network by utilizing Kollective For ConfigMgr, our cloud-based content delivery solution, which requires no additional hardware, professional services, or lengthy setup. In the past, this delivery may have taken days to complete, but now it happens within hours. You can easily see where your package was delivered geographically, to how many machines, and how much bandwidth was saved.

Terabytes of bandwidth savings

The Kollective for ConfigMgr agent shows 79% peering for this delivery. For the 2134 machines that were targeted, what would normally require 4.835 GB to deliver the package, only used 1.015GB. This is a 79% reduction in the amount of bandwidth required and is accomplished by transferring the load from the WAN to the LAN.

This is a relatively small package; imagine the bandwidth savings and network effects on a 4GB Win10 Quality update. The savings from just that one delivery will be measured in terabytes. How many deliveries like this do you do a month? Someone in your organization is likely accustomed to calculating how much additional bandwidth will cost – this is a rare opportunity to calculate how much bandwidth can be saved, and what that equates to in dollars saved.

Intelligent mesh peering means no “single point of failure”

One factor to keep in mind is that you no longer require a distribution point for many of these locations, and have thus removed a “single point of failure”. With Kollective, machines coordinate with one another to transfer content over the WAN once and then share the content with one another using our mesh peering technology. In addition, our real-world experience shows that a K4CM customer can expect a 90+% reduction in software delivery related helpdesk tickets, leading to significant workplace efficiency gains due to a reduction in time spent chasing down failed deliveries. Allowing your employees to do their job rather than fixing problems is significant in terms of employee satisfaction and real cost savings.

Have a remote office in Alaska that you are concerned about? As you can see in the image above, this package was safely delivered on the LAN side in the Anchorage office and got there without shutting down mission-critical traffic due to the agents’ ability to dynamically throttle when it detects higher priority traffic. You won’t receive frantic calls from your Network Team that the package you are managing is shutting down the network. The machines in this office, just like the machines in every other office, are sharing the package data amongst themselves using our intelligent mesh-peering solution.

The Kollective process allows a machine to get content from the nearest acceptable peer and is broken up into blocks. Here is how it works: imagine an employee has a machine that is downloading content over the WAN and then “serving” other machines as the “LAN leader” (in the background, and unbeknownst to her). She decides to grab her machine and head out for the day. Another Kollective agent will immediately resume the WAN download and begin serving that content to other peers.

Are you considering adopting Cloud Management Gateways for remote users or “Internet Only” remote offices? at some of these remote offices? As a 100% cloud-based solution, Kollective for ConfigMgr can support peering when using a CMG, providing the ability to manage clients on the internet outside of the traditional organization network perimeter. Since the Kollective Agent doesn’t require network mapping or boundary groups, groups of users in remote locations can effectively peer with one another las if they were within your network boundaries. This allows for far more efficient and effective software delivery.

All of this happens automatically, and the agent gets smarter over time. The days of boundary group mapping are over. There is no need to create or maintain boundary groups, as the agent will automatically go find the content it needs from the nearest peer that has it. After a few deliveries, each agent will remember where it got the content the last time and look there first. Thus, the agent gets “smarter” over time, making deliveries more efficient and saving more bandwidth. It is not unusual to see peering rates of over 90%, which leads to some amazing savings when you factor in the number of machines targeted and the size of the packages.

Drilling down into the details

Where did the package go? Let’s take a look… Gone are your days of pulling logs to see what happened. K4CM allows you to start from the top and get broad information about where the package was sent. From there, you can drill down to easily find out what countries were targeted, what offices, and even what machines.

You can also determine what machine was serving as the LAN leader, what machines were pulling content from that leader, and figure out if a machine or office is acting outside of expectations.

As the GM for Kollective for ConfigMgr, I’m pretty excited about what our product can offer you. From the costs savings and workplace efficiencies to real and useful network insights, Kollective can help you distribute packages without hassle, freeing you up to focus on other mission-critical tasks.

Now that you have witnessed a day in the life of a ConfigMgr Admin, why not give us a spin to see if K4CM is right for you with our 60-Day Free Trial .

Ciena: Customer Case Study

Learn how Ciena uses Kollective for ConfigMgr to managing software distribution on a global scale.

Ciena: Customer Case Study

Learn how Ciena uses Kollective for ConfigMgr to managing software distribution on a global scale.

Related Blog Posts

The post A Day In the Life of a Kollective for ConfigMgr Admin appeared first on Kollective Technology .

To view our Partner blog, click here

Death of Windows 7: Remote Office OSD Deployments


Hopefully everyone is aware that Microsoft will be ending support for Windows 7 in 2020 . There are many blog articles and press releases pushing this point. Organizations have had a couple years of extended support, thus paying additional fees to Microsoft for security updates, but come January 14, 2020 this will no longer be an option.  

In a recent surveys, most organizations claim they have already started their migrations to Windows 10. Many companies are already using Microsoft System Center Configuration Manager (SCCM) to manage their endpoints, so utilizing ConfigMgr’s OSD capabilities to migrate to Windows 10 is the most supported and best documented strategy.

IT groups may have started their Windows 10 migration plan by first upgrading their home and regional offices because of strong IT presence, and fast connectivity to local ConfigMgr distribution points. But what about remote edge locations? Organizations with many small locations with few clients such as banks, retail stores, or small government offices may find it challenging to deploy Windows 10 to the edge. The challenges of deploying Windows 10 to these locations may include:

Poor Connectivity – small locations with less than 20 clients may not warrant fast network connection for day to day operationsTransferring gigabytes of content to these locations for operating system images, driver packages, and even monthly patches can put a heavy strain on the network and cause a negative impact to the business.

Cost – as the amount of data being delivered to remote locations is significant, IT organizations may have to spend more on connectivity when normal daily operations require less bandwidth. If it is decided that installing ConfigMgr distribution points would reduce the network impact, companies have to weigh the cost benefits of server licensing, hardware, and continual monitoring and maintenance of those DPs. If there are hundreds or even thousands of locations to support, it may not be worth it. 

Lack of Local IT Staff – some small locations such as retail outlets may not have access to a dedicated IT staff. Scheduling visits to do deployments can be expensive and difficult to coordinate. Although Configuration Manager can fully automate a Windows 10 deployment, to avoid downtime, the OSD process must be foolproof. Unfortunately, there is no such thing as a foolproof OSD scenario as hardware failures may occur. 

Considering those challenges, what options does an organization have to speed up the deployment of Windows 10 to these small remote offices? 

Hardware Refreshes – as computing hardware gets close to end of life, they will need to be swapped out. Windows 10 can be loaded on the new hardware and shipped to the remote office. This option does reduce the technical challenges of doing OSD in the field, but IT presence may still be required to provision the new equipment.

Sneakernet – companies can deploy field IT, but to facilitate the OSD process they will have to travel with a removable drive to manually execute Windows 10 task sequences on individual systems. This is another high touch option that likely requires additional planning to update the removable drives when needed as well as  dealing with the travel logistics of visiting each location. This is a relatively high cost solution depending on how many locations need to be serviced, and how many field IT representatives are available. 

ConfigMgr Distribution Points  it can be expensive providing OSD services to remote locations. OSD content can be delivered over the network once to a local distribution point in which the clients would not need to download large files over the network. Realistically, many IT organizations choose not to deploy distribution points to small offices. The costs associated with maintaining a large amount of distribution points at hundreds or thousands of remote sites can be very expensive. Add to that, the licensing costs for Windows Server and hardware costs that include maintenance of those physical devices. Administrative costs are subtler but still daunting as each content distribution has to be executed and monitored, and if there are sites which are on the other end of high latency connections, there will likely be failures which will cause delays and potentially impact the deployment schedule.  

PeertoPeer Technology – aIT organization may decide to forego the implementation of hundreds of additional distribution points and implement a peertopeer solution. Not all peering options are the same. Microsoft’s native Configuration Manager Peer Cache solution does solve the problem of delivering the content to a remote location once, but it requires additional administrative overhead. The most obvious issue is that an administrator would have to effectively pre-seed the task sequence content to the remote location, but this would be required for any peer-to-peer OSD delivery.  

The real pain is continuing to maintain boundaries and boundary groups. Configuration Manager uses boundary groups to determine who to peer with, so the network topology needs to be continually maintained for optimal peering. Kollective for ConfigMgr  cloud based peer-to-peer solution doesn’t use boundary groups or any other network topology mapping to determine the best peers. Kollective’s mesh based peering technology uses real time network mapping to automatically determine the best peers and refines the topology over time. Since ConfigMgr content is stored in the cloud, remote edge locations with only Internet connections can retrieve content quickly, transferring the content only once, regardless of how many clients are requesting it at a given time. 

Regardless what type of business you run, or how your network is defined, it is vital that you protect your business with the most updated OS and that you have a plan in place to manage the reoccurring updates that come with WaaS. I hope this article helps you understand the challenges of deploying Windows 10 to remote offices and provides some options to help you optimize deployment.


How today’s enterprises are preparing for tomorrow’s security disaster

Microsoft will officially end support for Windows 7 on January 14, 2020, yet 43% of enterprises are still running the outdated platform. Learn how far enterprise businesses are in their migrations to Windows 10, the challenges they are facing and why IT leaders need a software distribution strategy to prepare for WaaS.

Related Blog Posts

The post Death of Windows 7: Remote Office OSD Deployments appeared first on Kollective Technology .

To view our Partner blog, click here