SCCM Peer Cache: When Reversing It Doesn’t Reverse It

(Note: For some reason I wrote this up in December 2017 and never published it. Maybe I forgot to add some links, but I put the work in and it seems to still be relevant. As noted in the bottom, this should have been resolved in 1802.)

Last week I had some SCCM woes with the peer cache feature, the gist of which is that application install steps during OSD would effectively stall out. Why? That was the great mystery that had me sweating overcaffinated bullets as people out in the field are notifying me and my boss that they can’t image, and of course at a time when certain important devices need to be imaged.

“Why in the world is this not working?” I asked myself. I can only presume it was the result of me enabling the feature across our organization, but there’s more to the story than that.

I know what you’re saying: “Did you freaking test it before deploying it?

Of course I did. I had spent the last few months testing BranchCache and Peer Cache in a lab setup and then in a local site. They both were working well, and I had no indications that either was causing a problem. In fact, I was able to measure noticeable improvements in application and software update delivery as a result of enabling the changes! However, I never had an issue with OSD in my lab or at the site I tested, and so I had no idea to expect it.

What I encountered in CAS.log during OSD was this on all the affected machines:

And quite a bit more than that, but this is what peer caching is supposed to do. It effectively creates a bunch of mini-DPs across your boundary group, but there’s one problem that I didn’t take into consideration, and it’s why my environment that I tested in didn’t have this problem but the problem appeared in production: we have a TON, and I mean a TON, of laptops, and those laptops are mostly in carts powered off or (hopefully) sleeping. So peer caching may not work for us.

But then why didn’t the distribution point take over? Why didn’t the client download from it? No idea, but I needed to move on, fast.

After seeing those logs (note the name of the URL has “BranchCache” in it, but it’s actually peer cache, but I didn’t know this at the time) and knowing the change I made recently, I figured I’ll just reverse the changes and it’ll be all good, right?

Thumbs Up.
We got this. We’ll just reverse the changes.

Wrong.

Well then what the hell is going on?

What the hell?

Feeling even more under the gun now that I’m completely baffled with what’s happening, I engage with Microsoft Premier support because I feel that I could keep plugging away and googling the problem to death, or I could cut to the chase and get Microsoft involved.

Microsoft gets in touch with me, and after going over all the information I sent them and looking over the logs I was noticing, the tech fairly quickly identifies the issue as being a problem with the current build of peer cache (as of 2018.11.01-ish). Apparently even though peer cache is disabled in client policy, the changes don’t actually work and the database in SCCM still contains all the super peer entries. The fix that resolved it was to delete the super peers out of the DB with these SQL query/commands:

Bam! The problem was solved. Mostly. Kind of. The tech thought OSD was working, so it must be fixed.

The problem though is that the database keeps getting full of super peer information, so it needs to be routinely cleared out, and the super per clients need to update their super peer state. So after following these two blogs, and then getting annoyed with cleaning the DB manually and updating the collection, I put together this crude script as a scheduled task to take care of it.

(Edit 20180525): To run this script, you’ll need a few prereqs:

  • PowerShell 5.1. This was tested running on that version. You can find your version by typing $PSVersionTable in a PowerShell terminal. This may work on earlier versions, but I never tested this on earlier versions.
  • SCCM Admin console installed on the machine you’ll run this from.
  • You need the SQLServer module installed. Assuming you’re on PowerShell 5.1, you can get it by just running ‘Install-Module SQLServer’, then import it in with ‘Import-SQLServer’.
  • Finally, you’ll need to adjust the script for your own local information (site code, servers, etc.)

(Edit2 20180529): After reading this over again, it might be helpful if I explain what my script does, at least a high-level. The comments in the code explains what it does at a line-by-line level. What the script below does:

  • Imports modules needed (SCCM and SQL)
  • Reads superPeers.txt and performs a SQL query to get current Super Peers, then concatenates both ingests
  • Creates a SCCM collection based on the resourceIDs that we just ingested
  • Invokes a client update notification telling the Super Peers to update their client policies
  • Keeps a list of all resourceIDs used for this process
  • Deletes the Super Peers and Super Peers mappings from the database

The basic idea is to get these various devices out there to update themselves and to clear them out of the database, otherwise other devices may try to still use them as Super Peer/mini-DP.

Next, what I’ve done is run this script in an elevated prompt, and then let it do it’s thing.

Script:

