Boost Configuration Manager Performance: Implement Peer Cache for Faster Client Updates

Table of Contents

Effectively managing content deployment is a cornerstone of any successful IT infrastructure, especially in distributed environments. Microsoft Endpoint Configuration Manager provides robust solutions for this, with Distribution Points being the traditional method. However, relying solely on Distribution Points can strain network bandwidth, particularly when deploying large updates or applications to numerous clients in remote locations or branch offices.

To alleviate these challenges and accelerate content delivery, Configuration Manager offers a powerful built-in feature called Peer Cache. This solution allows clients to share content directly from their local cache with other clients within the same network boundary. By leveraging the collective resources of local machines, Peer Cache significantly reduces the need for every client to download content from a Distribution Point, leading to faster updates and reduced wide area network (WAN) traffic.

Understanding Peer Cache in Configuration Manager¶

Peer Cache is designed to enhance and extend your existing content infrastructure. It doesn’t replace Distribution Points but works in conjunction with them. Think of Peer Cache sources as temporary, dynamic mini-Distribution Points that are client machines themselves. When a client needs content, it first checks with its peers configured as sources within its boundary group. If a peer has the content, the client can download it directly from that peer over the local network.

This approach is particularly beneficial in scenarios where you have many clients in a location with limited bandwidth back to the main Distribution Point or site server. Instead of all clients pulling the content across the slow link, only a few designated peer sources need to fetch it from the DP (or potentially another peer), and then they can serve it to all other clients locally. This dramatically speeds up deployment times and frees up valuable WAN bandwidth for other business-critical traffic.

Peer Cache utilizes standard HTTP or HTTPS protocols for content transfer between peers and clients. It integrates seamlessly with Configuration Manager’s content library and client cache mechanisms. While it shares some conceptual similarities with BranchCache, Peer Cache is a distinct Configuration Manager feature, managed and configured entirely within the Configuration Manager console and its client settings.

Configuring Clients as Peer Cache Sources¶

The first step in implementing Peer Cache is to identify and configure which client machines will act as content sources for their peers. Not every client needs to be a source; you should select machines that are reliably online, have sufficient disk space for the cache, and possess reasonable network connectivity within their local subnet or boundary group.

The process involves creating a custom client settings policy and deploying it to a collection of machines designated as peer cache sources.

Step 1: Identify and Group Potential Sources¶

Before creating the settings, you need to decide which computers will serve as peer cache sources. These should ideally be stable machines, perhaps desktop computers that are rarely turned off, or even servers (if appropriate for your environment and licensing). Avoid selecting laptops that are frequently disconnected or machines with limited disk space.

Create a device collection in the Configuration Manager console that includes these specific clients. You can populate this collection manually or use query-based rules to automate membership based on criteria like operating system type, location, or hardware specifications. This collection will be the target for your custom client settings.

Step 2: Create Custom Client Settings¶

Navigate to the Administration workspace in the Configuration Manager console, expand Site Configuration, and select the Client Settings node. Here, you will create a new custom device setting to configure the peer cache functionality.

Right-click on Client Settings and select Create Custom Client Device Settings. Give your custom settings a descriptive name, such as “Peer Cache Sources Configuration” or similar. This helps identify the purpose of the settings later. In the list of available setting groups, ensure that Client Cache Settings is selected.

Step 3: Configure Client Cache Settings for Sources¶

Once the custom settings object is created, edit it. In the left-hand navigation pane of the settings editor, select Client Cache Settings. Here you will find the specific options for configuring the client cache and enabling peer cache capabilities.

The key setting here is Enable as peer cache source. Change its value from “No” (the default) to Yes. When you enable this setting, you will also need to configure the ports that clients will use to communicate with these peer sources. Configuration Manager automatically suggests default ports: 8003 for HTTP and 8004 for HTTPS. You should verify that these ports are open in your firewall on the peer cache source machines and any intervening network devices between the peers and the clients that will download from them. Using HTTPS (port 8004) is recommended for security, provided you have a proper PKI infrastructure or enhanced HTTP configured.

Consider configuring other client cache settings within this policy specifically for your peer sources. For example, you might allocate a larger cache size for these machines compared to standard clients, as they will be storing and serving content for others. Set the Configure client cache size appropriately, perhaps as a percentage of disk space or a fixed size in MB.

Step 4: Deploy the Settings¶

After configuring the client cache settings, click OK to save the custom settings object. The final step is to deploy these settings to the device collection you created in Step 1. Right-click on the custom settings object you just created and select Deploy. Choose the collection containing your designated peer cache sources as the target.

Once deployed, clients in the target collection will download the new policy based on their policy polling interval. Upon receiving the policy, they will configure themselves as peer cache sources, open the specified firewall ports, and begin registering their available content with the Management Point. It is not necessary to enable peer cache functionality on the clients that will download from peers; this capability is controlled by boundary group options.

The Mechanics: What Happens Under the Hood¶

Enabling clients as peer cache sources triggers several processes and changes within the Configuration Manager hierarchy. Understanding these internal workings helps in verifying configuration and troubleshooting issues.

Changes on Peer Cache Source Clients¶

When the custom client settings policy is applied, the Configuration Manager client on the designated machine makes internal configuration changes. A significant change occurs in the client’s WMI repository. Specifically, in the ROOT\ccm\Policy\Machine\ActualConfig namespace, the CCM_SuperPeerClientConfig.SiteSettingsKey=1 instance is updated. The CanBeSuperPeer property for this instance is set to True. This WMI change signals to the various client components that the machine is now designated as a peer cache source.

You can observe this change in the client logs. The CcmExec.log will show entries indicating that the ‘SuperPeerController’ endpoint is being notified of settings changes, reflecting the WMI update. The Content Access Service (CAS), which manages the client’s cache, initializes its peer cache components. The CAS.log will contain entries like “SuperPeerController main thread has started.”

Finally, the client generates a state message to inform the Configuration Manager site about its new status as a peer cache source. This state message has a TopicType of 7201 and a TopicId indicating “Super Peer is now active”. The StateMessage.log records the generation and recording of this message, ready for sending to the Management Point. This state message is crucial because it registers the client’s capability as a peer source with the site.

Communication with the Management Point¶

The state message generated by the peer cache source client is sent to its assigned Management Point using the CCMMessaging component. This message contains information about the client, including its unique GUID, version, NetBIOS name, and crucially, its current status and potentially a list of content already present in its cache that it can share.

The Management Point receives this state message via its MP_RelayEndpoint. The MP_Relay.log file on the Management Point will log the reception and processing of this message, often showing the raw XML content of the state message. This XML contains details confirming the client’s identity and its active status as a peer.

Database Updates¶

Upon receiving the state message from the peer cache source, the Management Point forwards the information to the site server. The site server processes the state message and updates the Configuration Manager site database. The primary mechanism for this update is the execution of a stored procedure, typically spUpdateSuperPeerStatus.

This stored procedure updates specific tables in the site database that are used to track peer cache sources and the content they hold. The key tables involved are SuperPeers and SuperPeerContentMap. The SuperPeers table lists all clients currently registered as active peer cache sources. The SuperPeerContentMap table links these peer sources to the specific content packages and versions that they have stored in their local cache and are available to share. This database information is what the Management Point consults when a client requests a content location, allowing it to include peer sources in the list of available download locations.

Integrating Peer Cache with Boundary Groups¶

Boundary groups play a vital role in Configuration Manager content location. They define network locations (based on IP subnets, Active Directory site names, IP address ranges, etc.) and control which Distribution Points and State Migration Points clients in those locations can use. To enable clients to leverage peer cache sources, you must configure the boundary groups associated with those clients and the peer sources.

The configuration for allowing peer downloads is made directly on the boundary group properties.

Navigate to the Administration workspace, expand Hierarchy Configuration, and select Boundary Groups. Identify the boundary group (or groups) that encompass the network locations where your peer cache clients and peer cache sources reside. For peer cache to work between clients, both the client needing content and the peer source must typically be members of the same boundary group.

Right-click on the relevant boundary group and select Properties. Within the boundary group properties window, navigate to the Options tab. This tab contains various settings that influence client behavior within the boundary group, including content location.

On the Options tab, you will find the setting Allow peer downloads in this boundary group. Enable this setting by checking the box. This single setting tells clients within this boundary group that they are permitted to attempt downloading content directly from other clients in the same group that are configured as peer cache sources.

Enabling this option changes the order in which clients search for content locations. When a client in this boundary group requests content location information from the Management Point, the MP includes both Distribution Points and available peer cache sources in the list it returns. The client’s Content Location Service and Data Transfer Service are then instructed to prioritize attempting downloads from the peer sources listed before attempting to download from traditional Distribution Points. This prioritization is key to offloading traffic from DPs and WAN links.

