Over the past couple of days I've been fighting with an application that a 3rd party vendor packaged for us. The package in question is an MSI that calls numerous other files. In total, the package has over 3000 files and is about 180 MB in size.
Issue
The issue that was reported to me was that the content was not downloading. My datatransferservice.log, my CAS.log, and ContentTransferManager.log all looked good. The client found a local DP to download the content from. However when I looked at my cache folder, I saw that only a couple of MB of data was downloaded and it never increased in size.
So I figured BITS was the culprit here. Unfortunately there's no good logging for BITS without doing some nasty logmon stuff. The good news is that BITSAdmin is a great utility (at least for now, according to BITSAdmin on a Windows 7 box they reference new BITS Related powershell cmdlets which I didn't find all that particularly useful).
In order to see what jobs are currently downloading, type in:
bitsadmin /list /allusers
This will give you output similar to the following:
BITSADMIN version 3.0 [ 7.5.7600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
Administrative tools for the BITS service are now provided by BITS PowerShell cmdlets.{19A1D938-E1E9-437F-882E-1BFAABB707CB} 'CCMDTS Job' ERROR 146 / 3805 4752558 / UNKNOWN
Listed 1 job(s).
Notice how in this picture I have the following line:
{19A1D938-E1E9-437F-882E-1BFAABB707CB} 'CCMDTS Job' ERROR 146 / 3805 4752558 / UNKNOWN
This is no good. This basically means there's an error somewhere in the transfer job.
Before we get into the next step of the solution, you must first understand what an SCCM distribution point is. An SCCM DP is simply a glorified web server. If you look at the Datatransferservice.log file on any of your SCCM clients, you'll see a lot of URLs that look like the following:
http://DOMAIN:80/SMS_DP_SMSPKGF$/CEN00119/System32/Redist/MS/System/msvcrt.dll
What your client is basically doing is grabbing the files from these URLs and storing them into your local cache directory underneath the package ID.
So back to BITS. Since we saw an error in our bitsadmin /list /allusers, we need to find out exactly what that error is. The following command will show just that:
bitsadmin /info {19A1D938-E1E9-437F-882E-1BFAABB707CB} /verbose > c:\bits2.txt
So what this command is doing is giving us the information about the failed BITS job that we saw before. The verbose command gives us the status of each file in the job. We then pipe this out to a file. Inside of that file, we see the following:
BITSADMIN version 3.0 [ 7.5.7600 ]
BITS administration utility.
(C) Copyright 2000-2006 Microsoft Corp.BITSAdmin is deprecated and is not guaranteed to be available in future versions of Windows.
Administrative tools for the BITS service are now provided by BITS PowerShell cmdlets.GUID: {19A1D938-E1E9-437F-882E-1BFAABB707CB} DISPLAY: 'CCMDTS Job'
TYPE: DOWNLOAD STATE: ERROR OWNER: NT AUTHORITY\SYSTEM
PRIORITY: LOW FILES: 146 / 3805 BYTES: 4752558 / UNKNOWN
CREATION TIME: 5/12/2010 11:31:04 AM MODIFICATION TIME: 5/12/2010 11:33:18 AM
COMPLETION TIME: UNKNOWN ACL FLAGS:
NOTIFY INTERFACE: REGISTERED NOTIFICATION FLAGS: 11
RETRY DELAY: 60 NO PROGRESS TIMEOUT: 2419200 ERROR COUNT: 147
PROXY USAGE: NO_PROXY PROXY LIST: NULL PROXY BYPASS LIST: NULL
ERROR FILE: http://DOMAIN:80/SMS_DP_SMSPKGF$/CEN00119/Program Files/Hummingbird/Connectivity/9.00/HostExplorer/SDK/Samples/OHIO/Visual C++ Samples/HEOhioSample/MyTabCtrl.cpp -> C:\Windows\system32\CCM\Cache\CEN00119.1.System\Program Files/Hummingbird/Connectivity/9.00/HostExplorer/SDK/Samples/OHIO/Visual C++ Samples/HEOhioSample/MyTabCtrl.cpp
ERROR CODE: 0x80190194 - HTTP status 404: The requested URL does not exist on the server.ERROR CONTEXT: 0x00000005 - The error occurred while the remote file was being processed.
DESCRIPTION:
JOB FILES:
The above shows exactly what the issue is. a HTTP status error of 404 indicates that the file cannot be found on the server. In my case, the package that I am troubleshooting has two + signs for the Visual C++ Samples folder. In this case, if I try to visit that URL (which you can do in normal situations) you get a 404, which confirms the error BITS is reporting.
To fix this issue, you need to change the path so that this folder doesn't have any special characters. In ansi, a + sign is the equivilent to a 0x2B (i.e. %2B for a URL string), however the way SCCM handles this poor. I'm not sure if this is a bug, or just by design. The vendor was the one responsible for this pathing, but I can see where some apps will have folders for their SDK that would include C++ example code.
In any event, it took 2 days to figure this one out, but thankfully I did. Luckily, the users don't need the SDK files :)
Related External Links
- Generated by LinkCurl
Related External Links
- Generated by LinkCurl