May 7 2012

SCCM package containing a plus (+) sign / symbol in a filename

I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.


When troubleshooting a package that wasn’t transferring from a SCCM DP to a BDP today, I realised that the filename had a plus (+) sign in it, eg BrushTip_+Round 10.PspScript. Bitsadmin reported:

ERROR CODE: 0x80190194 – The requested URL does not exist on the server.ERROR CONTEXT: 0x00000005 – The error occurred while the remote file was being processed.

The problem here is that with IIS requested URLs containing unencoded “+” characters in the path (not querystring) are rejected by default. Since we couldn’t rename the file, the workaround was to disable this validation by setting the allowDoubleEscaping attribute in the system.webServer/security/requestFiltering configuration section in the application’s web.config. Be aware that doing this may make your application more vulnerable to malicious URLs.



<requestFiltering allowDoubleEscaping=”true” />




See for more info.



I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.


May 4 2012

SCCM 2012 and client side BITS…

I noticed this in the SCCM 2012 product documentation update today…

Microsoft Background Intelligent Transfer Service (BITS) is required to allow throttled data transfers between the client computer and System Center 2012 Configuration Manager site systems. BITS is not automatically downloaded during client installation. Most operating systems include BITS, but if they do not (for example, Windows Server 2003 R2 SP2), you must install BITS before you install the System Center 2012 Configuration Manager client.


I think this will catch out a few people…. a good one to remember…

I think the fact that the client deployment in System Center 2012 Configuration Manager does not include BITS will catch out a few people, especially since the documentation puts this point under the ‘Dependencies External to Configuration Manager and Automatically Downloaded During Installation’ section….

See Prerequisites for Client Deployment in Configuration Manager –



March 14 2012

SCCM BDPs needing restart after client installation

I had been distibuting packages to BDPs across a few SCCM enviornments and after monitoring report 136 I noticed that there were lots of packages still ‘Waiting to install package’ even after a few days . I checked the DataTransferService.log on the problem BDPs and noticed:

DTS::AddTransportSecurityOptionsToBITSJob – Failed to QueryInterface for IBackgroundCopyJobHttpOptions. BITS 2.5+ may not be installed properly.

These BDPs were running Windows 2003 x86 SP2. KB923845 (BITS 2.5) is installed with the SCCM client agent if it isn’t already installed. It isn’t obvious, but to utilise BITS 2.5, the client will require a restart.

I can verify that this needs a restart because within WindowsSystem32, files like Bitsprx2.dll change from version before the restart to after the restart. KB923845 ( indicates that these are the files that are updated in this hotfix.

Once the BDP was restarted, the error went away and the DataTransferService, PeerDPAgent and ContentTransferManager logs all show that data is being processed again.

September 15 2011

SCCM clients not downloading content from DPs

I’d been looking at an issue where SCCM clients were constantly waiting for content from a local DP even though I had confirmed the content was present and accounted for on the local DP disk (my DP are running Windows Server 2008 R2 which is IIS 7.5). I checked the IIS logs on the local DP and found an interesting line, something like:

HEAD /SMS_DP_SMSPKGD$/APH000CC//filename.config - 80 - Microsoft+BITS/7.0 404 7 0 15

The ‘404 7’ section was interesting because this is a HTTP status code for ‘404.7 – File extension denied’ – according to

I found a few articles via Google mentioning this problem and that I should edit the %windir%System32inetsrvconfigapplicationHost.config file to allow the .config file type. This didn’t seem to fix the problem for me. After adjusting this and restarting IIS, when I looked in the IIS management GUI in the Request Filtering section, the .config extension was still blocked. I needed to change the HTTP request filters because by default in IIS 7.5 there are a list of file extensions that IIS will not provide to clients via WebDav. This included the ‘.config’ file type which I needed to deploy as part of an application package.

I didn’t want to manually do this via the GUI on all of my DPs so I used the appcmd.exe command and then restarted IIS:

%WinDir%System32InetSrvappcmd.exe set config "Default Web Site" -section:system.webServer/security/requestFiltering /-"fileExtensions.[fileExtension='.config']"

This did the trick – my clients then downloaded the content from their local DP including the previously problematic .config files.

For more info see some of these links: