What is allow peer downloads in this boundary group?

• #Gomez peer rig setup update

When an application is deployed and installed on the peer cache source, the Content Access service generates a state message of topic type 7200. Deploy an application to the peer cache source The following example is used to show how peer cache works during content deployment. Select the Options tab, and then enable the Allow peer downloads in this boundary group setting. Right-click the boundary group, and then select Properties. Locate the boundary group that contains the peer cache clients and peer cache sources. In the Configuration Manager console, go to the Administration workspace, and then select Hierarchy Configuration > Boundary Groups.

When the site server receives the state message, it calls the spUpdateSuperPeerStatus stored procedure to update the following tables:Ĭonfigure boundary group options for peer downloads You'll see the following entry in the MP_Relay.log file: Message Body :ġ1GUID:xxxx.1015TestClient43710331]]>8003 The state message is formatted as XML, and then sent to the management point (MP_RelayEndpoint) through CCMMessaging. State message(State ID : 2) with TopicType 7201 and TopicId Super Peer is now active has been recorded for SYSTEM The following entries are logged in StateMessage.log: Adding message with TopicType 7201 and TopicId Super Peer is now active to WMI The following entries are logged in CAS.log: SuperPeerController main thread has started.Ī state message of topic type 7201 is generated. Notifying endpoint 'SuperPeerController' of _InstanceModificationEvent settings change on object CCM_SuperPeerClientConfig.SiteSettingsKey=1 for user 'SID'. The following entries are logged in CcmExec.log: Notifying endpoint 'SuperPeerController' of 1 settings change(s). The value of the CanBeSuperPeer property is changed to True. In the WMI class instance CCM_SuperPeerClientConfig.SiteSettingsKey=1 under ROOT\ccm\Policy\Machine\ActualConfig: When the client cache setting is deployed to the device collection, you'll see the following changes on the peer cache sources: Changes on clients that act as peer cache sources When you enable clients to be peer cache sources, the management point includes them in the list of content location sources. You don't have to enable peer cache clients. In the navigation pane, select Client Cache Settings, set Enable as peer cache source to Yes, and then specify the ports.ĭeploy this custom client setting to the device collection that you created in step 1. Select Create Custom Client Device Settings, specify a name and description, and then select the Client Cache Settings group. Go to the Administration workspace, and then select the Client Settings node. Determine which clients you want to enable as peer cache sources, and add them to the collection. In the Configuration Manager console, create a device collection. To enable clients to be peer cache sources, follow these steps: For more information, see Peer cache for Configuration Manager clients. Use peer cache to help manage deployment of content to clients in remote locations. It extends traditional content deployment solutions, such as distribution points. Peer cache is a built-in solution for Microsoft Endpoint Configuration Manager that enables clients to share content with other clients directly from their local cache. Applies to: Microsoft Endpoint Configuration Manager (current branch)

One of the big issues with Peer Cache is that clients can only get content from Peer Cache sources (“Super Peers”) when the Peer Cache source has got all of the content.

Operationally, this means when you deploy something new (e.g. a critical patch) to all clients in a remote location at the same time, you expect them all to pull the content from the remote DP over the WAN.
You may have heard that Peer Cache now includes Partial download support. (introduced in CM CB 1806). It “tries to eliminate more than one download of the same content per boundary group”. So how does it actually work, and does it really address the problem?
The link above provides a good explanation of how the feature works. Here’s quick a summary on how to set it up:

1. Build a Collection of systems that you want to act as Peer Cache sources (Super Peers)
2. Defined Custom client settings enable Peer Cache and deploy this to the Peer Cache sources Collection
   
3. Define a Boundary Group for each remote location. You do this not so that it does not have a DP associated with it, but has a relationship with a neighboring Boundary Group that does have an associated DP and a fallback delay of, say 30 minutes. This is important. It’s the only thing that prevents regular clients from downloading from the DP straight away, giving the Super Peers time to get the content first.
   
   
4. Update all Application Deployment Types to allow download from neighboring Boundary Group (otherwise they will never be deployed to the remote Boundary Group)
   
5. Update or create Software Update or Program Deployments to allow download from neighboring DP (disabled by default).
6. Enable partial download for Peer Cache in Hierarchy Settings

When you do this, Peer Cache source computers (‘Super Peers’) targeted with content will download the content in blocks.

Block 1 downloads first. If another Super Peer requests the same content while the first is downloading block 1, it will start to download block 2 and so on. This can be seen observing the ContentTransferManager.log on two ‘Super Peers’:

As each Super Peer aggregates all the blocks, it updates the Management Point and then other clients in the Boundary Group can get the content from it.

10/15/2018 9:27:56 PM Download complete for all 4 blocks
10/15/2018 9:27:56 PM Reporting the download completion status to MP
However, it’s only Super Peers that can use this partial download. To prevent the other clients in the Boundary Group from just going straight to the DP while the Super Peers are doing their partial downloads, you must deprive the Boundary Group of a DP and configure a fallback delay (say 30 minutes) to a neighboring Boundary Group that has a DP. The Super Peers will ‘ignore’ the fallback delay and start downloading immediately. The other clients will wait 30 minutes then attempt the download, by which time the Super Peers should have the content.
You could just make all clients Super Peers. However, if there are more Super Peers than blocks of content (in my test, Office 2013 at just over 700MB was split into 4 blocks), Super Peer starts to download a block until there are no more blocks from the DP. The remaining Super Peers will wait for the Boundary Group to fall back interval-like the regular clients.

So how does this compare with Nomad?

• To get this set up, you have to configure or modify Boundary Groups, Client settings, Hierarchy settings, Application Deployment Type Settings, Program and Software Upgrade Deployment settings. Nomad only requires enabling Nomad in Client settings and on each Package. It doesn’t require intricate management of Boundary Groups
• This configuration forces clients to delay download of the content, based on the fallback interval defined between Boundary Groups. Every deployment to clients in those remote Boundary Groups gets delayed. Nomad starts downloading content and sharing it among other peers without delay.
• The process has no resilience built in if any of the Super Peers go offline while content is still being downloaded. You can expect peers to go back to the DP when this happens. As the Nomad master shares the content with peers as it is downloading, it can quickly recover and resume (not restart) download from another peer within two minutes of the elected master going offline.

• Peer Cache uses BITS (which is incapable of bandwidth management) to download content from the DP. You can expect to see network congestion as multiple Super Peers simultaneously download different blocks. Nomad downloads content from the DP. Only one master (either per subnet or per site if you are using Single Site Download) gets the content sequentially from the DP. Using proper bandwidth management enables them to assess and use the end-to-end available capacity. Simultaneously, it backs off when other data is being transferred.

What is the purpose of a boundary group?

What is peer caching?

How does peer cache work?

What is a boundary group in SCCM?