The Realm of the Verbal Processor

Software Distribution Failure – BITS

Ran into an interesting SW Dist issue recently. Being that this is the second time in the last couple of months that I ran into this issue, I figured it was worth a blog post.

Scenario is this…I have an application packaged in ConfigMgr and parked on a BITS enabled Distribution Point. The app is advertised to a system. When the user kicks off the program (via Run Advertised Programs), the app starts to download, but appears to hang during the download. The download never completes, and as a result the program is never executed. After a bit of poking in the ConfigMgr logs on both the client (DataTransferService.log and ContentTranferManager.log) and the server, I came up empty…the logs show that it is still in process. I finally looked at the Windows Event logs and found the following (I think it was in the System log…but it might have been Application…can’t remember):

Event Type:    Information
Event Source:    BITS
Event ID:    16384
Description:
The administrator NT AUTHORITY\SYSTEM canceled job “CCMDTS Job” on behalf of Domain\User.  The job ID was {longstringofnumbersanddashes}.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

CCMDTS = ConfigMgr Data Transfer Service. Now…why the heck is the System account cancelling the ConfigMgr BITS download? What is really problematic is that once ConfigMgr starts downloading the package, it turns over the download to BITS and waits for it to respond that the download is complete…which it never does…hence the appearance of the download just hanging.

In researching what was going on I remembered running across this type of issue once before and finding the answer in the IIS logs…remember BITS operates over IIS. In looking at the IIS logs on the Distribution Point, I found this line several times (all of the below is one line…ignore any line wrapping):

ServerIP HEAD /SMS_DP_SMSPKGE$/ABC00123/blah/file.ldf – 80 – ClientIP Microsoft+BITS/6.7 404 7 0 156

Towards the end of that line you will note the HTTP error code of “404 7”. Refer to this page for full info on all HTTP error codes, but in summary a 404.7 equates to “File extension denied”. By default an IIS7 installation will block the delivery of certain extensions and directory names…regardless of file permissions. These settings are stored in the applicationhost.config file. In this instance, the app being deployed had several required files that ended with the “.ldf” extension. To resolve it, I simply had to stop the IIS service, edit the applicationhost.config to remove the line with that restriction, then restart IIS.

I originally ran into this issue with a program that had a “bin” folder…which produced a 404.8 (hidden namespace). This thread on the ConfigMgr TechNet forums was very valuable in pointing me in the right direction.

June 23, 2010 - Posted by Jarvis | ConfigMgr