SCCM 1710 and PeerCaching: Technical Notes

Executive Overview

SCCM PeerCaching was first introduced in SCCM 1610 as a pre-release feature and officially added to SCCM in 1710. PeerCaching is intended to serve as an additional option for clients to download content, mostly thinking in terms of OS Deployments to accelerate the process while taking into consideration environmental factors like network bandwidth.
In a PeerCache, there are one or more systems which host the content, and clients looking for said content will have the peer available as an additional option. There are some limitations to PeerCaching, unlike a standard distribution point running on a full Windows Server. These will be discussed later in the blog.
This document is intended to show requirements, answer questions, and show testing results. There are many “how-to” guides on the internet that walk through this. This blog can be scaled out as needed, the examples shown were a minimal configuration to demonstrate PeerCache.

Requirements/What you need

• SCCM 1610 (pre-release) or later (1710 full release)
• As a best practice, insure that the systems hosting and downloading the content are well connected. The purpose of PeerCaching is to find a local system that will allow for a faster download.
• One collection for PeerCaching systems

• This collection needs a client setting for PeerCaching. Note the enlarged cache size below as well as allowing the client to share content. The default ports are 8003 and 8004. This is configurable, but not recommended to change.

• The Windows Firewall will be automatically configured with these settings. Keep in mind that Group Policy can still override this if you disable allowing exceptions.
• The Client Cache Settings
  Important: Insure this client setting is a higher priority than other client cache settings. Use Resultant Set of Policy to insure this.
• The PeerCache Source systems also need collection variable, which configures content to be held after a Task Sequence is run. By default, content is deleted to make space after a Task Sequence as needed. The variable SMSTSPreserveContent must be set to True.
• This collection needs to be populated with systems so that they can get the downloaded content after the Task Sequence is deployed to it.

• This variable is only intended to tell clients to prefer peer downloads, when they can find them. This is for the computers booting into Windows PE or running a Task Sequence from inside Windows. The variable SMSTSPeerDownload must be set to True.
• Keep in mind that a Peer host always needs to be available, and this can be problematic with power policies as a lot of deployments happen in off-hours. In the case of self-service OS Deployments, they can happen as people leave for the day.

The key step here is of type “Download Package Content”

Note that Applications are not supported to pre-stage. In an OS Deployment, it is recommended to create a package and deploy a program for multiple reasons, but among the highlights are:

• Applications have detection rules and dependencies, OS Deployments do not need this. If you want to deploy the same app later, simply the detection rules will find the app installed (if set up correctly) and skip the reinstall.

• But wait, Packages have “Run this program first”. This is true, but also not a feature that is heavily used. It also takes server resources to process.

Setting it all up

Step 1: Follow the above to set the environment
Insure the variables are set, task sequence is created, collections made, etc.

Step 2: Test connectivity
Insure the peer host has the appropriate client settings and test the configured ports (8003, 8004 to see if they are listening). Either using the telnet client or nbtstat (good old tool that’s still part of Windows) can see if a listening port is established.

Step 3: Set up and deploy the PeerCache host:
You can set the PeerCache in one of two ways:

• Advertise / Deploy a Task Sequence to an existing Windows device which will be hosting the content (keep in mind the above requirements for the host system). To keep the PeerCache updated, I’d recommend a mandatory task sequence.
• Starting in SCCM 1710, apply detection logic to the system and run a child task sequence which copies the data as part of staging a new system for PeerCaching.

Booting it up / Test Results

When booting the Windows peer client, you will see everything work as normal, with the exception that PeerCaching is enabled.

Below is an example from my labs, these are the players:

• SCCM.stevens.family: The SCCM site server
• PC10.stevens.family: The PeerCache host
• SCRATCH10.stevens.family: The client receiving a new deployment

Test results:

• Boot into Windows PE
• Open up the command prompt and open up the SMSTS.log to view results

Filter on the FQDN (in my case stevens.family)

• Highlight on PC10, so we can see the PeerCache is being used. In this case, the PeerCache is distributing the Windows 10 MDT toolkit files to the client.
• If for some reason the PeerCache is not available, the client will wait and retry. So, if you’ve chosen to remove the PeerCache from this site, make sure to remove the variable. This could add a significant amount of time to the deployment. The setting SMSTSPeerDownload “prefers” the PeerCache system, not that it will “only” download from the PeerCache. It will look for another DP (and in another site), if it is allowed to.

Limitations of PeerCaching

There are three types of systems a client can get content from:

• A full Distribution Point running on Windows Server OS
• A Distribution Point running on a Windows Client OS (Windows 7 SP1 (Pro, Ent, Ultimate) or later required)
• A PeerCache Distribution Point can store limited content types. For example, Applications and Software Update packages are not supported at this time. If you are looking to keep this content available at a remote site, it would be best to create a Distribution Point over a PeerCache.

• Just my opinion, but I believe the reason why Software Update Packages are not supported at this time is because of the nature and complexity of this package. I have seen several scenarios that would make keeping the PeerCache updated in a timely fashion and in line with a deployment deadline unreasonable at best.

• Some will create update packages per month, and even break them down from this. They may have 3-5 years of packages and not clean them up. It’s no uncommon to see 50-75 Software Update Packages
• Automatic Deployment Rules, such as Windows Defender will have the DPs constantly updating the package.

Quick table comparing the features of different Operating Systems running a Distribution Point:

Keep in mind a Distribution Point is your best bet whenever it comes to cached and updated content delivery as it is managed directly from the SCCM console. Distribution Points on a Windows desktop OS (like 7/8/10) lack some of the server components (like Windows Deployment Services for PXE booting) and multicast. Windows Server Core doesn’t support Windows Deployment Services, but offers a much more secure and faster operating system (lacking the Windows GUI speeds things up tremendously and vastly reduces the attack space of the OS).

Rough notes that didn’t seem to fit anywhere else (or saying it again)…

• Keep in mind the PeerCache system must be continually updated as packages change. The good news is that if content has been redeployed and is already downloaded, a check is done against the package. If it already exists, it will not copy again.
• You do need to open up 2 ports for client communication, for the sake of simplicity, I would keep it at the default 8003 and 8004. You don’t want to have different sites coming up with different standards.
• You need to insure your cache is big enough to hold all the content you want to put on the Distribution Point. Disk space in the modern era is cheap, and the cache can be extended in the client settings at any time.
• The computer used as a PeerCache source should not move, as the last hardware inventory determines its availability based on what site it’s in.
• Download Package Content is a new action for the SCCM Task Sequence: it identifies packages that should be retained in PeerCache for other clients to download.
• Clients will not download any content from the Peer Source if the content is not fully downloaded. It doesn’t operate like other P2P software in that it grabs individual bits off of several systems to create a complete file.
• Clients don’t treat a PeerCache any differently than a Distribution Point when it comes to a retry. If it sees a PeerCache is down, it will stop trying to locate it and look to another source. It will first prefer the subnet, then AD Site, then boundary group sources. If multiple sources exist in any of these, a random source will be selected on the client to aid in fault tolerance. It doesn’t always pick “#1”.
• Clients will try for about 10-15 minutes or so to contact a Peer Source, and then fail to the next. Some errors (like file not found), the client will immediately fail over.
• For multiple Peer Sources, a client cannot be forced to go to a specific Peer. For load balancing, if a Peer Source is considered overloaded, it will return a error code to the client, who will then seek out another Peer or DP (this was new starting in 1702).

Congrats on making it (finally) to the end of my blog for SCCM PeerCaching.

— Easy link to my blog: http://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.