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)
A1 |
The user creates content (package/app) and distributes it to multiple regular distribution points |
A2 |
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 |
A3 |
Distmgr asks Package Transfer Manager (pkgxfermgr) to start processing the content |
A4 |
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 |
A5 |
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. |
A6 |
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)
B1 |
The user creates content (package/app) and distributes it to a multiple pull-distribution points |
B2 |
Distribution manager (distmgr) asks Package Transfer Manager (pkgxfermgr) to start processing the content |
B3 |
Pkgxfermgr verifies if the content is available on any of the source distribution points for each pull-distribution point |
B4 |
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) |
B5 |
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). |
B6 |
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.
-- Kerim Hanif
This posting is provided "AS IS" with no warranties and confers no rights.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.