You can further refine content location behavior using the Relationships tab on the boundary group, defining fallback relationships to other boundary groups or allowing fallback to site default boundary group content locations. This ensures that if a peer source is unavailable or doesn’t have the required content, the client can still obtain it from a Distribution Point.

Example Scenario: Content Delivery Walkthrough¶

Let’s walk through a typical scenario to illustrate how Peer Cache facilitates content delivery. Imagine you have a branch office with several client machines, some designated as peer cache sources, all within a single Configuration Manager boundary group. You deploy a large application to all machines in this branch office.

Deploy an Application to the Peer Cache Source¶

First, the application deployment policy reaches the machines designated as peer cache sources. These machines download the application content from their assigned Distribution Point (or another available source). Once the content download is complete and potentially installed, the Content Access Service on the peer source machine updates its local cache information.

The peer source client then generates another state message, this time with a TopicType of 7200, indicating a cache event, specifically the addition of a new content package (TopicId will include the package ID and version, e.g., “Cache add CAS00015.1”). The StateMessage.log on the client confirms this event.

This state message is sent to the Management Point and subsequently processed by the site server. The spUpdateSuperPeerStatus stored procedure (or a similar process) updates the SuperPeerContentMap table in the site database. This table now records that this specific peer cache source client possesses the content package CAS00015 version 1.

Deploy an Application to the Peer Cache Client¶

Now, the application deployment policy reaches the other clients in the branch office, which are not designated as peer cache sources but are in the same boundary group. When a client needs the content (e.g., for a required installation), its Location Services component initiates a content location request to the Management Point.

The request sent by the client is detailed in the LocationServices.log. It includes information about the required package ID and version, the client’s assigned site, its location information (IP addresses, boundary group IDs), and flags indicating its capabilities, including AllowSuperPeer="1".

The Management Point receives this request. Because the client is in a boundary group where “Allow peer downloads” is enabled, the MP consults the SuperPeerContentMap table in the database in addition to its information about available Distribution Points. The MP identifies which peer cache sources in the client’s boundary group (or related boundary groups via relationships) have the requested content.

