This post has been republished via RSS; it originally appeared at: Device Management in Microsoft articles.
First published on TECHNET on Oct 16, 2018The 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