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.

NetworkDiagram

In particular I’ll be using machines in Boundary  Group 3.

image

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

image

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.

SMSTSPreserveContent

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.

image

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

image

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.

SMSTSPeerDownload

Set this to “TRUE”.

This triggers the client to utilize Peer Sharing during the build.

image

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.

image

  1. Select “Windows PE Peer Cache”; the very last item in the left hand column.
  2. 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).

image

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?

  1. 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.
  2. 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.
  3. 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.

image

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

image

Here is my demo build Task Sequence.

image

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.

image

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.

image


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.

 

image

My demo sequence caches the USMT package as well as the Windows 10 OS Upgrade package.

image

 

After running the sequence these pacakges were added to the CCMCache folder on my Peer Source machine.

image


References

For more information, please see these sites.

What’s new in System Center Configuration Manager Technical Preview 2

WinPE Peer Cache vs BranchCache for OSD vs Delivery Optimization

Prepare Windows PE peer cache to reduce WAN traffic in System Center Configuration Manager

Advertisements

Posted on February 24, 2016, in Configuration Manager, OSD, Peer Cache, SCCM, Task Sequences and tagged , , , , . Bookmark the permalink. 2 Comments.

  1. Great article! Was just about to start writing this up 🙂 At the top you mention the limitations – but don’t forget that you can always use PeerCache for the OS and then use BranchCache to get your Applications and Updates – so you’re still getting the benefit of P2P end to end. Cheers, Phil 2Pint

    Like

  2. Great article! Thank you!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: