Hi everyone, welcome to the second blog in the series “New Distribution Points in Configuration Manager SP1”.
In this second post I am going to talk about “pull-distribution points”
You may ask why we introduced this new distribution point in SP1. One of the easiest ways to understand the reason is to imagine the scenario where you are distributing a content to tens and sometimes hundreds of distribution points at the same time. You can do this by targeting a distribution point group that has many distribution points in it, or this may occur if you are adding a new distribution point to an existing distribution point group. The action of distributing content to a large number of distribution points puts a huge load on the site server, especially the ‘distribution manager’ (distmgr) and ‘package transfer manager (pkgxfermgr)’ components of the site server. Basically the ‘distmgr’ becomes a bottleneck, and this is why in Configuration Manager 2012 RTM the recommendation is not to have more than 250 distribution points per site (by the way this is not a hard limit, it is just our product team’s test number for adequate performance).One of the ways for customers that have more than 250 distribution points in their environment to mitigate this bottleneck is to add a secondary site and have some distribution points under that site. By using distribution points at a secondary site they can keep the number of distribution points assigned to each primary or secondary site at less than 250. If you think about it, with this workaround what you are doing is you are actually just adding another ‘distmgr’ component (which comes with all primary or secondary sites) to help distribute the load. The problem with this design is that it makes the Configuration Manager hierarchy more complicated by introducing more site systems to the equation.
We have heard loud and clear from many of our customer’s that they want:
- A way to avoid ‘distmgr’ becoming a bottleneck
- To simplify their hierarchy and eliminate secondary sites
- The new solution with a minimum learning curve for their administrators
I think we have a good solution in Configuration Manager SP1 called ‘pull-distribution points’ that satisfies all of these asks. Let’s take a look at them more closely to understand why:
Software distribution process (for regular distribution points)
The user creates content (package/app) and distributes it to multiple regular distribution points
Distribution manager (distmgr) does preliminary checks
- IIS check (once a day) and file share check on remote distribution point (does this for every distribution) to see if they are configured correctly
Distmgr asks Package Transfer Manager (pkgxfermgr) to start processing the content
Pkgxfermgr starts working
- Since this is not a “redistribute” action where pkgxfermgr replaces the whole content, it tries to make sure to use a single instance of the content. To do so, it checks with the remote distribution point and then copies only the files that do not exist on the remote distribution point
Pkgxfermgr starts copying (pushing) the files to all of the distribution points. By default, it can simultaneously process 3 unique packages and distribute to 5 distribution points in parallel (these concurrent settings are configurable). When the first batch completes, pkgxfermgr goes to the next batch until it finishes copying to all distribution points.
Once the pkgxfermgr is done adding all the files to the content library on the remote distribution point computers, it verifies the hash of the content and notifies distmgr of a successful distribution.
Software distribution process (for pull-distribution points)
The user creates content (package/app) and distributes it to a multiple pull-distribution points
Distribution manager (distmgr) asks Package Transfer Manager (pkgxfermgr) to start processing the content
Pkgxfermgr verifies if the content is available on any of the source distribution points for each pull-distribution point
Pkgxfermgr sends a notification to each pull-distribution point to have the pull-distribution points start pulling the content (this notification includes the file names, sizes, hash values, attributes)
As soon as pull-distribution points receive this notification they start processing the content, and perform all of the checks that pkgxfermgr does in the first scenario (A4) but this time these processes run on the pull-distribution point locally (saving site server from using resources for these processes).
Once processing is completed, the pull-distribution point checks its list of source distribution points (which have already been defined during pull-distribution point setup). It starts with the first one on the list and tries to download the content, if it can’t find the content on the first source distribution point it moves to the next and tries to pull the content from there. This continues until the pull-distribution point succeeds in getting the content.
Regular vs. Pull vs. Branch Distribution Points:
Here are some bullets to summarize the differences and note some important differences in above tables:
I want a simpler hierarchy and to eliminate my secondary sites if possible: Secondary sites bring many advantages like the proxy management point, network bandwidth control, etc. But as I mentioned above we see that they are also used by customers with large environments with more than 250 distribution points to stay under the supported distribution point number for each site.
If the reason for secondary sites is just for this purpose and nothing else (to be under the supported number), then it is possible to eliminate these secondary sites by utilizing pull-distribution points.
You can see from the above tables A and B, the majority of the work that makes the distmgr a bottleneck (A4 and A5) is offloaded to the pull-distribution points. Since the load is distributed, there are less chances that distmgr would be a bottleneck for this scenario.
Some ideas for hierarchies utilizing pull-distribution points:
I don’t want to introduce a new learning curve to my admins: The pull-distribution point is just another distribution point; it is installed using the same wizard, it looks exactly the same in the UI, it has the same properties (well almost, more on this later) and more importantly it can be incorporated in all of your existing processes. So if you utilize pull-distribution points you will introduce a minimal new learning curve for your admins.
Considerations when planning for pull-distribution points
You can configure BITS settings on pull-distribution points by using:
Finally, just like I did in my first blog, I want so share with you some links from our official documentation in TechNet where you can find some more great information on pull-distribution points:
I hope that this blog post was useful and helped you answer your questions about pull-distribution points. If you have more questions or feedback, you have three choices:
Use #1 or #2 for questions, but if it is a bug or a feedback please use Microsoft Connect. This is important because when you leave feedback there, it automatically creates a bug in our database and gets the immediate attention of the whole feature team.
In my third and last blog of this series, I am going to be talking about advanced topics, caveats and things to watch out when planning and using new distribution points.
This posting is provided "AS IS" with no warranties and confers no rights.
From the article, "Planning for Pull-Distribution Points"
'Although a pull-distribution point supports communications over HTTP and HTTPS,
source distribution points must be configured for HTTP. You cannot specify a source
distribution point that is configured for HTTPS.'
Why was this done? Since everything in my hierarchy is HTTPS, I am unable to use Pull DPs.
Thanks. Very useful. I would like to say, though, that using multiple DPs can eliminate the need for secondary sites in many scenarios, not just when you are reaching the 250 DP limit.
Jeremy -> Please send us this feedback through the Microsoft Connect channel (as I explained at the end of my blog post) and we will see if we can add this support for you.
Thank you all for your feedback..
Great blog post!
Excellent Post... Thank you !
Hi. I know that you can't make a DP that is on a Site Server a Pull DP. What is not clear is if a DP on a Site Server can be used as a Pull DP Source.
I'm trying to remove a Secondary Site. I've got a new DP. Instead of distributing content over the wire I'm trying to get the content from the existing DP that is the MP and Site Server for this Seconday Site. That makes a lot more sense to me.
What am I missing? Site is SP1. New DP has the SP1 client. Existing MP/SS/DP does *not* have the client installed. Is that what I'm missing?
Would like to get clarity from you on whether or not Pull dp functionality works when source dp and pull dps are in a same distribution point group.
From link #1 - you can set up a Pull-DP to be sourced from an HTTPS DP, but it requires a little more work.
"Only distribution points that qualify to be source distribution points are displayed. Only distribution points that support HTTP can be specified as a source distribution points when you use the Configuration Manager console. However, you can use the Configuration Manager SDK to specify a source distribution point that is configured for HTTPS. To use a source distribution point that is configured for HTTPS, the pull-distribution point must be co-located on a computer that runs the Configuration Manager client. A pull-distribution point can be specified as a source distribution point for another pull-distribution point."
Great and clarifying article! It resumes exactly what most SCCM admins needs to know about DPs. Congrats for your job!
I was really excited about the idea of using pull Distribution Points until I saw that they are only controlled using BITS and don't have the typical bandwidth throttling capabilities of a regular DP. Unfortunately this is a deal breaker on our network of 100,000+ clients across 3000 locations. :(