See all of the top support solutions for our most common issues here
Here's an interesting issue I ran into the other day and I thought I'd post it here in case anyone happened to see it. The issue is one where if you have System Center Configuration Manager 2007 running on Windows Server 2008 R2 with WEBDAV 7.5, clients doing downloads using BITS can either appear to hang or they may just take a very long time downloading updates when your package contains many folders and files.
Note: This is actually a known issue in WEBDAV 7.x that was resolved with a hotfix in the non-R2 version of Windows Server 2008. Here is the hotfix I'm referring to:
KB957001 - A hotfix rollup is available for the out-of-band WebDAV module for IIS 7.0 : http://support.microsoft.com/default.aspx?scid=kb;EN-US;957001.
It does seem that this issue is the same as the one described in KB957001, however since we were running on IIS 7.5 the hotfix was not applicable since it is an older version than what is already is on the Windows Server 2008 R2 system.
After discussing this issue with the development team, while the issue itself is corrected in WEBDAV 7.5 it still needs to be configured.
Note: They also provided this link for more information: http://www.iis.net/ConfigReference/system.webServer/webdav/authoring
The setting that can affect the behavior we we're seeing above is the ‘maxAllowedXmlRequestLength’ attribute. It is not exposed in the User Interface but you can configure it with the appcmd.exe utility to set the PROPFIND response body to 30MB:
appcmd.exe set config "Default Web Site" -section:system.webServer/webdav/authoring /maxAllowedXmlRequestLength:31457280 /commit:apphost
By configuring this we are configuring the value above the default which is 4MB as documented in KB957001. Note that this is the XML response size, not the number of files or the size of the files.
Increasing this number to 30MB definitely improved the performance for some clients as it went from taking 8 to 12 hours to download the package to taking from 2 to 5 hours on some clients. Despite the improvement on these clients, other clients still took as long as 10 hours to download the package. As an optional workaround to increase performance further you can build your package into a single MSI file using a third party packaging tool which should offer a dramatic improvement.
Hope this helps,
Clifton Hughes | Senior System Center Support Engineer
The App-V Team blog: http://blogs.technet.com/appv/ The WSUS Support Team blog: http://blogs.technet.com/sus/ The SCMDM Support Team blog: http://blogs.technet.com/mdm/ The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/ The SCVMM Team blog: http://blogs.technet.com/scvmm/ The MED-V Team blog: http://blogs.technet.com/medv/ The DPM Team blog: http://blogs.technet.com/dpm/ The OOB Support Team blog: http://blogs.technet.com/oob/ The Opalis Team blog: http://blogs.technet.com/opalis