I have a problem with one Windows 2012 server and SCCM client BITS downloads. Jobs created by SCCM client and under SYSTEm account are extremely slow, some 40-60Kbit/sec only. Link itself between client and SCCM 2007 server is 1..1.5Mbit/sec.

  After a couple days I have exchausted my ideas. BITS GP policies are in place, minimum at workhours is 100kbit/sec but download is always 40-60Kbit/sec. Is it workhours or not. 17Mb file I can download over http manually in seconds. It also downloads with seconds when I created schedule task under system account where there was row

start-bitstransfer -source http://server/test.cab -destination c:\folder\test.cab

I tried changing permissions on SCCM side, give anonymous user rights to download, put NTAuthenticationProviders to "NTLM" but without any changes on download speed. To download this 17Mb file with SCCM client takes hours. Of course, if I switch to CIFS/SMB then it also gets files within seconds but I really don't want to do that.

 Any ideas why BITS jobs created by SCCM client are so slow? How can I tell to it that link is quite good and you can download faster.

Don't set the SCCM 2007 client option to Limit the maximum network bandwidth for BITS background transfers. That will slow down BITS to a crawl.

 BITS is "Not configured" on "Computer client agent" properties. 

Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\BITS doesn't have any values.

GP "Limit the maximum network bandwith for BITS background transfers" is Not configured.

At some point I configured it and put maximum transfer rate for BITS some 500kbits, but it made no difference. Speed was same, without BITS limits and with BITS limits. Always some 40-60kbits.

Have you tried to temporarily removing the BITS throttling to see if the problem vanishes?

 BITS throttling wasn't in place at first. Then I configured it and now i took it off again. It didn't have any effect on download speed. I also updated network drivers to last version yesterday, but again - no effect to speed.

Started yesterday one job and at morning its status was TRANSFERRED.
18MB and 12h download time

----------------------------------
GUID: {ADD1B985-5FCF-4461-BE8C-196561C283F4} DISPLAY: 'CCMDTS Job'
TYPE: DOWNLOAD STATE: TRANSFERRED OWNER: NT AUTHORITY\SYSTEM
PRIORITY: LOW FILES: 1 / 1 BYTES: 18128896 / 18128896
CREATION TIME: 23.01.2014 18:12:35 MODIFICATION TIME: 24.01.2014 5:31:15
COMPLETION TIME: 24.01.2014 5:31:15 ACL FLAGS:
NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 11
RETRY DELAY: 60 NO PROGRESS TIMEOUT: 2419200 ERROR COUNT: 0
PROXY USAGE: NO_PROXY PROXY LIST: NULL PROXY BYPASS LIST: NULL
DESCRIPTION:
JOB FILES:
        18128896 / 18128896 WORKING http://server:80/SMS_DP_SMSPKGE$/PRI0003A/TortoiseSVN-1.6.16.21511-x64-sv
n-1.6.17.msi -> C:\Windows\SysWOW64\CCM\Cache\PRI0003A.4.System\TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
NOTIFICATION COMMAND LINE: none
owner MIC integrity level: SYSTEM
owner elevated ?           true
This job is read-only to the current CMD window because the job's mandatory
integrity level of SYSTEM is higher than the window's level of HIGH.
Peercaching flags
         Enable download from peers      :false
         Enable serving to peers         :false

CUSTOM HEADERS: NULL
---------------------------------------------------------

Check with your N/W is there any restriction for Data transfer in your environment using the routers incase of LAN and WAN.

 There isn't such restrictions which limit http transfers to 50Kbit/sec. As I mentioned, manually I can download same file in seconds. So can BITS job if I start it maually under my account and if I start it with scheduled tasks and under SYSTEM account. But when it is started by SCCM client then it is crawling like a snail.

What does your configuration look like on the server side for bits?   

SCCM server side? BITS isn't configured for "Computer Client Agent". "ConfigMGR distribution point" properties has "Allow clients to transfer content from this distribution point using BITS, ..." marked.

 No speed limit in place on network equipment, no BITS GP policies. And otherwise BITS transfers work fine if started maually or with scheduled task. I am quite out of ideas what to check or how to replicate this slow speed in any other way. Right now it manifests itself only with SCCM client BITS jobs.

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by Ryan Br 20 hours 29 minutes ago bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by Ryan Br Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

And you've done a bits from server location to end point?  What about webdav on the server -- not sure if this is an issue on 2012 configs.  I would post the link but I'm not validated on this account yet apparently.  Webdav is a transfer protocol extension for IIS.  You can also check your IIS logs on the server to validate there are no transfer errors, though if it's moving but not failing you probably wont see an error. 

Think about it like this - if you're transferring something over bits, that's being accomplished by IIS and the first place I would probably look for problems.  It could be throttled there too.

• Edited by MrBrooks Friday, January 24, 2014 3:43 PM bad spelling

I know this is an old thread, but it's the first result when searching for help on slow BITS transfer issues.  I'm having a different issue, but I know from a lot experience that a 30 to 80 kbps transfer rate over a 100MBs Ethernet client on a 1.5Mbps circuit that there is a speed duplex mismatch issue somewhere along the line.  BITS and SMB transfers break up into a lot of small packets resulting in a lot of TCP ACK collisions and retransmit of data.  You will not see these errors on the switch when it is set to full, which is why so many network engineers are oblivious to the issue.  Do not try and manage hard setting everything to 100/Full.  You will never know what it is set to if you change it, but if you leave these settings alone across the board you can rest assured that everything is set to auto.  Hard set for your one-off exceptions and keep track of them so that their port settings can be restored to default after they are no longer needed.

As with others I realise this is an old post, but hopefully this will help someone else.

I recently had a similar issue whereby SCCM 2012 OSD downloads would not get over about 128kbps even though both client and server were on Gigabit connections on the same network.

I ran similar tests to the OP with manual BITS-Transfers which ran at an acceptable speed, yet SCCM transfers were still slow.

The key failing in this test is that while the BITS-Transfer command from Powershell utilises BITS it does the transfer using SMB but SCCM uses HTTP.

The cause was the maximum bandwidth limit in IIS>Default Site>Advanced Settings>Connection Limits had been set at about 128Kbps some time ago to prevent SCCM from flooding our slow WAN Links. Unfortunately that also affects any http downloads from this server for clients on the local LAN.

Hope this explanation helps others who find this thread when searching for answers.

 For a record, there was no IIS bandwith limit. But after many days of struggle and no results I dropped it and switched over to CIFS/SMB. As we had plan to upgrade from SCCM 2007 to 2012 and upgrade is on way right now then I didn' see reason to spend hours on this. Problem was left unsolved for me unfortunatelly.

• Edited by Markko Meriniit Friday, October 10, 2014 9:26 AM
• Proposed as answer by Garth JonesMVP, Moderator Monday, December 22, 2014 8:53 PM
• Marked as answer by Garth JonesMVP, Moderator Saturday, January 03, 2015 3:42 PM

 For a record, there was no IIS bandwith limit. But after many days of struggle and no results I dropped it and switched over to CIFS/SMB. As we had plan to upgrade from SCCM 2007 to 2012 and upgrade is on way right now then I didn' see reason to spend hours on this. Problem was left unsolved for me unfortunatelly.

• Edited by Markko Meriniit Friday, October 10, 2014 9:26 AM
• Proposed as answer by Garth JonesMVP, Moderator Monday, December 22, 2014 8:53 PM
• Marked as answer by Garth JonesMVP, Moderator Saturday, January 03, 2015 3:42 PM

 For a record, there was no IIS bandwith limit. But after many days of struggle and no results I dropped it and switched over to CIFS/SMB. As we had plan to upgrade from SCCM 2007 to 2012 and upgrade is on way right now then I didn' see reason to spend hours on this. Problem was left unsolved for me unfortunatelly.

• Edited by Markko Meriniit Friday, October 10, 2014 9:26 AM
• Proposed as answer by Garth JonesMVP, Moderator Monday, December 22, 2014 8:53 PM
• Marked as answer by Garth JonesMVP, Moderator Saturday, January 03, 2015 3:42 PM

 For a record, there was no IIS bandwith limit. But after many days of struggle and no results I dropped it and switched over to CIFS/SMB. As we had plan to upgrade from SCCM 2007 to 2012 and upgrade is on way right now then I didn' see reason to spend hours on this. Problem was left unsolved for me unfortunatelly.

• Edited by Markko Meriniit Friday, October 10, 2014 9:26 AM
• Proposed as answer by Garth JonesMVP, Moderator Monday, December 22, 2014 8:53 PM
• Marked as answer by Garth JonesMVP, Moderator Saturday, January 03, 2015 3:42 PM

SCCM server side? BITS isn't configured for "Computer Client Agent". "ConfigMGR distribution point" properties has "Allow clients to transfer content from this distribution point using BITS, ..." marked.

 No speed limit in place on network equipment, no BITS GP policies. And otherwise BITS transfers work fine if started maually or with scheduled task. I am quite out of ideas what to check or how to replicate this slow speed in any other way. Right now it manifests itself only with SCCM client BITS jobs.

Like you mentioned:

My problem was throttling under  Sites Database> Site Management> {SiteName}> Site Settings>Client Agents> Computer Client Agens

Under BITS tab

Bandwidth throttling settings between work hours was set to "21 bps", this is WAY TOO SLOW!

Someone else mentioned bandwidth settings under IIS that were correct for me but another place for a potential problem.

Thanks guys!!

-Noob to SCCM

  Little update. Problem was solved from client side by upgrading client to SCCM 2012 version. But problem exhibited itself when installing SCCM 2012 client program. Had to wait days or weeks client to install or do it manually, copy source files to local machine, which took time couple minutes, and launch ccmsetup with /source switch. Looked at network traffic at same time and found that there was same pattern as shown in picture at http://serverfault.com/questions/266764/what-causes-duplicate-ack-records . Additionally, MTU size decreased for branch office, 1400 bytes something when for headquarters internal net it is 1500. Maybe it add a little to the problem, who knows. 
  Weird thing is it shows itself only and only then when computer wiht old SCCM 2007 client initiated BITS HTTP download. If I donwloaded manually same file with IE over HTTP then there was no problems. Sure, there were retransmissions and DUP-ACK packets but no problem with speed. And if SCCM 2012 client downloaded Windows updates from SCCM server over HTTP then there was also no problem with speed. For now I can only speculate that its something to do with network equipment fragmenting packets and link being not so perfect and something with HTTP protocol handling with BITS on PC where is SCCM 2007 client.