ConfigMgr Current Branch–Windows PE Peer Caching
What is Windows PE Peer Caching?
Windows PE Peer Caching was a feature added in Configuration Manager Technical Preview 2. During an OS deployment, it allows a machine being built to pull content from other systems on the local subnet (its peers) as opposed to going across a potentially slow WAN connection. It is quite simply a peer-to-peer network of content providers. This is similar functionality to 1E’s NomadBranch and 2Pint’s BranchCache for OSD Toolkit.
Limitations of Peer Caching?
It only works if the task sequence starts from within Windows PE, either through a PXE boot or build media. If the task sequence starts from within the full OS then Peer Caching is unavailable.
Peer Caching only works with:
- Operating System Images
- Driver Packages
- “Legacy” Packages and Programs
- Boot Images
Applications and Software Updates do not take advantage of Peer Caching. Those will instead be sourced from a Distribution Point.
Peer Caching Lab Configuration
For this post I will be using a lab set up like this.
In particular I’ll be using machines in Boundary Group 3.
Boundary Group 3 represents a remote office that does not have a local Distribution Point. Perhaps the office is small with few clients or there may not be a secure location to store a Distribution Point. At this location, all ConfigMgr content will need to come across the WAN link from the main office (Boundary Group 1).
In this location there are 2 machines (PC32a and PC32b) that have some of the build content cached and will make it available for the third machine (PC32c) when it is built. Machines PXE boot across the WAN from the PXE-enabled Distribution Point DP01. This is configured using DHCP scope options for the 192.168.13.x/24 scope on the DHCP server DC01.
How does Peer Caching work?
When PC32c runs the task sequence and attempts to locate sources for the referenced packages it will first attempt to locate them in the cache of its peers. If a peer location cannot be found it will instead pull the content from a Distribution Point.
How to set up Peer Caching
There are a couple of moving parts you need to get in place to make this work.
Identify Peer Source Machines
First, you need to identify which machines you will want acting as peer sources. These should be machines that should be up and running when other machines are building. You don’t want your content source powering down in the middle of a download. Laptops probably would not be a good idea since they are mobile and ususally on slower wireless connections instead of wired.
Once you have identified which machines you want to act as peer sources you will want to place them into their own collection. In my lab I placed them in a collection called “Peer Cache Source Systems”.
Note: You are going to want to ensure that the ConfigMgr client cache size is large enough to hold all of the packages that you are intending to store.
Collection Variable for Peer Source Machines
Now that you have a collection that contains all of your machines that are intended to be peer sources you will add a Collection Variable.
You will set this to “TRUE”.
This enables those systems to retain the package content of any package it uses during the buld and to make it available for other machines to access. Otherwise the task sequence will behave as it normally would and discard the package content once it has completed the action that required it.
So, when machines in this collection are built the packages they used will be cached and made available for others.
The packages will be found in C:\Windows\CCMCache
Each package will be stored in a numbered folder. In this demo folder “1” contains the ConfigMgr client install files, folder “2” contains the install.wim.
Collection Variable for Peer Client Machines
On your collection where you have targeted your build task sequence you will set a different Collection Variable.
Set this to “TRUE”.
This triggers the client to utilize Peer Sharing during the build.
ConfigMgr Client Settings for Peer Sharing
Almost there, one final configuration needs to be done. We need to enable Windows PE Peer Caching in our client settings.
You can either create a brand new Client Settings or modify the Default Settings. In my case I modified the Default Settings.
- Select “Windows PE Peer Cache”; the very last item in the left hand column.
- Change “Enable Configuration Manager client in full OS to share content” to Yes
The ConfigMgr client will automatically create Windows Firewall rules for the ports specified for communication (ports 8003 and 8004 by default).
In Windows Firewall with Advanced Security you will find 2 Inbound rules named SCCMSuperPeer.
One allows UDP port 8004 and the other allows TCP port 8003.
How does these pieces fit together?
- The Collection Variable SMSTSPeerDownload on the OS deployment collection, instructs machines to look first for a peer source for any content referenced in the build.
- The Collection Variable SMSTSPreserveContent on the Peer Cache Source collection, instructs machines to retain any packages used during their building for later access by other peer clients.
- The Client Settings “Enable Configuration Manager client in full OS to share content” does the actual turning on of the sharing once a machine is built.
Download Package Content
This is a new action available for task sequences. This action allows you to identify specific packages that should be retained in the Peer Cache on a system.
From within the Task Sequence editor click the Add pulldown. Choose Software and then Download Package Content from the flyout menu.
Next click the add button and select the packages that you want to download to the system. If you want them to be retained for Peer Sharing select the bullet for “Configuration Manager client cache”
Here is my demo build Task Sequence.
During the Setup Windows and ConfigMgr step I am using the SMSCACHESIZE client install parameter to set the cache size to 20GB so I’ll have plenty of space for testing.
This sequence will build a Windows 8.1 machine so the install.wim for Windows 8.1 will be stored in the peer cache. In addition I’m also using a Download Package Content action to store the install.wim for Windows 10. When the build completes this machine, since it is a member of the Peer Cache Source Systems collection will share out not only the packges used in building a Windows 8.1 system but also if a machine is building using a Windows 10 sequence the Windows 10 install.wim is available as well.
How do you tell if it is working?
Look in the SMSTS.log file. Search for the string “Downloaded file from”. You should see that the location that the file was downloaded from is one of your Peer Source systems.
That’s great, but what if my Peer Sources are already built?
You can create a custom task sequence and simply add a Download Package Content action that specifies all of the packages that you want to cache on the system.
My demo sequence caches the USMT package as well as the Windows 10 OS Upgrade package.
After running the sequence these pacakges were added to the CCMCache folder on my Peer Source machine.
For more information, please see these sites.
Posted on February 24, 2016, in Configuration Manager, OSD, Peer Cache, SCCM, Task Sequences and tagged Configuration Manager, OSD, Peer Cache, SCCM, Task Sequences. Bookmark the permalink. 2 Comments.