The strange case of Peer Cache not getting disabled

This thing bugged me for over a month now.

I enabled Peer cache on a bunch of clients (1500), then I wanted to disable it because it is better to enable it just on some clients which are always on, maybe on those subnets with a slow internet connection. This thing here, to let you understand

5

I wish I’d never done that.

After disabling the feature via client settings, a bunch of clients were not removed from the Super Peers list. How do I know that? Let’s start From the beginning…

Symptoms

Extreeemely slow OS deployement, slow applications download (Downloading stuck 0% for a while) from Software Center, or even when deploying updates.

Testing an application download which is automatically deployed to all notebooks (that I expect to be still considered in the permanent cache of the former Super Peers):

1

CAS.log reported a long download locations list before the SCCM was even considered, so the server still reports these sources as active peer cache clients.

2

DataTransferService.log then reports a bunch of errors, because the feature is disabled on clients and content can’t be reached, then the client waits a bunch of seconds and proceeds with the next download location.

3

During OS deployment I noticed that placing a computer on the same subnet as the SCCM distribution point, it is considered first in the list, so the issue is … work-arounded?

4

Causes

I didn’t understand at first if this was BranchCache or PeerCache related. I tried a lot of things: re-enabling the feature then disable it again, changed my boundaries and boundary groups so that they are managed by IP address range, removed the “Allow clients to share content[…]” from applications (which is BranchCache related).

Nothing worked, so I opened a case to Microsoft.

The engineer asked me to check this article of Umair Khan (legendary name): 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/

This is the exact case. Read it, because this is gold. Even the introduction and myth-busting about BranchCache and PeerCache is worth a read.

I proceeded in verifying everything Khan says: the setting is disabled on computers, but the site server is not aware. Apparently there’s an issue when the client sends back a state message stating “oy site server, I’m not a superpeer, remove me from the list” and this is not considered.

Verifying the WMI informations on a “guilty” computer (one of those appearing in CAS.LOG) with WMI Explorer

6

The setting is consistent with the deployed client settings. So the computer knows.

Let’s see if the client is in the “SuperPeers” table on the DB

Select * from System_DISC where Name0 like ‘ComputerName_still_in_Superpeer_list’

get the ItemKey from there, and

Select * from SuperPeers where ResourceID = ‘ItemKey’

7

8

So the client is still a SuperPeer for SCCM, and the same ResourceID also appears in SuperPeerContentMap for every application or package it is (was) able to distribute.

Select * from SuperPeerContentMap where ResourceID = ‘ItemKey’

9

So, how do we get rid of this data (which is now complete garbage, since I disabled the setting globally) ?

Solution(s)(?)

Method 1 – The nice way

I created a collection with these fake superpeer clients in it and deployed the Powershell script suggested by Khan, which will make clients repeat to the MP “Remove me from that f*&%$ng list!”

Creating the device collection: it’s brutal and I didn’t find anything more elegant, but it does its job

Select * From superpeers

Higlight the ResourceID Column, Copy

10

Paste it in Notepad++, put a comma and space at the end of each line
Create a new device Collection (copy an existing one), membership, query and do something like this:

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System where SMS_R_System.ResourceId in (PASTE_LIST_HERE) order by SMS_R_System.Name

11

It’s prettier in query design

12

Now let’s put this script in a package and deploy it to the collection.

[bool]$f = $false
$hostname = hostname

$CanBeSuperPeer = (Get-WmiObject -namespace "root\CCM\Policy\machine\actualConfig" -query "select CanbeSuperPeer from CCM_SuperPeerClientConfig").CanBeSuperPeer

if ($CanBeSuperPeer -eq $f)
{
Get-WmiObject -namespace "root\CCM\StateMsg" -query "select * from CCM_StateMsg where TopicType = 7201 and stateid = 1" | Set-WmiInstance -Arguments @{MessageSent = $f}
Write-output "Resent the CanBeSuperPeerState -> '$CanBeSuperPeer' to the MP for the client $hostname"
}

I created a package with a program inside, such as this
Command line: powershell.exe -ExecutionPolicy Bypass -File send_superpeer_state.ps1

13

Then set the deploy to repeat the action As soon as possible, or if you want every ten minutes, just to be sure.

14

With the almighty powers of Right click Tools Free (install them if you didn’t already), I sent a “Machine policy retrieval and evaluation cycle” on the collection

15

Some clients are not online. I think I’ll have to use bad manners upon them, but let’s proceed in a fashionly order.

Monitoring > Deployments, let’s see how it’s rolling

16

49 clients already run the script.
I had 138 clients in the SuperPeers table, in the beginning. Let’s see how it’s doing

17

They became 131. Not bad, let’s wait some more.

The day after the script ran on 72 clients, but I still had 120 entries in the table.

Through Right Click Tools (have you installed it yet?) i went in powershell remoting on a computer, ran the script, but even after some minutes he didn’t disappear from the table.

Alright, this isn’t doing what expected.

Method 2 – bad manners

You know, in its article Khan mentioned that, upon receiving the state message, this should happen on the database

19

Let’s do this. I don’t need any of the data in those tables, since I disabled PeerCache everywhere, so i deleted the entire content of those tables (ALWAYS DO A BACKUP FIRST!)

delete from SuperPeerContentMap

delete from SuperPeers

TADAAA

And everything started to work fine. Trying to download an application, CAS.log reported one download location (the DP) and everything going smooth.

But this didn’t end my journey through hell. Two days later, after the weekend, THEY CAME BACK FROM THE GRAVE. Well, just two clients, but that’s odd. I found these two entries in SuperPeers this morning

20

I tried to run the Powershell script from Master Khan on these two computers, with no results. The two computers are still there. So we can definitely say that there’s something awful going on with these state messages.

Microsoft, please fix this annoying s#!%

I’ll continue monitoring this thing, right now I’m just happy with this.

I’ll share some useful queries for this matter and some links, just to be nice


Queries to figure things out:

SELECT * FROM SuperPeers

select * from SuperPeerContentMap

select * from System_DISC where Netbios_Name0 like 'grbo512wxp'

select * FROM SuperPeers where ResourceID = '16777359'

select * from SuperPeerContentMap where ResourceID = '16777359'

--delete from SuperPeerContentMap

--delete from SuperPeers

SELECT * FROM SuperPeers inner join System_DISC on ResourceID=ItemKey

Troubleshooting article from Umair Khan

A request assistance by another lost soul

 

Advertisements

2 thoughts on “The strange case of Peer Cache not getting disabled

  1. Thanks for this – we’re having the same issue. Annoyingly, the main reason we’re having issues with clients trying to use SuperPeers for content is that they’re offline and won’t be online anytime soon, so they’re no exactly going to receive the remediation script either! Not happy about editing the database though. Might make it Microsoft’s problem, or just go for it.

    I curious to check – is there anywhere other than client settings that we should be looking at to ensure PeerCache is fully disabled?

    Like

    • Not that I know, the case is still in review by Microsoft support, and the last thing they did ask to me was… deleting contents from the table!
      It seems though that the issue is caused by the MP not processing the state messages correctly
      I’ll let you know when i’ll have updates!

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s