Pull Distribution point can help reduce the processing load on the site server and can help to speed the transfer of the content to each distribution point. One other need to use Pull Distribution Point could be because you require more than 250 Distribution point from a single Primary site. Using Pull DPs comes with certain limits compared to using a standard DP.

In previous post we covered How to manage your Distribution Points with Collections in large environment. Based on those collections, it’s possible to manage network impact while distributing content to Pull DP.

This post will explain how limit SCCM 2012 Pull Distribution Point bandwidth.

Pull Distribution Point Bandwidth Limitation Differences

Rate Limits

One of the key feature missing from Pull DP is the ability to use rate limits.  The tab is not even visible for Pull DP properties.

  • To check the Full DP Properties, navigate in your console to Administration / Site Configuration Servers and Site System Roles
  • Click on your Distribution Point
  • In the Site System Roles section, right click on role name Distribution Point
  • Select Properties
SCCM 2012 Pull Distribution Point bandwidth

Screenshot : Standard distribution point – Rate Limits

So you are left with more than 250 DPs/Pull DPs and you are not able to manage the hit on the network bandwidth when distributing content.

Concurrent Distribution

Another missing feature of a Pull DP is the number of concurrent distributions. This cannot be managed automatically by threshold. So if you distribute a package to 1000 Pull DP, theoretically all of them could download at the same time. In fact, it doesn’t happen because the site server and SQL are so busy processing the requests.

Side note : There are no metrics from Microsoft when it come to a lot of Pull DPs. We asked the product team for the maximum concurrent distributions, without clear answer.

  • To check the Concurrent Distribution Settings, navigate in your console to Administration Site Configuration Sites
  • Click on your Site Server
  • In the top ribbon section, click on Configure Site Components and Software Distribution

sccm 2012 pull distribution point bandwidth

Important : The concurrent distribution settings for Pull Distribution point affects the number of concurrent package distribution for a single Pull Distribution Point. It is not meant to manage the number of Pull Distribution Point that can receive distribution at the same time.

Solution

The solution comes in two parts :

  • Carefuly plan DP groups to limit the quantity of simultaneous distribution
  • Create a specific Client Setting for those computers to use BITS

Distribution Point Groups

From our experience, DP groups can be of around 400 pull DP. Try to split so it make sense for your environment, without becoming too much management to distribute. Site server performance might require upgrades to CPU/RAM to ease distribution when so many DPs/Pull DPs are involved.

For example : 1000 Pull DPs splited in 3 groups with the biggest at 400 will work just fine. When it’s time to distribute,  do it one group at the time. Plan ahead as this will take time.

Client Settings

The way to control bandwidth for PullDP is through using BITS (background intelligence transfert service). Limiting with BITS is easy and constant.

Pull Distribution point can have a specific Client Settings.

  • Open the SCCM Console
  • Go to Administration / Client Settings
  • Create a new Client Settings

SCCM 2012 Pull Distribution Point bandwidth

  • Add Background Intelligent Transfer Service
SCCM 2012 Pull Distribution Point bandwidth
  • Configure the limits you want. This should be discussed with the network guys

SCCM 2012 Pull Distribution Point bandwidth

  • Deploy this new Client Settings to the collection of Pull DP
  • Be sure to check the priority of this Client Setting
SCCM 2012 Pull Distribution Point bandwidth
Important note
By using BITS to manage distribution to Pull DP, it will also affect the SCCM client when it try to download content in the local cache (C:\Windows\CCMCache). This mean that for those computers, the download time will be limited to BITS throttling.

 

SCCM 2012 Pull Distribution Point bandwidth

Comments (5)

Carroll Mariah

10.12.2020 AT 10:09 AM
Note: For this dedupe magic to work your Pull DPs need to be on Server 2012 or better. Windows 7 and 10 lack dedupe so while they can use BranchCache they don t get the extra benefits that dedupe brings to the table. The end result is that your Pull DPs will use less storage (dedupe) and bandwidth across your WAN (BranchCache). I experienced a 30-40% reduction in disk space and data transfer across several hundred DPs doing this. Phil confirmed that this is in line with his experience as well so I think it s a fair benchmark.

Guillaume

04.06.2018 AT 11:40 AM
Hello, In the important note, you mentioned SCCM client download will be impacted due to BITS limitation. Do you make reference to the sccm client on the pull-DP or sccm client which use the Pull-DP as content source ? Thank you

Arun

09.08.2017 AT 01:31 PM
if we have 200 machines on window 7, we want to upgrade window 7 to window 10 by sccm 2016 so how much bandwidth we will be used

carlo

07.07.2017 AT 06:04 AM
from what I've understood SCCM Secondary sites use file-based replication to transfer site data to their parent primary site. So try to have a look into Hierarchy Configuration -- File Replication for schedule and rate limits (if I'm not wrong...)

Scott Metzel

05.30.2017 AT 05:02 PM
So I know this article covers 2012, but, as of Current Branch build 1610 or 1702, the "Maximum concurrent packages for each pull distribution point" property which was on the "Pull Distribution Point" tab of the "Software Distribution Component Properties" property window is gone (as depicted in the second image in this article). Does anyone know a) why this was removed and b) how that setting is supposed to be set now? On a standalone Primary Site running ConfigMgr CB 1702, the value / setting is still in effect; I can see entries in PkgXferMgr.log which indicate it's still being applied, yet now there doesn't seem to be a way to control it. I'm not having an issue (and if I was this would take on a whole different level of urgency), but it's just.. gone.