ConfigMgr 1702: The case of unexplained – Client Peer cache not getting disabled even after disabling it via Client Settings

This post has been republished via RSS; it originally appeared at: Configuration Manager Archive articles.

First published on TECHNET on Jun 12, 2017

https://blogs.technet.microsoft.com/umairkhan/2017/06/12/configmgr-1702-the-case-of-unexplained-client-peer-cache-not-getting-disabled-even-after-disabling-it-via-client-settings/

 

Hi Folks,

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.

  1. Peer Cache is 100% SCCM technology
  2. BranchCache (BC) is 100% Windows technology
  3. Peer Cache and BC can run together and complement each other no need to choose one or another
  4. BC is an older feature of Windows been there for many years but it is hard to monitor, troubleshoot
  5. BC works in broadcast messages, so it can only stay in a subnet
  6. 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)
  7. 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.
  8. Peer Cache uses SCCM client cache location and BC uses its own cache, they don’t share cache locations.
  9. 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.
  10. 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.)
  11. 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.

 

1. How does it look on the client or where does it reside on the Client WMI to verify if the Peer Cache is enabled?

 root\CCM\Policy\machine\actualConfig --->CCM_SuperPeerClientConfig

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

 

ELSEIF (@UpdateType = 2) --STATE_STATEID_SUPER_PEER_ACTIVE

And Upserts SuperPeers and SuperPeerContentMap tables


2. 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:

 1: instance of CCM_StateMsg
   2: {
   3:       Criticality = 0;
   4:       MessageSent = TRUE;
   5:       MessageTime = "20170519155508.323000+000";
   6:       ParamCount = 3;
   7:       Priority = 1;
   8:       Reserved1 = NULL;
   9:       Reserved2 = NULL;
  10:       Reserved3 = NULL;
  11:       StateDetails = "";
  12:       StateDetailsType = 0;
  13:       StateID = 1;
  14:       TopicID = "Cache add CAS00003.4";
  15:       TopicIDType = 0;
  16:       TopicType = 7200;
  17:       User = "";
  18:       UserFlags = 0;
  19:       UserParameters = {"4", "CAS00003", "8003"};
  20:       UserSID = "";
  21: };

 

Upon receiving this state message we call[spUpdateSuperPeerCachedContentMap]which will Upsert for an Add event and Delete for a Cache remove event.


3. What happens when you then edit the Client Policy to configure it to not use ClientPeerCache ?

As you guessed,

root\CCM\Policy\machine\actualConfig --->CCM_SuperPeerClientConfig

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

 

The client is not allowed to be a superpeer. Will stop superpeer controller

And  raises State Message Topic Type: 7201 StateID = 1 ( Remove all cached content for this superpeer )

Sample  State Message for removal:


   1: instance of CCM_StateMsg
   2: {
   3:       Criticality = 0;
   4:       MessageSent = TRUE;
   5:       MessageTime = "20170519174311.337000+000";
   6:       ParamCount = 1;
   7:       Priority = 1;
   8:       Reserved1 = NULL;
   9:       Reserved2 = NULL;
  10:       Reserved3 = NULL;
  11:       StateDetails = "";
  12:       StateDetailsType = 0;
  13:       StateID = 1;
  14:       TopicID = "Remove all cached content for this superpeer";
  15:       TopicIDType = 0;
  16:       TopicType = 7201;
  17:       User = "";
  18:       UserFlags = 0;
  19:       UserParameters = {"8003"};
  20:       UserSID = "";
  21: };

 

 

Upon receiving this state message on Site server : topic type : 7201 State ID: 1, we call [spUpdateSuperPeerStatus] Which goes in

 


   1: IF (@UpdateType= 1) --STATE_STATEID_SUPER_PEER_DEACTIVATED  
   2:       BEGIN  
   3:   
   4:         -- SP is no longer serving content, remove its rows from SuperPeerContentMap  
   5:         DELETEFROM SuperPeerContentMap WHERE ResourceID=@ResourceID; 
   6:   
   7:         -- Also remove from SuperPeers 
   8:         DELETEFROM SuperPeers WHERE ResourceID=@ResourceID; 


So that’s how the records are removed from the system.


4. Now coming to the final question of I have disabled the same but the Clients are still searching for PeerCache. Why?

 

Sample Error Message

 


[CCMHTTP] ERROR: URL=[CCMHTTP] ERROR: URL=http://ComputerName.domainname.com:8003/SCCM_BranchCache$/Content_88c0ad2e-83db-4221-88de-6e4b68631adc, Port=80, Options=480, Code=12007, Text=ERROR_WINHTTP_NAME_NOT_RESOLVED

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.

 

 


   1: [bool]$f = $false
   2: $hostname = hostname
   3:  
   4: $CanBeSuperPeer = (Get-WmiObject -namespace "root\CCM\Policy\machine\actualConfig" -query "select CanbeSuperPeer from CCM_SuperPeerClientConfig").CanBeSuperPeer
   5:  
   6: if ($CanBeSuperPeer -eq $f)
   7: {
   8:   Get-WmiObject -namespace "root\CCM\StateMsg" -query "select * from CCM_StateMsg where TopicType = 7201 and stateid = 1" | Set-WmiInstance -Arguments @{MessageSent = $f}
   9:   Write-output "Resent the CanBeSuperPeerState ->  '$CanBeSuperPeer' to the MP for the client $hostname"
  10: }

 

 

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!

 

~UK

Support Escalation Engineer | Microsoft System Center Configuration Manager

Disclaimer: This posting is provided “AS IS” with no warranties and confers no rights.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.