Peer-To-Peer Content Distribution Options for Configuration Manager

If you’re using Microsoft System Center Configuration Manager to manage your desktop environment, you are probably considering the options available for delivering software distribution, patch management and OS deployment without implementing Distribution Points in every location. Configuration Manager has come a long way in providing solutions for remote users. Microsoft has also introduced a number of options for peer-to-peer content distribution for systems management.

1E was the first company to invent a peer-to-peer content distribution solution (Nomad) for Configuration Manager (or Systems Management Server as it was then). We are often asked about the options available ‘out-of-the-box’ from Microsoft for peer-to-peer content distribution and whether there is still a requirement for Nomad. The table below summarizes the three Microsoft peer-to-peer solutions available and compares them to 1E Nomad.

* Not officially supported but can be tweaked using 3rd party tools

This article explains each of the options in more detail so you can make an informed decision when choosing a peer-to-peer content distribution solution for Configuration Manager.

BranchCache

BranchCache is a feature of the Windows operating system, introduced in Server 2008 R2 Enterprise and Windows 7 Enterprise. (In fact, BranchCache can also be used with Windows Professional, but is limited to BITS transfers only – for more details read, Operating systems for BranchCache client computer functionality).
BranchCache can be used for peer-to-peer sharing of content from an HTTP or SMB source on the BranchCache server. BranchCache can operate in one of two modes:

• Hosted mode requires a BranchCache server in the remote location. New content is downloaded by a peer workstation then uploaded to the local BranchCache server. Subsequent requests for the same content in the same location are then served by the local BranchCache server. This mode can span multiple subnets in a location, and the server is also going to be available when the content is required by other peers. This is not particularly useful however if you are trying to reduce infrastructure! It’s also not supported for Configuration Manager.
• Distributed mode only requires BranchCache clients in the remote location. Clients that require content download the content from the remote source and store it in their BranchCache cache. When other peers require the content, they can get it from any other BranchCache client on the local subnet – assuming they haven’t been switched off or taken home by the user.

In 2009, Microsoft added support for BranchCache (Distributed Mode only) for peer-to-peer content distribution in Configuration Manager 2007 SP2. If your Distribution Point servers and your clients have the BranchCache feature installed and configured correctly, simply enabling the option in the Configuration Manager Deployment (for Packages, see Figure 1) or Deployment Type (for Applications, see Figure 2) will make it all happen. In fact, these BranchCache options are enabled by default on all new Package Deployments to Software Update Deployments and Application Deployment Types as of Configuration Manager 2012.

Fig 1. Enabling BranchCache for a Package Deployment

Fig 2. Enabling BranchCache for an Application Deployment Type

Fig 3. Enabling BranchCache for a Software Update deployment

BranchCache is great because it allows peer-to-peer sharing of any content that is hosted on a server that has BranchCache enabled. Documents from (on-premise) SharePoint sites or corporate file servers can be shared among BranchCache peers with no additional configuration required on the client, as long as the hosting server has the feature installed and configured correctly.

When it comes to content distribution in Configuration Manager, there are some things you need to think about when using BranchCache:

• When a BranchCache client downloads content from a remote Distribution Point, it uses the Background Intelligent Transfer Service (BITS) to manage the bandwidth. BITS does a very poor job of understanding what bandwidth is actually available. It only looks at the local network adapter – if that connection happens to be a 100Mbps Ethernet adapter and the client is doing nothing else on the network, BITS will assume it has 100Mbps to play with. Of course the end-to-end bandwidth is often much less and has other clients using it too. You can ‘cap’ BITS so it will never use more than a specific amount of bandwidth (defined as an amount such as 20kbps, not a percentage) but this may still result in network congestion and will slow everything down, even if more bandwidth is available.
• Every client that requests content has to download the BranchCache ‘manifest’ directly from the BranchCache server. This manifest defines the signatures for the BranchCache ‘chunks’ of data that make up the content. Although this manifest is a lot smaller than the content itself, be prepared for every client connecting to the BranchCache-enabled DP and downloading it over the WAN.
• BranchCache doesn’t do a great job if everyone wants the same content at exactly the same time. In that scenario, you can end up with every client starting to download the content independently over the WAN using BITS (aaargh!), until one of the clients gets ahead of its peers and has more of the content. This doesn’t happen under normal circumstances, but if you’re using Wake-on-LAN or setting the Start Time on your deployments to a time in the future (perhaps to avoid downloads over the WAN during business hours) you are more likely to run into this issue and you’ll have the network guys on your back!
• BranchCache is not officially supported in Windows PE. If you’re doing OS Deployment with Configuration Manager, you’re probably aware the new operating system image – probably the biggest lump of content you ever need on a client – is usually downloaded while running in Windows PE. Not great if that is going to be downloaded across the WAN, using BITS, by every client that gets rebuilt. There are some tweaks you can do with 3rd party tools to get it working, but oddly Microsoft chose a different path…in the form of the Windows PE Peer Cache.

Windows PE Peer cache

Windows PE Peer Cache is a new feature introduced in the Configuration Manager Current Branch 1511 release. It is designed to get around the shortcoming of BranchCache not being (officially) supported in Windows PE.

You can designate any existing Configuration Manager clients as a Windows PE Peer Cache source through Client Settings. You’ll probably want to build a specific Device Collection (excluding laptops and ‘VIP’ systems perhaps) and create custom Client Settings to enable Windows PE Peer Cache on that Collection of devices.

