/build/static/layout/Breadcrumb_cap_w.png

Package transfer to DPs

A colleague was just about to select 'Update Distribution Points' for AdobeAcrobat Pro v9. Given that this behemoth weighs in at a whisker over 1.2Gb, I ventured that to avoid a visit from vexed network ops Johnnies, it might be best if he waited until after 6pm. He is (well, was!) of the opinion that SCCM uses BITS to update DPs and therefore isn't a bandwidth hog. I figure that since it uses BITS to send packages to clients, it would be illogical for it to use some other mechanism to copy them to other targets. Can anyone enlighten us?

0 Comments   [ + ] Show comments

Answers (4)

Posted by: dunnpy 14 years ago
Red Belt
0
Ian,

I would concur with your colleague - assuming that the DP's were configured for BITS.

I've just checked the 'Microsoft System Center Configuration Manager 2007 Administrator's Companion' and that seems to be saying the same thing.

Just do it - it's a friday afternoon [:D]

Thanks,

Dunnpy
Posted by: Jsaylor 14 years ago
Second Degree Blue Belt
0
I'm reasonably sure that the DP and client BITS settings are separate in SCCM. Just because he has BITS configured to throttle on client agents (via GPO or via the SCCM interface) doesn't mean that copies to the branch DP's would be throttled.

I'll poke around and see if I can find the exact settings for branch DP throttling.

EDIT: A bit of research later, and I don't see anything that asserts standard DP's use BITS at all during the download process. Branch DP's can be configured to use BITS to carry data fairly easily, but those are distinct from how DP's are usually configured.

This seems to support the idea that BITS does not get used in the source directory --> Standard DP transfer.

EDIT 2: No mention of BITS at all in the distmgr log for DP updates on my fully BITS-enabled site. I don't know that this is conclusive proof, I could still be blind and/or stupid.

Also, I just noticed that I'm like... four hours too late.
Posted by: anonymous_9363 14 years ago
Red Belt
0
Thanks for your input, chaps. I appreciate it.This seems to support the idea that BITS does not get used in the source directory --> Standard DP transferUmmm...the last 'Comment' seems to say the opposite! Best thing, I think, is to set up a "dummy" for late one night and have the network Johnnies watch their gauges. They'll enjoy that...

EDIT:
Now that my client's network is behaving itself, I Googled and found http://windowsitpro.com/Windows/Articles/ArticleID/95959/pg/2/2.html which seems to confirm that BITS is indeed used.
Posted by: Jsaylor 14 years ago
Second Degree Blue Belt
0
Ummm...the last 'Comment' seems to say the opposite!


Unfortunately, "Branch DP's" and "DP's" are two entirely different things to SCCM. "Branch DP's" most definitely can be independently configured to use BITS for all data transfer to and from those servers. The concept was introduced with SCCM to allow non-server class hardware to be easily requisitioned for use as distribution points in small environments (aka, use a desktop as a DP.)

Normal DP's assume enterprise class hardware, and those are the ones that I can find no solid confirmation on whether or not the Primary site ---> DP package transfer is committed via BITS. Apologies if this was cleared up in that second post you found, I fail at having a windowsITpro account!

Edit: Also, wow, I shouldn't go on vacation and then start replying to stuff without checking dates first. Hello week old post!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