SCCM 1710 and PeerCaching: Technical Notes

Executive Overview

SCCM peer cache was first introduced in SCCM 1610 as a pre-release feature and fully released in 1710. One thing to stop and mention is what a pre-release feature really is. Pre-release features are supported working versions that can be installed in production, however, they are still being developed and more functionality is being added.

Peer Cache 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 peer cache, 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 peer cache, unlike a standard distribution point running on a full Windows Server. These will be discussed later in the blog.

This blog 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 peer cache.

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 the peer cache is to find a local system that will allow for a faster download.
• One collection for peer cache systems
  • This collection needs a client setting for peer cache. 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 peer cache 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.

Insure that the Network Access Account can log into the peer cache system if it is running in Windows PE. If running inside Windows, insure the domain joined computer account can log into the peer cache system. It should also be noted that the Network Access Account is no longer needed for the full OS.

One collection for the systems who will be receiving the content

• 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.

One task sequence for the systems who will be storing the content. You can also set the Collection Variable in the TS here, but best to do it at the collection level.

• I mentioned "scaling out" earlier. Keep in mind you can use this same task sequence to build more peer cache sources from other peer cache sources. You do need to insure all the content is downloaded to the first peer cache source. Keep in mind the peer cache source won't distribute content until it is fully downloaded.

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

Again, note the key step is Download Package Content. Let me step back for a minute and explain what this means, as it isn't really clear as to how other types of content works, like Applications and Software Updates. Hopefully we can demystify this a bit:

Peer Cache isn't a Distribution Point, and doesn't work the same. You can download package content to the Peer Cache, but to deploy applications and software updates, the following has to happen:

• Software has to be installed on the peer cache source. Why? This will download it to the client cache for storage later.

  • This means you are limited to a single deployment type. If you are say, deploying to both Windows 10 and Windows 7 and have different deployment types, you would need different peer cache sources to deploy to.
  • One way to make this more bearable in your OS Deployment is to use packages and not applications to deploy. I really like the application model otherwise, so it's not something I would personally recommend in the full OS.

• Some notes here:

• Software Updates work the same way. They need to be installed on the peer cache source. This could potentially be a nightmare, why?

  Scenario: You deploy both Windows 10 1703 in production and 1709 in test. You would need 2 peer cache hosts to deploy updates, as updates are not the same between 1703 and 1709.

• Taking updates a step further, you would also need to make sure the same apps for patching are available. So, if you have Office 2016 in peer cache, but Office 2013 on systems, expect them to find a DP.

• For the sake of software updates, and I have not tested this theory, MDT's "Install Software Updates Offline" may be a bit of a repreieve in a OS Deployment. Keep in mind these are Windows updates only and require a package, so the "Copy Package Content step" will assist in this. I can't see the MDT step working in a full OS, however. Maybe at some point, I'll test this and report back.

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 peer cache host:
You can set the peer cache 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 peer cache 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 peer cache.

Booting it up / Test Results

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

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

• SCCM.stevens.family: The SCCM site server
• PC10.stevens.family: The peer cache 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 peer cache is being used. In this case, the peer cache is distributing the Windows 10 MDT toolkit files to the client.
• If for some reason the peer cache is not available, the client will wait and retry. So, if you’ve chosen to remove the peer cache 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 peer cache system, not that it will “only” download from the peer cache. It will look for another DP (and in another site), if it is allowed to.

Different ways of getting content

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 peer cache host can store limited content types via the "Download Package Content" step. It would be nice to add apps and software updates to this step, but let's keep in mind that Peer Cache sources aren't full distribution points. In case you missed it, see above for more info on this.

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 peer cache 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 peer cache 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 peer cache 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 peer cache any differently than a Distribution Point when it comes to a retry. If it sees a peer cache is down, it will stop trying to locate it and look to another source. It will first prefer the subnet and 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 the SCCM Peer Cache.

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

Comments

• Anonymous
  January 15, 2018
  Nice, Lee!
• Anonymous
  January 15, 2018
  The broadcast port (8004 by default) is only required for WinPE based peer cache.PeerCache can download Software Updates just fine; see https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/client-peer-cache. This was changed at some point from memory.Peer fail is also 8 minutes to my knowledge.
  • Anonymous
    January 17, 2018
    Jason,I am not seeing where in the link it discusses Software Update Packages, unless I just missed something (been known to happen). I didn't see my update packages show up for content download, however.
• Anonymous
  January 17, 2018
  Hi Lee, very informative thanks!I did note you mention that Peer Cache isn’t used for software updates though? I wasn’t aware of that (or that it’s not used for ‘Application’ deployments either actually).Please could you help me understand where Peer Cache would be used when deploying Windows 10 Feature Updates?If it’s not used for software update deployment – does this mean that Peer Cache is only really used during task sequence based deployments? So if W10 Feature Updates are only being deployed via CM Servicing (instead of via an In-Place Upgrade TS) – Peer Cache would never be used for downloading those Feature Updates?Thanks,Greg.
  • Anonymous
    January 17, 2018
    The comment has been removed
• Anonymous
  February 05, 2018
  Thanks for your open minded attitude and working with us on the product team to update your blog during your medical leave Lee. It was great working with you on this blog..
  • Anonymous
    February 05, 2018
    Kerim, was a pleasure working with you on this. Definitely have to look you up the next time I'm in Seattle. :)
• Anonymous
  March 01, 2018
  Nice write up..I've been unable to make it work on 1706. Everything seems to be setup ok but clients try to reach superpeer but than fail to main dist point. Seems to error with winhttp_secure_failure.We have PKI deployed but i noticed that IIS on the site system, I don't have 443 binding to the pki cert.Is this a requirement? Everything else works fine.Any input would be great. thank you.
  • Anonymous
    March 07, 2018
    I would think that 443 would not be a requirement as it's not in the docs anywhere. The defaults of 8003 and 8004 are all you need, and with that, there is no requirement of a CA infrastructure. Without looking at the docs, my guess would be the cert (if any) would be self-signed.
• Anonymous
  March 22, 2018
  The comment has been removed
  • Anonymous
    March 28, 2018
    The comment has been removed
• Anonymous
  March 22, 2018
  The comment has been removed
  • Anonymous
    March 28, 2018
    The comment has been removed
• Anonymous
  April 25, 2018
  The comment has been removed
  • Anonymous
    April 26, 2018
    @Jeff, you may want to look at the location the client is downloading from. Applications cache differently than packages as they must be installed on the peer cache host first (not just "download package content").