locked
Need help understanding rate limits on DP's in large environments RRS feed

  • Question

  • I understand what rate limiting does, but I cannot find the answer to how SCCM chooses which content locations from a DP group.

    Our challenge is that we have ~100 DP's, 80 of which are in remote locations with very small WAN connections. For thos sites, we have to limit traffic heavily (limit available bandwidth to 10%) during business hours (8am-8pm ) . These 80 DP's with slow connections were all secondary sites in 2007, so the sender took care of much of the traffic. Now with them all being DPs, we are limited by the 'Concurrent Distribution Settings' 'Maximum number of packages' setting, which maxes out at 7.

    Our challenge is that it appears that SCCM is not intelligent enough to know that it will never get the 2GB package out during business hours to 7 of these poorly connected DP's, but chugs on them until completion rather than moving on to other sites with less (or no ) rate throttling.

    I had the thought of tiering the DP groups, and not strating the content distribution until the previous tier was complete, but this will triple or quadruple the work of our distribution team.

    My question is if we set those slow DP's to 0% available during 8am-8pm, will pkgXferMgr be smart enough to skip those sites and move on to other sites, or will it just queue the transfer up and wait till 8pm, effectively halting all distribution settings during the day?

    Is there an obvious out of the box solution I'm missing here? We're working with 3rd party vendors to evaluate their solutions, so please only respond with out of the box solutions.


    Will

    Wednesday, May 15, 2013 12:05 PM

Answers

  • Hi Will,

    You cannnot actually set 0% rate limits - so you will need to look at using the scheduler to open/close the DP to certain priorities of traffic during the day.  If a DP is not open to traffic of the same priority set of the content you are sending then ConfigMgr will move on to other open DP's.

    AFAIK there is no way to automatically set the order of the Distribution Points to which content is distributed to and I am unaware of how the DP selection is made.


    My Personal Blog: http://madluka.wordpress.com

    Wednesday, May 15, 2013 12:42 PM

All replies

  • That mechanism is not too smart from what I have seen. You could play with (package) priorities though. Set "small" packages (applications etc) to priority "medium" and large ones to "low" and configure the DP settings appropriate.

    Torsten Meringer | http://www.mssccmfaq.de

    Wednesday, May 15, 2013 12:30 PM
  • Hi Will,

    You cannnot actually set 0% rate limits - so you will need to look at using the scheduler to open/close the DP to certain priorities of traffic during the day.  If a DP is not open to traffic of the same priority set of the content you are sending then ConfigMgr will move on to other open DP's.

    AFAIK there is no way to automatically set the order of the Distribution Points to which content is distributed to and I am unaware of how the DP selection is made.


    My Personal Blog: http://madluka.wordpress.com

    Wednesday, May 15, 2013 12:42 PM
  • In Administration -> Distribution Points, you can right click on a DP, properties, and set the schedule and rate limits of the 80 slow DPs.
    Wednesday, May 15, 2013 9:39 PM
  • AFAIK there is no way to automatically set the order of the Distribution Points to which content is distributed to and I am unaware of how the DP selection is made.


    Thats really what I was hoping someone would chime in on, but if Torsten is in the dark, I'm guessing its not likely something I'll get an answer to on this post.. The challenge with priorities is that it requires some thought and understanding of DP's, WAN size, etc. We've typically shielded our distribution tech's from having to deal with that. They just drop them in, and we try to have the infrastructure protect itself. We'll have to change process somewhere.

    I dislike the idea of tiered DP groups, but they may be the only real answer, although they will dramatically increase the distribution team's workload :/


    Will

    Thursday, May 16, 2013 11:54 AM
  • I'm afraid you will have to separate the 7 slow DP's from the total pool of DP's, deploy to your first pool of 73 then to the 7 slow ones.

    You could also look into Pull DP's to pull the content down from nearer DP's so that DistMgr on the site server isn't moving the content to them. If they have a closer DP to obtain the content from than where it is originating (the site server) this may assist.


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Saturday, May 18, 2013 10:34 AM
  • I'm afraid you will have to separate the 7 slow DP's from the total pool of DP's, deploy to your first pool of 73 then to the 7 slow ones.

    You could also look into Pull DP's to pull the content down from nearer DP's so that DistMgr on the site server isn't moving the content to them. If they have a closer DP to obtain the content from than where it is originating (the site server) this may assist.


    Rob Marshall | UK | My Blog | WMUG | File CM12 Feedback | CM12 Docs | CM12 Release Notes

    Here's a thought - could the slower dp's all be set as pull dp's to pull from the primary?  Would this accomplish the same goal albeit that the pull's wouldn't count against the concurrent distributions?  Are any number of concurrent downloads by pull dp's permitted?  Can a primary BE a source for a pull dp?  Lab time!

    My Personal Blog: http://madluka.wordpress.com

    Monday, June 10, 2013 11:31 AM
  • I hadn't thought of that option, but you are correct - lab time. We'll be going to SP1 this weekend, so that may provide some relief.

    Will

    Monday, June 10, 2013 11:41 AM