SCCM CB | How to configure and use Peer Cache in SCCM CB (Application, package and OSD)

Commentaires fermés avril 30th, 2019


In this post, I explain you how to configure and use the peer cache with Sccm CB application, package and OSD deployment.

For the start, it’s need to be clarify one point, the Peer Cache feature is available since the SCCM 1610 version.

Configuration Manager doesn’t enable this optional feature by default. You must enable this feature before using it. For more information, see Enable optional features from updates.

For enable the peer cache feature, it’s necessary to activate the feature in Administration>Overview>Updates and Servicing>Features

You can minimize and improve the network transferts in activated the option below (Configure client peer cache sources to divide content into parts. These parts minimize the network transfer to reduce WAN utilization):

After that, le’t go for the peer cache configuration!

The first one is the prerequisite:

  • One or many workstations dedicated to be peer cache client
  • Boundaries and boundaries Group configured
  • Collection with Clients Settings configured with the peer cache option

Reminder for the peer client cache configuration:

A peer cache source rejects requests for content when it meets any of the following conditions at the time a peer requests content:
  1. Low battery mode
  2. Processor load exceeds 80%
  3. Disk I/O has an AvgDiskQueueLength that exceeds 10
  4. There are no more available connections to the computer

A-Peer cache configuration and requirement parameters

1-Create the target collection for the peer cache client (in my example, i have two clients)

2-Create a new custom clients settings with this parameter under:

Configure client cache size = Yes

Maximum cache size (in my example, i put the maximum for the cache client=65000)

Maximum cache size = 20

Enable Configuration Manager client un full OS to share content = Yes

Port for initial network broadcast = 8004 (You don’t miss to open this port on yours firewalls)

Por for content download from peer = 8003 (You don’t miss to open this port on yours firewalls)

3-Create a second collection with all clients included in the same boundaries group that the peer cache client (This collection is used for generalize application deployment = after you will deploy the application on yours peer cache client)

4-Deploy an application to the peer cache clients (in my example, i take 7-Zip = ELY00029=Package ID)

5-At this moment, i can check in CAS.log if the package is donwloaded in the cache of my client by the distribution point and if his present in the cache (this step is necessary and it’s just for one time, the first time)

6-Now, if i install the 7 Zip package on another workstation included in the same boundaries group, the package is good downloaded by the peer cache client (DataTransferService.log)

7-The 7-Zip application installed correctly and by the peer client cache :-)

B-Configure Peer cache for OS Deployment

In this example,  the peer cache works the same way that the application and package model deployment, it’s necesseray to deploy your OS image and package OSD for the first one in your branch

1-Prepare you task sequence to deploy OSD

2-For that you peer cache client keep all objects OSD in her cache, it’s necessery to add variable in collection SMSTSPreserveContent=True

For information, when you have finish and you want to deploy OS using the peer cache feature, it’s necessary to put the variable (SMSTSPeerDownload=True) on the collection

3-Launch your OS Deployment…

4-After you will find the config manager client cache with the package OSD in his cache, you first peer cache client for OSD is ready!

5-You can see the log result of smsts.log and that he use good the peer cache feature (network)

Package ID=ELY00004

Package ID=ELY00014

Package ID=ELY00015


Enjoy! :-)

Sources Peer cache for Configuration Manager clients

SCCM 1806 Hotfix available (KB4462978) !

Commentaires fermés octobre 31st, 2018


Just a article for you inform that the SCCM 1806 Hotfix KB4462978 is available on your console.


PXE crash

No comments octobre 4th, 2018


A troubleshoot post available under.

Configure IP Helper

Configuration Manager PXE boot causes Windows Deployment Services to crash

Applies to: Microsoft System Center Configuration Manager Current branch


You use a System Center Configuration Manager PXE service point (Configuration Manager 2007) or a Pre-Boot Execution Environment (PXE) distribution point (Configuration Manager 2012) to perform PXE boots. In this situation, the operation first appears to work successfully, but then the process stops running. When you examine the server on which the PXE service point and Windows Deployment Services(WDS) are installed, you discover that WDS has crashed.

When you restart WDS on the server, this does not resolve the issue. When you restart both the Windows Management Instrumentation and WDS, or when you restart the server itself, this may temporarily resolve the problem. However, the issue eventually recurs, and WDS crashes again.

If you try to reproduce this issue by continuing to perform PXE boots, you discover that although the issue may occur frequently, it cannot be reproduced on a consistent basis. The crash behavior occurs randomly.

When you use Event Viewer to examine the WDS server on which the Configuration Manager Current branch PXE service point is installed, you find that the following errors are logged.

System log:

Application log:

Windows Deployment Services log:

You may also receive the following error message:

The Windows Deployment Services (WDS) Server service terminated with service-specific error 16389 (0×4005).


This issue may occur in environments where there are redundant backup routers. If IP Helpers for PXE (DHCP relays) are positioned on both the primary and backup routers, this may cause a situation where two duplicate PXE request packets are sent to WDS: the original PXE request by the primary router and a duplicate PXE request by the backup, redundant router.

If the timing is just right, the duplicate PXE request may overwrite some of the information in WDS from the original PXE request. This causes information in WDS for the PXE request to become corrupted, and then WDS crashes.


To work around this issue, use one of the following methods:

  • Disable the PXE IP Helpers in the backup, redundant router so that duplicate PXE requests are not sent. For more information about PXE IP Helpers, see the following TechNet article:
  • Configure the Configuration Manager WDS provider to be single-threaded instead of multithreaded. This will limit WDS processing of PXE requests to one at a time and will prevent the second, duplicate PXE request from conflicting with the original request. To configure the Configuration Manager WDS provider for single-threading, create the NumberOfThreadsregistry key with a DWORD value of 1 in the following location:Configuration Manager 2007 32bit WDS server:HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\PXEConfiguration Manager 2007 64bit WDS server: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\SMS\PXEConfiguration Manager 2012 DP/WDS server:HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\DPDoing this does not typically affect server performance for PXE requests except in environments where a large number of PXE requests are performed on a consistent basis. In these environments, we recommend that you use the first workaround.