I am back with the unexplained series. Today being the discussion on the new feature called Client Peer Cache introduced in ConfigMgr 1610. Even though the issue in the blog talks about Client Peer Cache still in use when disabled, We will first try to understand the background and some semantics of the new feature. The Official Microsoft documentation on this can be obtained here: https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/client-peer-cache
First of all if you don’t know it already, Peer cache is not Branch cache. Peer cache was newly introduced concept from ConfigMgr where the client can get the content from its peers (need not be in the same subnet like in branch cache).
Just giving some perspective on how it gets enabled. It’s a Pre-Release feature so first enable it from Updates and Servicing.
Then for the clients to use this feature, set it via the Client Settings. Note only the highlighted settings refer to the Client Peer Cache.
At this point it would be awesome to bust some myth and get more on how Client Peer Cache and Branch Cache differ.
- Peer Cache is 100% SCCM technology
- BranchCache (BC) is 100% Windows technology
- Peer Cache and BC can run together and complement each other no need to choose one or another
- BC is an older feature of Windows been there for many years but it is hard to monitor, troubleshoot
- BC works in broadcast messages, so it can only stay in a subnet
- Peer Cache doesn’t use broadcast it asks Management Point (MP) for the best location to get the content and MP tells the peer which Peer Cache Source has the content the peer is looking for. This means it can cross subnets (imagine a branch office which has multiple network subnets)
- Peer Cache and BC both have Client Data Sources Dashboard in SCCM that tells a lot of information about where data is coming from per boundary group.
- Peer Cache uses SCCM client cache location and BC uses its own cache, they don’t share cache locations.
- When used together and the content is available on both a BC client and also a peer cache source on the same boundary group, usually BC wins since before peer goes ahead and tries to pull the content from the list that MP provided to it, it does a broadcast (given the BC is enabled on that peer) and if it finds the content (or parts of the content) it can pull the content.
- BranchCache offers de-duplication (no need to transfer blocks of data that match those already in the cache). (I assume, but have not verified, that Peer Cache will download the entire package again even if just a single file changed.)
- BranchCache can share partial content chunks (caching starts before the complete content has been downloaded), while Peer Cache needs to have the full package content before it can be shared.
Now that’s some good background to know, Lets move on to the FAQ section to explore the feature more.
- How does it look on the client or where does it reside on the Client WMI to verify if the Peer Cache is enabled?
In this the Property CanBeSuperPeer would be TRUE.
The client component CLientAccessService (CAS.log) raises State Message Topic Type:7201 StateID = 2 ("Super Peer is now active") via StateMessage.
Upon receiving this state message on Site server : topic type :7201 State ID: 2, we call [spUpdateSuperPeerStatus]
Which goes in
And Upserts SuperPeers and SuperPeerContentMap tables
- How does the Cache content location is updated on the site server once a new Package is updated in Client CCM cache?
On a Cache Add or remove. The CAS component will simply raise State Message Topic Type:7200 StateID = 1 ("Cache Add") or StateID = 2 (Cache Delete) via StateMessage.
Sample Cache Add message:
Upon receiving this state message we call[spUpdateSuperPeerCachedContentMap]which will Upsert for an Add event and Delete for a Cache remove event.
- What happens when you then edit the Client Policy to configure it to not use ClientPeerCache ?
As you guessed,
In this the Property CanBeSuperPeer would be set to FALSE.
CAS.log then gets a CSuperPeerController::OnClientConfigChange() and once it finds the Property is set to false then logs
And raises State Message Topic Type:7201 StateID = 1 (Remove all cached content for this superpeer)
Sample State Message for removal:
Upon receiving this state message on Site server : topic type :7201 State ID: 1, we call [spUpdateSuperPeerStatus]
Which goes in
So that’s how the records are removed from the system.
- Now coming to the final question of I have disabled the same but the Clients are still searching for PeerCache. Why?
Sample Error Message
E.g: Out of 300 clients, 30 are still using Peer cache.
You will find the records are still there in the SuperPeers and SuperPeerContentMap for the ones which are still using PeerCache.
First verify in the Client WMI and you will see that the CanBeSuperPeer is FALSE. (If it is true you know it is Policy application issue) And you can actually verify the 7201 State ID: 1 message was indeed sent.
At this point we can confirm this as a State Message issue.
Very simple to create collection from resourceIDs in SuperPeers and then may be ask them to resend the removal state message.
A sample PowerShell that can be deployed via ConfigMgr to this collection.
Track the progress now and with the given internals info you should be able to trace it now. As and when the state messages are received the records will be getting deleted.
Hope it helps!
Support Escalation Engineer | Microsoft System Center Configuration Manager
Disclaimer: This posting is provided “AS IS” with no warranties and confers no rights.