The value of bandwidth and peer caching with ConfigMgr

Over the years building ConfigMgr, I have definitely learned about the value of bandwidth.

I remember, when I first started working on ConfigMgr in 2003, I had monthly calls with a customer who had 18,000 remote offices and needed to be able to roll out up to 10 updates every day to those 18,000 offices. They carefully paid attention to every single byte sent across their WAN. 

The release of Windows 10 significantly changed the cadence at which organizations deploy new versions of Windows – which is usually the single largest package for most users. When you think about organizations rolling out new versions of Windows twice a year, you can understand why they would much prefer to only download that new release of Windows once per site and then have a local device serve the update to it’s peers. 

Over the last couple weeks, I’ve had a number of customers ask me about the effectiveness and use of the peer-to-peer capabilities built into Windows and ConfigMgr. To say these capabilities have come a long way would be a massive understatement.

To best explain the remarkable progress that has been made here, I’ll let data from two different deployments speak for themselves – it’s something I’m seeing in a lot of ConfigMgr deployments all over the world. 

First, check out this tweet from an IT Pro explaining the bandwidth savings from just a single ConfigMgr distribution point : https://twitter.com/mhouston100/status/1073425968839122944

Look at how much of the latest Windows 10 update was delivered by the ConfigMgr peer cache!

If you want to see how we’re this same thing internally, you can read more here: https://blogs.technet.microsoft.com/system_center_in_action/2018/10/16/our-journey-to-peer-content-distribution/.

Also:  Note that over 90% of the content downloaded and installed internally at Microsoft has come from peers.  Keep in mind that we’re managing more than 350k PCs at Microsoft using these capabilities.  

So, how is this effecting customers right now? In just 7 days, customers using the ConfigMgr peer cache saved 1.6 petabytes of bandwidth. Seven!

And, as long as we’re talking about bandwidth savings, customers deploying Win32 apps through Intune have saved 1.4TB of bandwidth from the built-in peer-to-peer capabilities since the 1811 update.

The built-in peer cache capabilities in #ConfigMgr and #Intune are powerful, broadly and deeply used, and ready for you to deploy right now.

You can literally measure the value of these capabilities in petabytes.