Update: As of December 2017, the issue still persisted, which might have been because the clients weren’t getting their client policies updated, so the Microsoft tech had me recreated some of the client policies and deploy them. The issue seems to have been fixed as those dang laptops start getting powered on. The tech also informed me that this behavior is resolved in SCCM 1802.

Also, I suspect that the issue was not only due to laptops becoming superpeers and not being powered on, but also because the boundary groups configured were too broad and spanned too many sites. Not the primary issue, but it definitely contributed to it.

We have continued to use BranchCache and it’s amazing how well BranchCache is working in our organization, even with a ton laptops in carts (45-53% of content source comes from BranchCache at these sites).

9 thoughts to “SCCM Peer Cache: When Reversing It Doesn’t Reverse It”

    1. You need a few components (which I guess I didn’t note, and I’ll clarify a bit).

      For one, you’ll need to have the SCCM console installed on your machine to use to import the SCCM PowerShell cmdlets (line 5, currently).

      Next, you’ll need the SQLServer PowerShell module. Assuming you’re on PowerShell 5.1, you can get it by just running ‘Install-Module SQLServer’, then import it in with ‘Import-SQLServer’.

      Finally, this assumes a single-server install (primary server and SQL on same box). If not, you’ll need to adjust it accordingly.

      Finally, you’ll need to enter your own site information and connection info (site code, servers, etc.).

      What I ended up doing was running this once, but in the end I needed to run it as a scheduled task, which my production one added tracking to determine when the peers were getting cleared out.

      Hopefully you’re migrating to 1802 soon, because that’s the real fix, and 1802 is actually running pretty smooth for us.

      Let me know if you have further questions about it.

      1. 1) SCCM console is installed on all my machines (Surface Pro 4s)
        2) The SQL bit – How and what do you mean?
        3) Yes, Single Server, Primary Server and SQL on the same box

        Can you provide some screenshots please? I’m really confused and I’m struggling with my OSDs. I build around 10-20 Surfaces a day and this peer cache is killing me.

        Thank you in advance.

        Regards

        1. > 2) The SQL bit – How and what do you mean?

          My script requires the SQLServer cmdlets. Here’s some documentation on it:

          * Doc: https://docs.microsoft.com/en-us/sql/powershell/sql-server-powershell?view=sql-server-2017
          * How to Install: https://docs.microsoft.com/en-us/sql/powershell/download-sql-server-ps-module?view=sql-server-2017
          * Info on the Module: https://www.powershellgallery.com/packages/SqlServer/21.0.17199

          > Can you provide some screenshots please? I’m really confused and I’m struggling with my OSDs. I build around 10-20 Surfaces a day and this peer cache is killing me.

          I can’t really do screenshots of my SCCM production environment right now, but if you want a quick fix, do this (*AT YOUR OWN RISK*; not liable if it breaks, which it shouldn’t, but still, have to put that disclaimer in there):

          1. Open up SQL Management Studio and login with appropriate rights to edit the DB.
          2. Right-click on your SCCM DB (should be name “CM_“, and click ‘New Query’.
          3. Then type in:
          delete from SuperPeers
          delete from SuperPeerContentMap
          4. Run query.

          That will clear the the mappings and SuperPeer listings. My script is really just doing that SQL command above, and then creating an SCCM collection to track any machines that are SuperPeers.

          On top of that, your should also replace your current Client Setting policy that relates to the peer caching feature (that disables it) with a completely newly configured policy and deployment. The idea here, from the Microsoft Premier tech, is to force the clients that are stuck being SuperPeers to get a new policy telling them that peer caching is no longer happening.

          Good luck!

  1. I have the same problem with SCCM 1802,
    OSD fail to install applications, when peers are offline and it gets content from the DP..
    It looks like the application installs but SMSAPPINSTALL.exe doesn’t know that the install was successful and needs to install the next application?
    Rolling back Peer Caching has fixed it…
    thanks for your post

    1. Yeah, I’m bit hesitant to recommend peer cache now because of the issue of laptops becoming super peers. Like you said, and what I’ve experienced, when the laptops go offline, devices still try to get data from them instead of the distribution point.

      It seems like you would need to create boundaries and/or boundary groups that don’t include laptops for this to work correctly, at least in peer caching’s current state.

      1. You rollback peer cache by turning off the setting in the client settings; i.e., just reverse what you did to enable peer caching.

        Go to console > administration > client settings > then find the client settings policy that you enabled peer cache with. Within the policy, go to client cache settings > then make sure ‘Enable Configuration Manager Client in full OS to share content’ is set to off.

Leave a Reply

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