There are essentially three ways that MECM clients can receive content that are deployed to them in our environment. These options are from Distribution Points (DP), Branch Cache, or Peer Cache systems. Historically, USGS clients have received content from one of over a hundred MECM Distribution Points.
Microsoft suggests an MECM environment design that leverages BranchCache and Peer Cache Systems rather than large numbers of Distribution Points for a smoother exchanged of cached content. In order to provide a more streamlined environment that better supports the needs of both our large and smaller field sites, the USGS will be implementing BranchCache on all clients in USGS starting on February 8, 2019.
The USGS MECM team has been working with sites to evaluate current Distribution Point needs. Where appropriate, distribution points have been decommissioned and Peer Cache systems are being set up to support the needs of field sites in their place. At these test sites, BranchCache has also been enabled and positive results have been observed.
- Peer Cache: A Peer Cache system serves as a mini DP that will only download content based on what it needs to patch/install on itself. This content then can be shared with others in the same boundary. A Peer Cache system can be physical or virtual that represents the most common OS in the office and gets all the applications/patches local IT staff plan to push to other systems in the environment. In field offices, the MECM team suggests a VM running on a server. While laptops are often mobile and leave the office, this VM will stay in place to act as a Peer Cache system that is always available to pull content from. Peer Cache systems will not be throttled and need to get content first in order to help others. Peer Cache systems should be part of ePatching Fast Ring Testing to insure they receive content ahead of standard systems in an environment.
- BranchCache: While a Peer Cache system is a defined source of content (like a DP), BranchCache is more like borrowing content from your neighbor. If a computer needs a patch it will download the content to its local Cache before it begins to install it. BranchCache allows a computer to look at all the other BranchCache systems in the boundary group to see if the content can be found locally before reaching out over the WAN to download a copy from a remote distribution point. Once the first system downloads the needed content into the boundary, it can now act as a BranchCache source for other systems in the boundary group. If a site has a Peer Cache system, it will look for content on the Peer Cache system before looking for BranchCache content, and as a third option will reach out to the WAN to download a copy from a remote distribution point.
How to Set up BranchCache:
As of February 8, 2019, Branch Cache is enabled on all systems in MECM. Additionally, the “DI – SCCM Branch and Peer System Firewall Rules” GPO was linked to the domain to allow firewall rules for Branch and Peer communication.
How To Set up a Peer Cache system at a site:
A Peer Cache system can be set up as a Physical or Virtual machine in a boundary group. A Peer Cache system will use up to 50% of its disk space for Cached content. A Peer Cache system should have at least 100 gigs of free space. The Peer cache system can be a common use workstation at the site as long as disk space can be used for cache and it represents the Operating Systems of the boundary.
- Create a MECM Device collection to hold the Peer Cache system(s) for the boundaries for the local managed sites. Use the naming convention of GS-Center – Peer Cache Systems (ex. GS-CaribbeanFlorida-W – Peer Cache Systems)
- Add the Peer Cache system as a direct member to the collection.
- Add the Peer Cache system to ePatching Fast Ring Testing
- Send an email to servicedesk@usgs.gov to work with the MECM team to have a Peer Cache system setup for a boundary group
What is pre-seeding content on a BranchCache or Peer Cache system?:
In the case of full Distribution Points, content is distributed to all DPs before any deployment actions are taken. This assured that content is available at the time of deployment. This pre-seeding concept needs to also be applied for BranchCache and Peer Cache environments. By making a Peer Cache system or a subset of systems at a field site members of the ePatching Fast Ring testing process, they will receive monthly patch downloads a week before content is distributed to the standard patching group. This means these computers will have the needed cache to share with others in the boundary. Local IT should also leverage this in any local deployments sent to remote offices using BranchCache and Peer Cache. If a local IT person plans on pushing an application or a Windows 10 Feature update Task Sequence in MECM to a remote site, they should first deploy the application to the systems that are part of Fast Ring testing for that site (either Peer Cache collection or collection of Fast Ring test systems). This will allow content to be pre-seeded in the boundary so that when the future deployment is done for the remainder of the system, cached content will be locally available. Please remember relevance as a system will only cache what is relevant. If your Fast Ring testing systems do not represent the OS of other devices in the boundary, than the first computer that needs content and can not find it locally will reach out to a remote DP for content.
How to Check the Log files of a Client to see where it is getting content from:
The local CAS.log file on systems can be used to determine what source a client is pulling cached content from. The file will either reference a BrachCache client, a Peer Cache system or a local or report Distribution Point. This data can be helpful in understanding cache data flow in an environment.
- Open the C:\Windows\CCM\Logs\CAS.log file using CMTrace
- The log files will reference the source location of downloaded content. They may point to BranchCache systems within the boundary, the Peer Cache system, or local or remote Distribution Points.
Location update from CTM for content 9fe808a6-f89b-4e76-8453-5d07cf3719f5.1 and request {2D60C487-9B6B-4189-A662-3330C0E5536F} ContentAccess 12/19/2018 2:39:35 AM 6476 (0x194C)
Matching DP location found 0 – https://igsbafewvm005.gs.doi.net:8003/sccm_branchcache$/9fe808a6-f89b-4e76-8453-5d07cf3719f5 (Locality: SUBNETPEER) ContentAccess 12/19/2018 2:39:35 AM 6476 (0x194C)
Matching DP location found 1 – http://igsbameiascmdp1.gs.doi.net/sms_dp_smspkg$/9fe808a6-f89b-4e76-8453-5d07cf3719f5 (Locality: BOUNDARYGROUP) ContentAccess 12/19/2018 2:39:35 AM 6476 (0x194C)
Matching DP location found 2 – http://igsbameiascmdp1.gs.doi.net/nocert_sms_dp_smspkg$/9fe808a6-f89b-4e76-8453-5d07cf3719f5 (Locality: BOUNDARYGROUP) ContentAccess 12/19/2018 2:39:35 AM 6476 (0x194C)
How to Monitor the Client Data Sources in MECM:
System Center Configuration Manager Console allows MECM IT to monitor the source of client data for each boundary group.
- Open the MECM Console and navigate to \Monitoring\Overview\Distribution Status\Client Data Sources
- Select a Report Period to monitor
- Select a Boundary Group to Monitor
The report will display statistics about which systems in the boundary received content from Distribution Points, BranchCache and Peer Cache systems.
For field sites that do not have a local Distribution Point, content distributed by BranchCache and Peer Cache systems will represent local LAN traffic rather than content being pulled from a remote DP over the WAN.
