[SOLVED]SCCM: Waiting (Forever) for Content

Written by Phil Schwan


You have advertised a program to a collection of computers and configured it to download to the local client cache to install, but when you check the advertisement report all you see is a bunch of “Waiting for content” as the current status. You have verified that your boundaries are set up properly and the package is fully available on the appropriate Distribution Points.

Looking at the client, the files are not downloaded to local client cache. The folder is created, but only .TMP files appear


The IIS7 implementation in Windows Server 2008 introduced several new security features, such as Request Filtering, which prevent certain files or folder structures from being accessible via BITS. This will result in BITS file transfers from the Distribution Point to the client stalling out and ultimately failing.


Assuming that removing the files or directories from the package is not an option, the Request Filter in IIS needs to be configured to allow the desired content. There are a couple ways to do this:

Edit the applicationHost.config file

The relevant settings are stored in the C:\Windows\System32\inetsrv\config\applicationHost.config file. Note that you must have rights to the C:\Windows\System32\inetsrv\config folder to make this change. Don’t assume you do just because you’re a member of the local admins group…I’ve had to explicitly grant myself permissions to this folder in order to make these changes.

The <requestFiltering> section should be about a third of the way down and will contain a list of all the commonly filtered file extensions and whether or not they are allowed. So for example if the package in question contains .MDB files and you want to allow them, simply modify the entry to set allowed=”true” to enable the transfer.

Edit the rules using the IIS Admin Tools

Alternatively, you can run the following command on the DP server (requires IIS Admin Tools). The following command for example allows the BIN folder to be a valid path for content:

C:\Windows\SysWOW64\inetsrv\appcmd.exe set config “Default Web Site/SMS_DP_SMSPKGD$” -section:system.webServer/security/requestFiltering /-hiddenSegments.[segment=’BIN’] /commit:apphost

(Obviously you may need to modify the SMS_DP_SMSPKGD$ value above if you have your package share configured for a different drive)

Another example is this command which enables “double escaping” (frequently seen with file names containing ‘+’ or other such characters):

C:\Windows\SysWOW64\inetsrv\appcmd.exe set config “Default Web Site” /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True /commit:appHost

Then reset IIS:


(Or open IIS Manager, go to Sites > Default Web Site and click Restart in the Actions pane on the right)

By default, the clients should attempt to resume their BITS transfers within about an hour.

Deep Dive:

So how do you track this down?

Most of the time you can determine the ID of the local BITS job from DataTransferService.log file:


However, the DTS log can sometimes be picky about when it displays the actual job name. The job can also be determined from client by using the BITSADMIN utility, which I recommend since you’re going to end up using that utility anyway to get the actual error that job is encountering.

To use BITSADMIN remotely, you can copy the executable to C:\windows\system32 on remote machine, then open a remote command prompt using psexec:

Psexec.exe \\remotemachine –u domain\user123 –p yourpassword cmd.exe

Once connected, run bitsadmin /list /allusers to see list of current BITS jobs:


If there is a job with an error, it will indicate it here. You can then get additional information on the BITS job by running the following command to dump it in a text file:

Bitsadmin /info {BITSJOBGUID} /verbose > C:\bits.txt

The file should give an indication as to the error encountered:


(The full text of the first line is: ERROR FILE: http://<FQDN&gt;:80/SMS_DP_SMSPKGD$/HMH0004A/Bin/Epic Print Service/ErtfValidator.exe -> C:\WINDOWS\system32\CCM\Cache\HMH0004A.2.System\Bin\Epic Print Service\ErtfValidator.exe )

In this particular case, the file to be copied to the local cache was in a /Bin subfolder, which by default was not allowed by IIS7. Following the steps outlined above, the “hiddenSegments” setting was changed to allow /Bin folders, IIS was restarted, and a resume command was issue on the client to resume the BITS job. The download completed and the program ran.

Relevant Links:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;943891 – IIS HTTP Status Codes

http://richardbalsley.com/sccm-how-to-determine-contentdownload-to-cache-issues (Using BITS Admin to track down the error)

http://support.microsoft.com/kb/942076/en-us (double escape ‘&’)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s