Introducing the Pull-Distribution Points

[Yvette O'Meally]

First published on CLOUDBLOGS on Jun 06, 2013

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:

1. My site server is unusable for days if I make a big distribution to hundreds of distribution points: Above, I tried to explain the reason why this happens, but I think we should go deeper into the software distribution process to understand this better. Below you will find details about what happens in the background when software is distributed to each type of distribution point. This information is also useful because I see a lot of misconceptions where pull-distribution points are mistaken for branch distribution points (which were discontinued in System Center 2012 Configuration Manager).




1. 
   

   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.

   
   


2. 
   

   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:

   
   
   
   
   • The differences between regular distribution points and pull-distribution points start on steps A5 and B4; for regular distribution points, distmgr “pushes” the content directly to the distribution points but in case of pull-distribution points the pkgxfermgr sends a “notification” (to the pull-distribution points) to have the pull-distribution points start pulling the content from source distribution points as soon as possible.
   
   
   • Pull-distribution points are only different from regular distribution points with a small variance; they pull the content from their source and do the processing of the content locally (see B5 in table above).  This way the processing load on the site server is offloaded to the pull-distribution points.
   
   
   • Branch distribution points, which are deprecated in System Center 2012 Configuration Manager, were totally different. They were literally enhanced clients and hence used client channels for all communication. Therefore they had many issues like troubleshooting, monitoring, no PXE support, etc.
   
   
   • Pull-distribution points use the distribution point channel for all communication. This makes them easier to troubleshoot and monitor
   
   
   • Pull-distribution points can also be used for all the purposes of a regular distribution point, such as OSD, PXE, multicast etc.
   
   
   • Pull-distribution points can be installed on all operating systems that support a regular distribution point (even client operating systems)
   
   
   • Pull-distribution points do not require a Configuration Manager client be installed on the distribution point computer to function; they can be installed without an agent being present.
   
   
   
   




2. 
   

   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:

   
   




1. Have a hub/spoke model where there are one or more source distribution points that you push the content to and have many pull-distribution points pulling from these sources.


2. Have pull-distribution points pulling from other pull-distribution points (you can use a pull-distribution point as a source for another pull-distribution point), they are very flexible




3. 
   

   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

1. Every pull-distribution point will require a source distribution point. When planning for pull-distribution points these sources and their locations in your environment should be planned carefully right from the beginning of the design phase.


2. There should be a good network connectivity between pull-distribution points and source distribution points so that you can achieve efficient and fast software distribution.


3. Remember that since the pull-distribution point is a regular distribution point you can always prestage the content on it.


4. I mentioned that the pull-distribution point properties are almost the same as a regular distribution point. One difference is that in a pull-distribution point’s properties you don’t see the Scheduling and Rate Limits tabs. This is because pull-distribution points pull the content just like a Configuration Manager client does and they use BITS to download the content, again just like a Configuration Manager client. If you have a need to throttle or schedule your download times and bandwidth you would need to configure BITS settings on the pull-distribution points.
   

   You can configure BITS settings on pull-distribution points by using:

   
   
   
   
   1. Configuration Manager console : Use the Client Settings option in the Administration workspace (you would need the Configuration Manager client installed on your pull-distribution point computer; this won’t work without the Configuration Manager client)
   
   
   2. Group policy settings : Use this option if you don’t have a Configuration Manager client installed on the pull-distribution point computer.
   
   

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:

1. Introduction to Content Management in Configuration Manager http://technet.microsoft.com/en-us/library/gg682083.aspx


2. Planning for Pull-Distribution Points http://technet.microsoft.com/en-us/library/gg712321.aspx#BKMK_PlanPullDps

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:

1. Use the comments below


2. Use the TechNet forums
   http://social.technet.microsoft.com/Forums/en-us/configmanagerapps/


3. Use Microsoft Connect https://connect.microsoft.com/ConfigurationManagervnext/feedback/CreateFeedbackForm.aspx?Feedb...

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.