none
Clients stop downloading package and have BIT.TMP files in cache

    Question

  • I am having an issue with package distribution to sccm clients where clients stop downloading the package without any errors or warnings. and report a waiting on contents status.

     

    Initially, I noticed the issue when deploying Office 2007 to clients where I setup the advertisement for that package to start at an earlier time than the mandatory time to precache the contents.  Monitoring the advertisement status report, I noticed 10% of the clients show waiting on contents status, did random spot check, and the package folder in the cache was either there with no files just folder structure, or it had BIT.TMP files. 

    The DatatransferService.log, ContentTransferManager.log, CAS, Exec, and the package/advert related log files didn't have any errors

     

    On few clients, restarting the SMS Host service did the trick and triggered the download again, on others that didn't work; however, going to run advertised programs and manually selecting and running the program fixed the issue, on a third small group, reinstalling the client made it work.

     

    The assumption was, the package was too big, and network hick up might have caused that to occur, or IIS on the DPs had issues and was interrupted, or the client had bad BITS install and failed downloading this large package.  Later on, I found that this occurs with every deployment, small and large, and regardless of the way the advertisement is set up.

     

    Any suggestions or assistance is very appreciated

    Monday, November 03, 2008 4:22 PM

Answers

  • Hi everyone,

    I've come across this issue a couple of times and there doesn't seem to be a great deal of information on how to resolve it. Hopefully this should help people out if they are having issues.

    The problem:

    1. Client begins downloading a package and it stalls at 0% or downloads like 2% and stops. Even if left for several hours the download does not resume. No relevant errors are reported in the SCCM client logs. (Hint, for anyone new to SCCM/SMS, use Trace32 to browse your logs. Launch trace32.exe and open all logs selecting "Merge selected files". This makes it a lot easier tracking down errors).

    2. You'll see that the distribution point your client is downloading from is using HTTP. This is important as it's giving you a clue as to where the issue might be. If you open the IIS log from \\yourdistributionpoint\c$\inetpub\logs\LogFiles\W3SVC1, you'll see an entry something like this

    2009-04-21 05:21:43 <IPAddress> HEAD /SMS_DP_SMSPKGD$/APH000CC/VFS/CSIDL_WINDOWS/Installer/$PatchCache$/Managed/00002109150000000000000000F01FEC/12.0.4518/DBENGR.DLL.2.config - 80 - <IPAddress> Microsoft+BITS/7.0 404 7 0 15

    The return code is the important bit. 404.7 indicates that the file extension is blocked. This is interesting because if you look in
    %windir%\System32\inetsrv\config\applicationHost.config on your deployment server you’ll see this entry:

    <requestFiltering>
         <fileExtensions allowUnlisted="true">
             <add fileExtension=".config" allowed="false" />
              …


    You'll see that the file DBENGR.DLL.2.config has been blocked.

    Other errors you are likely to see are:

    - 404.7 (File extension denied)

    - 404.8 (Hidden Namespace)

    - 404.11 (URL Double Escaped)

    How to fix the problem:

    http://support.microsoft.com/kb/943891 and look at the resolution for each of the errors. Once you’ve made the changes, restart IIS and everything should be working fine. Download or distribute your packages again and you should see a sea of 200 return code in IIS showing that everything is working fine.

    If you have BITS enabled sites and are finding that packages do not deploy reliably to them, it is likely this is the source of the problem. AppV packages seem to be the most troublesome as they are more likely to contain a file or folder that is blocked. The problem is hard to spot as it seems inconsistent.

    Hope this helps people out

    Cheers,
    Eric. 

     

    Friday, April 24, 2009 12:28 AM
  • I've had a similar problem with this all week and just got this resolved with Microsoft. Package would start downloading to the local cache folder and then hours later I'm left with BIT*.tmp files and a WaitingContent status.

     

    My Setup:

    Server 2008, MSCCM 2007 SP1, IIS7, Vista Enterprise

     

    The problem was in the <hiddenSegments> portion of the ApplicationHost.config file. My package had a "Bin" folder nested in the setup files and I removed this line from the section:

     

    <add segment="bin" />

     

    I then restarted IIS and redeployed the package successfully.

     

    This is the KB for reference:

    http://support.microsoft.com/kb/942047/

     

    Hope this helps!

     

    Friday, November 14, 2008 9:49 PM
  • Well I as able to correct my issue.  As it turns out it was also an IIS issue.  Go figure.  Wink

     

    Anyway I found the common issue with servers that were not working was having ASP.NET registered in IIS.  The DP's that werent having teh issue did not have ASP.Net in the allowed services.  I ran "aspnet_regiis -u" on the affected servers and the package starting flowing properly again.  This apparently was not an issue with SMS 2003 as these servers were recently upgraded to SCCM but IIS remianed the same.

     

    Still trying to track down why this breaks it but for now all is working again.

    Wednesday, November 26, 2008 3:32 AM

