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.
- 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.
- 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.
- 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.
Some notes here:
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
- Boot into Windows PE
- Open up the command prompt and open up the SMSTS.log to view results
- 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.
Filter on the FQDN (in my case stevens.family)
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:
|Operating System||Supports Peer Cache||Supports DP||Supports PXE||Supports Multicast|
|Windows 7 SP1, 8, 10||Yes||Yes||No||No|
|Windows Server 2008 R2,
2012, 2012 R2, 2016
|Windows Server Core 2008 R2,
2012, 2012 R2, 2016, 1709
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: http://aka.ms/leesteve —
If you like my blogs, please share it on social media and/or leave a comment.