The Management Point constructs a response containing a list of potential content locations. This list includes the traditional Distribution Points accessible to the client and the identified peer cache sources. The LocationServices.log on the client will show this list, distinguishing between locations by their Locality. A peer cache source will be listed with Locality='SUBNETPEER', while a traditional DP might show Locality='SUBNET', Locality='BOUNDARYGROUP', Locality='REMOTE', etc. The peer source location URL will typically use the configured peer cache port (e.g., https://TestClient.Contoso.Com:8003/SCCM_BranchCache$/CAS00015).

The client’s ContentTransferManager component receives this list of locations. The ContentTransferManager.log confirms the locations received, listing them with their respective Locality types.

The DataTransferService component on the client is responsible for the actual download. Because “Allow peer downloads” is enabled on the boundary group, the DataTransferService prioritizes the locations. It will attempt to download the content from a source with Locality='SUBNETPEER' first. If a peer source is available, has the content, and is responsive, the client will download the content directly from that peer over the local network. This download is typically much faster than pulling the content from a remote Distribution Point.

If the peer source is unavailable, doesn’t respond, or the download fails, the DataTransferService automatically falls back to the next location in the list, which will typically be a Distribution Point specified in the boundary group or a related boundary group, ensuring the client eventually gets the content. This prioritization is logged in DataTransferService.log, showing the client attempting the ‘SUBNETPEER’ location first.

Here’s a conceptual diagram of the process:

mermaid graph TD A[Client Needs Content] --> B{Location Request to MP}; B --> C[Management Point]; C --> D{MP Checks DB<br/>(SuperPeers, SuperPeerContentMap)}; D --> E[MP Consults Boundary Group Config]; E --> F{MP Sends Location List<br/>(Peers + DPs)}; F --> G[Client Receives Location List]; G --> H{Client (DataTransferService)<br/>Prioritizes SUBNETPEER}; H -- Attempt Download --> I[Peer Cache Source]; I -- Content Delivered Locally --> J[Client Installs Content]; H -- Peer Unavailable/Failed --> K[Traditional Distribution Point]; K -- Content Delivered (Fallback) --> J;

This flow illustrates how the Management Point acts as a central broker, providing the client with a list of potential sources, and the client intelligently attempts to use the most efficient source (the peer) first before falling back to the traditional DP.

Troubleshooting Common Peer Cache Issues¶

Implementing Peer Cache is generally straightforward, but like any distributed system, issues can arise. Knowing where to look for clues is essential.

• Clients not enabled as sources: Verify the custom client settings deployment targeted the correct collection. Check PolicyAgent.log on the source client to confirm policy receipt and application. Check the WMI class CCM_SuperPeerClientConfig on the client using wbemtest.exe to ensure CanBeSuperPeer is True. Check CcmExec.log and CAS.log for startup messages related to the SuperPeerController.
• Peer sources not appearing in location lists: Ensure the state message (TopicType 7201) from the peer source is reaching the Management Point and being processed. Check StateMessage.log on the client and MP_Relay.log on the MP. Verify the SuperPeers and SuperPeerContentMap tables in the site database are being updated (requires SQL access).
• Clients not attempting peer downloads: Confirm that the “Allow peer downloads in this boundary group” option is enabled on the correct boundary group(s). Check LocationServices.log on the client to see if Locality='SUBNETPEER' locations are included in the list from the MP.
• Peer downloads fail: Check firewall configurations on both the peer source and the client; the specified peer cache ports (8003/8004) must be open for inbound connections on the source and outbound on the client. Check DataTransferService.log on the client for specific error codes during the download attempt from the peer location. Verify the peer source is online and the CCMExec service is running. Ensure the peer source has enough free disk space in its cache.
• Content not available on peer source: Even if enabled as a source, a peer can only serve content it has successfully downloaded and cached. Verify that the content was successfully deployed and installed on the peer source machine. Check CAS.log on the peer source to confirm the content is in its cache.

Analyzing log files on both the client requesting content (LocationServices.log, ContentTransferManager.log, DataTransferService.log) and the potential peer source (CAS.log, CcmExec.log, StateMessage.log), as well as logs on the Management Point (MP_Relay.log) and site server, is key to diagnosing most issues.

Best Practices for Implementing Peer Cache¶

To maximize the benefits of Peer Cache and ensure a smooth deployment experience, consider the following best practices:

• Strategic Source Selection: Choose peer cache sources carefully. Machines that are reliably powered on, have stable network connections, and adequate disk space are ideal. Distribute sources geographically or logically within boundary groups to ensure coverage.
• Appropriate Cache Size: Configure a generous cache size for your peer cache sources. Since they will be serving content to multiple clients, they need sufficient space to store various packages. Monitor cache usage to ensure it’s not consistently full.
• Firewall Planning: Carefully plan and implement firewall rules to allow communication on the configured peer cache ports between clients and peer sources within boundary groups. This is a common configuration hurdle.
• Boundary Group Design: Ensure your boundary group design accurately reflects your network topology. Correct boundary group membership is essential for clients to receive the correct location information, including peer sources.
• Monitoring: Monitor the effectiveness of Peer Cache by reviewing Configuration Manager reports related to content distribution. Look for data showing clients downloading content from peer sources instead of DPs. Monitor network traffic at branch locations to see the reduction in WAN utilization during deployments.
• Pilot Deployment: Before deploying Peer Cache widely, implement it in a pilot boundary group to test its functionality and measure its impact in a controlled environment.

Limitations and Considerations¶

While Peer Cache offers significant advantages, it’s important to be aware of its limitations and considerations:

• Source Availability: Peer Cache relies on the availability of the peer source machines. If a designated source is offline, disconnected, or its CCMExec service is stopped, it cannot serve content.
• Resource Usage: Peer sources will use local resources (CPU, disk I/O, network bandwidth) when serving content to peers. While typically manageable on modern hardware, consider the potential impact, especially on older or less powerful machines.
• Not a DP Replacement: Peer Cache is an enhancement to your content distribution strategy, not a replacement for Distribution Points. DPs remain the authoritative source for content distribution and are necessary as a fallback.
• Complexity: In very complex or rapidly changing network environments with highly mobile users, managing peer source collections and boundary groups might require more administrative overhead.

By carefully planning your implementation, selecting appropriate sources, and correctly configuring boundary groups and client settings, you can effectively leverage Configuration Manager’s Peer Cache to optimize content delivery, improve deployment speed, and conserve network bandwidth across your organization.

Let’s Discuss¶

Implementing Peer Cache can significantly enhance your Configuration Manager environment. What are your experiences with Peer Cache? Do you have any tips or challenges you’ve encountered during configuration or troubleshooting? Share your thoughts in the comments below!