All replies

  • I'm having the same exact issue. A client will download to cache other applications, but stalls on one particular app in the same manner Sam describes. I do not see anything peculiar in the package source.

     

    • Proposed as answer by Dhaataja Tuesday, August 04, 2015 6:47 PM
    Monday, November 03, 2008 9:10 PM
  • The package I was trying to download had files that were filtered by IIS 7.0

     

    http://technet.microsoft.com/en-us/library/cc431377.aspx

     

    To modify the requestFiltering section on BITS-enabled distribution point computers:

    1. Open the applicationHost.config file located in the %windir%\System32\inetsrv\config\ directory on the BITS-enabled distribution point site system.

    2. Search for the <requestFiltering> section.

    3. Determine the file extensions that you will have in the packages on that distribution point. For each file extension that you require, change allowed to true.

      For example, if your package will contain a file with an .mdb extension, change the line <add fileExtension=".mdb" allowed="false" /> to <add fileExtension=".mdb" allowed="true" />.

      Allow only the file extensions required for your packages.

    4. Save and close the applicationHost.config file.

    you can verify by running bitsadmin on your client and examining the log

     

    bitsadmin /list /verbose /allusers > C:\bits.log

     

    hth

    • Proposed as answer by Roy_ Thursday, April 10, 2014 3:41 PM
    Tuesday, November 04, 2008 5:36 PM
  • Thanks for the update,  to make this issue even more interesting, on some clients, restarting the SMS Host service resumes the download of the package, on others, going to Run Advertised Progras and running the package manually from there resumes the download.

     

    I am seeing this across the board with all packages, where 10% of the clients will have this issue, and the rest will cache just fine.

     

    Thursday, November 06, 2008 4:37 PM
  • Hello everyone.

    I am also having this same issue.  The package source code is as standard as any other package but this one application stalls showing the BIT.TMP files. 

    No errors in the logs, they just ...stop.  It sits at "WaitingContent".  I have been able to randomly get it installed by doing all sort of things like increment the package version to start the cache again, Hard reset the policies or Restart the service or Repair the client.  Its very random (or so it appears).

     

    Here's some log info from a machine that is currently experiencing the issue.  Note the time of the log (offset by 1 hour as the client is in carolina).  It's about 25 minutes since the last update to the log  Indifferent

     

    Here's the last entry from my Cas.log:

    Code Snippet

    Download started for content 0010009A.8 ContentAccess 11/13/2008 11:04:37 PM 1300 (0x0514)
    Raising event:
    [SMS_CodePage(437), SMS_LocaleID(1033)]
    instance of SoftDistDownloadStartedEvent
    {
     ClientID = "GUID:74BEF36B-33B6-4424-A272-E463D7D8A6CD";
     DateTime = "20081114040437.394000+000";
     MachineName = "WXXXXXXXXX";
     PackageId = "0010009A";
     PackageName = "0010009A";
     PackageVersion = "8";
     ProcessID = 3392;
     SiteCode = "P01";
     ThreadID = 1300;
    };
     ContentAccess 11/13/2008 11:04:37 PM 1300 (0x0514)

     

     

    Here's the last entry from my ContentTransferManager.log:

    Code Snippet

    Download started for content 0010009A.8 ContentAccess 11/13/2008 11:04:37 PM 1300 (0x0514)
    Raising event:
    [SMS_CodePage(437), SMS_LocaleID(1033)]
    instance of SoftDistDownloadStartedEvent
    {
     ClientID = "GUID:74BEF36B-33B6-4424-A272-E463D7D8A6CD";
     DateTime = "20081114040437.394000+000";
     MachineName = "WNCA9635P31";
     PackageId = "0010009A";
     PackageName = "0010009A";
     PackageVersion = "8";
     ProcessID = 3392;
     SiteCode = "P01";
     ThreadID = 1300;
    };
     ContentAccess 11/13/2008 11:04:37 PM 1300 (0x0514)

     

     

    Here's the last entry from the Execmgr.log:

    Code Snippet
    Execution Request for package 0010009A program Aspect_AQM_2.8_NCA_AGT_R01-Install state change from WaitingContent to WaitingContent execmgr 11/13/2008 11:04:36 PM 3148 (0x0C4C)

     

     

    Really hoping someone from Microsoft will chime in here.  I have deployed many a package and I have never seen this before.  It's a fairly significant issue.

     

    Info:

    (Standard Model)

    XP SP3, firewall Off, IE7, Symantec AV (Not showing anything in the history)

     

    Anyone else resolve this issue?

     

    Thanks!


     

    Friday, November 14, 2008 4:26 AM
  • I've had a similar problem with this all week and just got this resolved with Microsoft. Package would start downloading to the local cache folder and then hours later I'm left with BIT*.tmp files and a WaitingContent status.

     

    My Setup:

    Server 2008, MSCCM 2007 SP1, IIS7, Vista Enterprise

     

    The problem was in the <hiddenSegments> portion of the ApplicationHost.config file. My package had a "Bin" folder nested in the setup files and I removed this line from the section:

     

    <add segment="bin" />

     

    I then restarted IIS and redeployed the package successfully.

     

    This is the KB for reference:

    http://support.microsoft.com/kb/942047/

     

    Hope this helps!

     

    Friday, November 14, 2008 9:49 PM
  • Thanks for the reply.  Unfortunately (depending on how you look at it I suppose) I am not running Server 08/IIS7.  My setup is Server 2003 SP2/IIS6.  Clients are all XP Pro SP2/3.

     

    Anyone from Microsoft care to take a stab here?  If not I guess I will need to burn a case with support.  Sad

     

    Friday, November 14, 2008 11:04 PM
  • Hi Michelle,

     

    You are my hero and will definitely be mentioned in my prayers tonight....

     

    I have been tracing this problem the whole day and I cold not figure out what went wrong.

    On some computers the package could be downloaded and on others it couldn't.

     

    But after deleting the line and restarting the IIS everything is working just fine.

     

    Thanks again!

    Wednesday, November 19, 2008 4:50 PM
  • Well I as able to correct my issue.  As it turns out it was also an IIS issue.  Go figure.  Wink

     

    Anyway I found the common issue with servers that were not working was having ASP.NET registered in IIS.  The DP's that werent having teh issue did not have ASP.Net in the allowed services.  I ran "aspnet_regiis -u" on the affected servers and the package starting flowing properly again.  This apparently was not an issue with SMS 2003 as these servers were recently upgraded to SCCM but IIS remianed the same.

     

    Still trying to track down why this breaks it but for now all is working again.

    Wednesday, November 26, 2008 3:32 AM
  • Thank you all for the reply back.  I will try that and see how it works for my environment.

     

     

     

     

    Wednesday, November 26, 2008 2:52 PM
  • Hi everyone,

    I've come across this issue a couple of times and there doesn't seem to be a great deal of information on how to resolve it. Hopefully this should help people out if they are having issues.

    The problem:

    1. Client begins downloading a package and it stalls at 0% or downloads like 2% and stops. Even if left for several hours the download does not resume. No relevant errors are reported in the SCCM client logs. (Hint, for anyone new to SCCM/SMS, use Trace32 to browse your logs. Launch trace32.exe and open all logs selecting "Merge selected files". This makes it a lot easier tracking down errors).

    2. You'll see that the distribution point your client is downloading from is using HTTP. This is important as it's giving you a clue as to where the issue might be. If you open the IIS log from \\yourdistributionpoint\c$\inetpub\logs\LogFiles\W3SVC1, you'll see an entry something like this

    2009-04-21 05:21:43 <IPAddress> HEAD /SMS_DP_SMSPKGD$/APH000CC/VFS/CSIDL_WINDOWS/Installer/$PatchCache$/Managed/00002109150000000000000000F01FEC/12.0.4518/DBENGR.DLL.2.config - 80 - <IPAddress> Microsoft+BITS/7.0 404 7 0 15

    The return code is the important bit. 404.7 indicates that the file extension is blocked. This is interesting because if you look in
    %windir%\System32\inetsrv\config\applicationHost.config on your deployment server you’ll see this entry:

    <requestFiltering>
         <fileExtensions allowUnlisted="true">
             <add fileExtension=".config" allowed="false" />
              …


    You'll see that the file DBENGR.DLL.2.config has been blocked.

    Other errors you are likely to see are:

    - 404.7 (File extension denied)

    - 404.8 (Hidden Namespace)

    - 404.11 (URL Double Escaped)

    How to fix the problem:

    http://support.microsoft.com/kb/943891 and look at the resolution for each of the errors. Once you’ve made the changes, restart IIS and everything should be working fine. Download or distribute your packages again and you should see a sea of 200 return code in IIS showing that everything is working fine.

    If you have BITS enabled sites and are finding that packages do not deploy reliably to them, it is likely this is the source of the problem. AppV packages seem to be the most troublesome as they are more likely to contain a file or folder that is blocked. The problem is hard to spot as it seems inconsistent.

    Hope this helps people out

    Cheers,
    Eric. 

     

    Friday, April 24, 2009 12:28 AM
  • I ran into the same problem with my setup (SCCM 2007 SP2, SQL 2005, Server 2008 x64 (IIS7)). None of the troubleshooting steps in this post helped me so I went digging through IIS and found the problem.

    Somehow the SMS Distribution Points Pool got set to Integrated Managed Pipeline Mode instead of Classic. I set the pool back to Classic and my packages started downloading and installing.

    For those that haven't been able to fix this yet, see if this helps.
    Thursday, January 07, 2010 4:02 PM
  • Eric, you saved my day! kept banging my head against a wall seeing my package stopped downloading leaving me with BIT*.tmp files ind my cache.

    Realized I had to stop my IIS before the logs was updated, and then I saw files being blocked.

    Allowed them in the applicationhost.config and readvertised the package, and woila..

    Thanks again.

    Thursday, February 03, 2011 2:25 PM
  • I am having the same issue, but I am still working on IIS 6.0, Windows Server 2003 SP2.<o:p></o:p>

    This is a secondary site (and a Domain Controller BTW).<o:p></o:p>

    I am getting the "waiting for content" status for all of my clients in site's boundaries (which is set up correctly, just one subnet), for all advertisements.<o:p></o:p>

    Patches are working fine, but they are delivered from the main site.<o:p></o:p>

    The clients are able to download software from the primary site (one package was not copied to this DP, and the advertisement was successful), so this is definitely not a package (programs are being installed all over the company, and 19 other secondary sites have the same configuration) and not a client issue (successful patch installation, and one advert downloaded from the central site worked).<o:p></o:p>

    The client logs do not deliver any errors.<o:p></o:p>

    Any ideas where to look?<o:p></o:p>


    Tuesday, April 03, 2012 12:59 PM
  • I had this issue with my Java 1.7 package. ".config" was blocked  in the applicationHost.config causing a"Waiting for content" state on clients that had a 2008 R2 secondary site.
    Thursday, April 10, 2014 3:47 PM
  • Many thanks for this Eric; yours is a very specific and granular response with a guaranteed effectiveness as I have over the course of the past hour been able to finally resolve this issue for an SQL2012 unattend Install which had been quite grueling for me to complete earlier. 

    In my case, I had other errors which needed addressing within the applicationHost.config file and they included extensions such as .ldf and .config as well as the 'bin' folder.

    Saturday, September 27, 2014 6:49 PM
  • Hi everyone,

    I've come across this issue a couple of times and there doesn't seem to be a great deal of information on how to resolve it. Hopefully this should help people out if they are having issues.

    The problem:

    1. Client begins downloading a package and it stalls at 0% or downloads like 2% and stops. Even if left for several hours the download does not resume. No relevant errors are reported in the SCCM client logs. (Hint, for anyone new to SCCM/SMS, use Trace32 to browse your logs. Launch trace32.exe and open all logs selecting "Merge selected files". This makes it a lot easier tracking down errors).

    2. You'll see that the distribution point your client is downloading from is using HTTP. This is important as it's giving you a clue as to where the issue might be. If you open the IIS log from \\yourdistributionpoint\c$\inetpub\logs\LogFiles\W3SVC1, you'll see an entry something like this

    2009-04-21 05:21:43 <IPAddress> HEAD /SMS_DP_SMSPKGD$/APH000CC/VFS/CSIDL_WINDOWS/Installer/$PatchCache$/Managed/00002109150000000000000000F01FEC/12.0.4518/DBENGR.DLL.2.config - 80 - <IPAddress> Microsoft+BITS/7.0 404 7 0 15

    The return code is the important bit. 404.7 indicates that the file extension is blocked. This is interesting because if you look in
    %windir%\System32\inetsrv\config\applicationHost.config on your deployment server you’ll see this entry:

    <requestFiltering>
         <fileExtensions allowUnlisted="true">
             <add fileExtension=".config" allowed="false" />
              …


    You'll see that the file DBENGR.DLL.2.config has been blocked.

    Other errors you are likely to see are:

    - 404.7 (File extension denied)

    - 404.8 (Hidden Namespace)

    - 404.11 (URL Double Escaped)

    How to fix the problem:

    http://support.microsoft.com/kb/943891 and look at the resolution for each of the errors. Once you’ve made the changes, restart IIS and everything should be working fine. Download or distribute your packages again and you should see a sea of 200 return code in IIS showing that everything is working fine.

    If you have BITS enabled sites and are finding that packages do not deploy reliably to them, it is likely this is the source of the problem. AppV packages seem to be the most troublesome as they are more likely to contain a file or folder that is blocked. The problem is hard to spot as it seems inconsistent.

    Hope this helps people out

    Cheers,
    Eric. 

     

    Thanks a lot.

    I was having problems with two packages and found the problems with both of them, so thanks a lot.

    Tuesday, February 24, 2015 4:14 PM