Our journey to peer content distribution

The lead up

              Here within Microsoft we pride ourselves as being the “first and best” consumer of ConfigMgr features.  With that comes early learning and a little bit of pain as we try features early in the development cycle, and with code that is sometimes not fully tested or implemented as full as envisioned.  With the advent of the ConfigMgr (a.k.a SCCM) peer cache functionality we saw the opportunity to get in early on the roll out to aid us in some of our other projects (like a move to Azure and a DP removal for cost reduction).  Sarat Chandra was the man tasked to bring the idea of peer content sharing from the whiteboard to the production environment and while he had to deal with a few bumps in the road, he got us to a nice solid implementation.  That early lead also led to some fun tests as we worked with the development team to use and improve the feature to give you what you have available today.  One memorable learning from those early days was when a workstation (the workstation of our boss) served out over 3 TB of data to nearly 200,000 other machines, at the same time becoming useless for an entire day due to CPU and NIC consumption.  We also got a reminder that laptops move and while they might start the day in one office, later serving content to people in that office, when the laptop has moved to a Starbucks down the road, is not so good for making happy users and network admins.

Results today

              Much refinement has gone into both the product and our implementation of the feature to bring us to a much nicer point now.  We have it rolled out across the company and we have better reporting that is now showing that only 10-20% of our content requests are coming from our distribution points.  We did that through a combination of the ConfigMgr Peer cache functionality and the built-in OS BranchCache functionality.  We have also reduced our distribution point footprint in branch offices significantly, with a goal to completely remove them al in the next year.

              Getting this success required finding the right targeting for creating peer cache source servers.  Today we have some general targeting that works well for most locations, with some rule exceptions to handle a few remote offices that didn’t have a good result set for our peer source servers.  The combination that gave us the best success for defining a peer source was created as a collection which we then target with the appropriate client agent settings.  That combo is:

·       Not a high-level executive (We don’t want to risk any impacts to our CEO, for example)

·       Desktops only (they don’t move much and provide reliability)

·       Hardwire connection (more dependable throughput than wireless)

·       Not a VM

An example of our collection query for those that want a more direct example is:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_SYSTEM_ENCLOSURE on SMS_G_System_SYSTEM_ENCLOSURE.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER on SMS_G_System_NETWORK_ADAPTER.ResourceId = SMS_R_System.ResourceId inner join SMS_G_System_NETWORK_ADAPTER_CONFIGURATION on SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.ResourceId = SMS_R_System.ResourceId where SMS_G_System_SYSTEM_ENCLOSURE.ChassisTypes in ("3","6","4","5","7","15","16","17","23") and (SMS_G_System_NETWORK_ADAPTER.AdapterType = "Ethernet 802.3" and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1) and SMS_R_System.IsVirtualMachine = "False" and SMS_R_System.ADSiteName not in (<<<<<AD Sites you want to exclude>>>>>)

In our corporate headquarters we had many more machines to choose from for peer sourcing so we further improved content deliverability and reduced our selection set for peer source servers by also targeting only those machines with 20GB of free disk space.  This was done as an optimization to make sure we didn’t have a lot of cache churn on peer source servers.  Other locations had fewer potential targets, so we didn’t use this limitation on those locations.  Here is what the last 24hours looked like for us:



We also built custom reports to measure efficiency of Peer Content Source using rejection data that sources send based on the throttling set at the client agent settings and create an alert. This helps us track and remove Peer sources that are not efficient and help minimize content delivery delays. Below is the sample report:

Our Future:

              All this said, the ConfigMgr and OS products continue to improve, and we are looking to integrate those improvements as well.  We are about to start a pilot on the new partial download functionality that is available in the 1806 release.  We also have been really excited by what we have seen and heard about LEDbat implementation possibilities.  This new peer content process is a small change for ConfigMgr infrastructures but can be a big change in design and resiliency for your content distribution.


12/3/18 - Updated screen shots and added collection query.

12/6/18 - Query updated

Comments (5)

  1. Stefan-r says:

    Hi Mike,
    great Article!
    Did you enable this for all Desktops that match the criteria or did you limit it per site?
    And is it possible to get the custom reports?
    Thanks much,

  2. Hi Stefan,
    We did not limit on site per se. We created a general collection for all machines (desktops) that met our criteria and set them up as peer sources. For the few areas that did not have enough viable desktops (or too many) we had to make additional collections with modified rules to tweak things a little bit.

    As for the reports, unfortunately we don’t have anything in a shareable format currently. There is something very similar that is available through Microsoft Premier, titled “System Center Configuration Manager: Advanced Dashboards” I believe. If you are a premier customer I would suggest reaching out to your Technical Account Manager and they might be able to get that delivered for you.

  3. The Z-Nerd says:

    You say you’re limiting connections to hardwire and your example query includes the following:

    > (SMS_G_System_NETWORK_ADAPTER.AdapterType = “Ethernet 802.3” and SMS_G_System_NETWORK_ADAPTER_CONFIGURATION.IPEnabled = 1)

    Is this your actual query for excluding wireless, or are you doing something else by name? Because it seems like Wireless adapters would fit that criteria if it was connected over wireless.

  4. Bala R says:

    Hi Mike,
    Wonderful Article!
    We are currently running 1806 with few cloud distribution points and I am looking for a way to measure the cloud DP’s usgae like how much data been served, how many requests been served like that, seems I can make use of the report you have shown above. Would you mind sharing the logic. How it was being calculated.

    Many thanks.

    1. Bala R says:

      Hello Mike,
      It seems the view v_DPUsageSummary has the usage details only for on-prem DPs, is this normal?
      our requirement is to fetch the usage summary of the cloud DPs.

      Many thanks.

Skip to main content