Fig 4. Windows PE Peer Cache Client Settings

The next step is to set the SMSTSPeerDownload variable to TRUE in your OSD Task Sequence. This will enable a client running the Task Sequence to get Package content from a Windows PE Peer Cache on the local subnet. Note that only Package content (including OS images, boot images, driver packages and bog-standard software packages) can be obtained using the Window PE Peer Cache feature. It’s not limited to the Windows PE stage of the Task Sequence – a Windows PE Peer Cache source could be used for Package content in the Task Sequence when the full OS is running. However, you’re not going to get any Application or Software Update content this way – for that you’ll need to implement another peer-to-peer solution.

If the client running the Task Sequence is unable to find the content it needs on a Windows PE Peer Cache on the local subnet, it will download the content from the DP. Normally when a Task Sequence executes, content is temporarily downloaded into the _SMSTaskSequence folder and deleted when the Task Sequence completes. This isn’t very helpful if you want the rebuilt client to share the content it’s just spent ages downloading with its peers later on.

Setting the SMSTSPreserveContent variable to TRUE in your Task Sequence will ensure that when a client downloads content during the OSD Task Sequence, it will be preserved in the Configuration Manager client cache when the Task Sequence completes. If the rebuilt client also has the Windows PE Peer Cache client settings applied through policy, it becomes a Windows PE Peer Cache source with all the Task Sequence content available in its cache (as long as you’ve allocated enough space in the Configuration Manager Cache settings).

It is also possible to pre-stage Task Sequence content to Windows PE Peer Cache clients by including the Download Package Content step in the Task Sequence. You don’t want the Task Sequence to actually execute and rebuild the source machines, so best to create a pre-stage Task Sequence that includes all the reference packages you need in your ‘real’ deployment Task Sequence, but define the logic so the Task Sequence exits after the Download Package Content step without actually installing any of the images, drivers or packages.

Windows update delivery optimization

Fig 5. Enabling Windows Update Download Optimization

Recently we’ve had a lot of people asking about the new Windows Update Delivery Optimization (WUDO) feature, introduced in Windows 10. You can enable this on clients through Settings > Update & Security > Windows Update > Advanced options > Choose how updates are delivered, or of course through Group Policy.

Windows Update Delivery Optimization enables clients to obtain Microsoft updates from peers rather than downloading directly from Microsoft Windows Update. However, this is only going to benefit you if your clients are getting updates using Windows Update or Windows Update for Business. If you’re using Windows Server Update Service (WSUS) or Configuration Manager for managing updates, WUDO is already out of the equation.

1E Nomad

Hopefully this article has given you a good idea of the options for peer-to-peer content distribution that Microsoft offers out of the box, what they are good for and where they may be lacking. You may find that these meet your requirements. You should also consider the following benefits you get with 1E Nomad:

• Nomad uses a continually learning algorithm that takes into account changes in end-to-end bandwidth, latency and I/O performance on the source (whether that is a DP across the WAN or a local peer) to determine the optimum rate for content transfer. It will instantly back off to accommodate other traffic and use what is available when bandwidth is freed up. With Nomad, distribution of Configuration Manager content will never cause network congestion.
• Nomad can be used to download all Configuration Manager content types (Packages, Applications and Software Updates) in both the full OS and in Windows PE during an OS Deployment Task Sequence. No need to maintain different tools, configurations and Task Sequences for different deployment tasks.
• Content can be pre-staged to clients in remote locations using the Precache Content Wizard – a simple right-click wizard in the ConfigMgr console. Unlike the Windows PE Peer Cache, you don’t need to create and deploy custom Task Sequences if you want to pre-stage OSD Task Sequence content in each location before it is needed.
• If you’re using Configuration Manager for OS Deployment, Nomad also takes care of PXE and User State Migration. It comes with a peer-based PXE service, so you always have several PXE servers available on every subnet (no need for any DHCP options or IP helpers on your routers). The Peer Backup Assistant enables storage on local peers to be used to temporarily store USMT data from clients that are being rebuilt.
• Content downloaded during an OS Deployment Task Sequence can be preserved in the Nomad cache, making it available to other peers when the Task Sequence has completed. If you’re not formatting or re-partitioning the disk, all the previously cached content is also preserved so when the client gets to the point in the Task Sequence where it installs software Packages, Applications and Software Updates, much of the content may already be in its local cache – it doesn’t even need to get it from a local peer, let alone a remote DP.
• The FanOut feature in Nomad considerably speeds up deployments enabling multiple devices within a subnet to simultaneously become a content source for other peers, even while they are getting the content themselves from other local peers.
• The Single Site features in Nomad enable multiple subnets to be mapped to a single location. This enables content to be downloaded once over the WAN and distributed across subnets within the location. You won’t get that level of efficiency with BranchCache (Distributed Mode) or Windows PE Peer Cache. The single site feature can also be used by the Peer Backup Assistant, allowing USMT data to be stored on peers in neighboring subnets if there is no suitable candidate on the local subnet.
• Nomad also comes with 1E WakeUp, which enables deployments to be managed confidently out of hours ensuring PCs are woken up when an Assigned Deployment is scheduled for them. WakeUp also integrates with Nomad, so if a Nomad client requires content that is known to be on a local peer which happens to be powered off, Nomad will initiate the process to wake up the local peer and get the content from it rather than downloading it all again over the WAN.