Disruptive by Design: Maintaining Enterprise Baselines for Defense Operations

Peer cache is a great way to optimize Microsoft Endpoint Configuration Manager (MECM) and provide a more significant user experience to warfighters in remote areas.

MECM, formerly System Center Configuration Manager, is an enterprise tool to maintain compliance for Windows operating systems. It maintains all updates, third-party applications and enterprise configurations. Trying to maintain computers used for defense operations can be quite a challenge and this gives engineers the ability to directly affect battlefield endpoints.

One issue with an evolving technology-based world is providing up-to-date computers and data systems to on-the-ground forces in the most remote areas in the world. But peer cache is a client setting applied through the MECM console that allows a server or workstation to provide content to endpoints over the local area network (LAN), either in the same subnet or in a boundary group dictated in MECM.

Traditionally, MECM used only distribution points, which transfer content over the wide area network (WAN). The use of distribution points is a great way to get content around the enterprise; however, it can be limiting and slow progress if there are high-latency points.

For example, you have one remote location outside of the states and 10 distribution points located stateside. Depending on the network connection, it can take a lot of time to get the content onto all distribution points. The location outside the states must wait for the content to transmit to all the distribution points. Then, each machine at that location must reach the closest distribution point and pull the content individually.

Peer cache allows one machine to pull the content from the distribution point over the WAN, and then every other machine can pull the content over the LAN from the peer cache that has already received the content. This technology saves time and traffic flow. Peer cache enables the enterprise to have fewer distribution points, which reduces the time for distribution and allows more flexibility for forward operating bases or remote sites with poor network capabilities.

Peer cache works similarly to a distribution point; however, instead of the repository, it is downloaded on the machine once installed. As a result, it cannot host the boot image used in the Preboot eXecution Environment (PXE) process. The PXE process works by first pulling an Internet protocol from a Dynamic Host Configuration Protocol server. Once the new machine has pulled a new Internet protocol, it can look for the nearest distribution point to pull the initial boot Windows Installation Media. Once the installation media has been downloaded, that new workstation would pull the content from the peer cache. The primary benefit is that it does not go across the WAN, saving your network from being saturated.

When maximizing peer cache, you want to limit the number of peers per Internet protocol range. More is not always better when it comes to enterprise imaging. When a computer requests applications or packages that have been deployed to a group of peer cache computers, it receives a list from the management point of all available peer sources and then distribution points that contain the content. By default, the traffic will reach back to a display port if the application or package is not on the peer cache. To limit the amount of traffic going across the WAN, you want your main applications and packages distributed to all your display ports and then deployed out as required to all the peer caches. The deployment to the peer cache as required will allow the machine to download the content into its cache.

Here are a few troubleshooting steps to remember. First, the peer cache connects through the Internet protocol subnet or the boundary groups created in MECM, so you want to keep active directory sites and services clean and ordered. If you have overlapping Internet protocols in different regions, the machines could essentially crosstalk to pull the content they need. The computer only sees the available peers in the subnet, not the machine’s physical location. Another key is to not have peer caches all over the place. You only want it in locations where distribution points are unavailable due to slow networking or austere locations.

Warfighters in those austere locations deserve no less.

Dakota Miller is an SCCM engineer for Booz Allen Hamilton. Miller is on a mission to continue to innovate and integrate new technologies for the U.S. Defense Department.