By now, most folks know that there are some major changes between IIS 6 (included with Windows Server 2003) and IIS 7 (included in Windows Server 2008) and now IIS 7.5 (included in Windows Server 2008 R2). This of course directly relates to and affects BITS enabled distribution points in Configuration Manager 2007 and the underlying IIS configuration because BITS on the server side is essentially a function of IIS. Actual configuration of IIS 7 and 7.5 in preparation for BITS enabled DPs is covered in TechNet: http://technet.microsoft.com/en-us/library/cc431377.aspx.
Near the bottom of the above linked page is a section that generally tells you to loosen some of the security restrictions in IIS to accommodate BITS distribution of software. This is the result of the inclusion of most of the features of the IISLockdown security tool directly into IIS. These security features prevent IIS from responding to requests using malformed URL strings, which could lead to elevated access or running commands that should not be allowed, or serving restricted content like configuration files or database files. The requestFiltering section described in the article specifically deals with the later and is the usual suspect when BITS is having issues providing content to clients. The ConfigMgr team recently posted a great article on troubleshooting the BITS process:
http://blogs.technet.com/configmgrteam/archive/2010/01/14/troubleshooting-client-content-download-in-configuration-manager-2007.aspx.
I ran into both the bin folder being blocked and the double escape sequence being blocked as described in step 6 of the above linked article. At the time though, I had no idea what was actually causing the problem. My first step was to open the IIS log on the DP and look for any errors. In reviewing the log, I noticed that many of the files were being transferred successfully as indicated by a success code of 200. However, there were numerous files failing with a code of 404 – content not found in HTTP error code terms. The only commonality for the failures I found was that the URLs contained Program+Files – checking the source files reveled that there indeed was a Programs Files folder there – BITS adds the plus to encode the space. Not being an IIS expert I didn’t know exactly how to correct this issue even though I knew what the symptoms were.
I copied the URLs into IE on a client system and received similar results, a generic 404 for the files with Program Files in their path and a download attempt on the others. Just because (call it intuition), I did the same on the DP itself and the error page returned gave me the cause of the symptoms: double 
escaping is disabled. Although I had forgotten and got a little lucky, the thing to point out here is that IIS (by default) will return extended error information to the web client (IE in this case) if the request was local to the IIS system. Thus, if you are having issues downloading content using BITS, locate the URL in the IIS log and enter it into IE on the DP itself and IIS should tell you exactly what’s going on.
In my previous post (Client = No) I mentioned that the ConfigMgr Team had recently posted a good article on client registration but I couldn’t find it. MVP extraordinaire Torsten Meringer sent me the link yesterday.
http://blogs.technet.com/configurationmgr/archive/2010/01/20/how-it-works-automatic-client-approval-in-configuration-manager-2007.aspx
Good on ya Torsten!
At my current customer we are performing a clean, side-by-side upgrade from their current SMS 2003 infrastructure. We are using client push to install the ConfigMgr 2007 SP2 agent on all client systems. Pretty smooth for the most part with two exceptions.
The first issue has to do with automatic uninstallation of the SMS client during the installation of the ConfigMgr agent. On a handful of clients (about 5% of our initial 200 in the pilot group), we were getting the following message in ccmsetup.log and then the log would stop, services.exe would jump to 50%+ CPU time, and the client install would just hang there:
RemoveW2KDrivers. Removing Remote Control drivers ccmsetup
After some web searching and only a couple of hits and some manual inspection we determined that the permissions on the registry key holding the information for SMS Remote Tools mouse driver were somehow corrupt. The exact key is HKLM\System\CurrentControlSet\Enum\Root\*SMS_MOUSE and all of its subkeys (not values). We wrote a quick for loop in a batch script to use regini to connect to every client in SMS and reset the permissions. Given the very low number of hits I got while searching for this issue, I can only conclude that it was something very unique to this environment and perhaps one of the legacy images used to deploy systems.
The second pain point has been that another handful of clients (some of the same ones) would get fully installed, find the MP properly, get assigned to the site, registered, and even start downloading policies but would never actually flip from No to Yes in the console for having the client installed. Multiple collection updates and client Data Discovery cycles changed nothing. This was a real head-scratcher for a while until I ran across an entry in the ClientIDManagerStartup.log on the client:
Smsid is missing but (re)generation is disabled.
A quick web search revealed a couple of posts relating this message to the local SMS certificates on the client system. Given that these were being upgraded from SMS, it made (some) sense that the self-signed certificates created by the SMS Agent were expired, corrupt, or in some other way unusable. Using the Certificates snap-in I deleted the two SMS certificates (located in the SMS store of the local computer account) on one of the systems and then restarted the ConfigMgr agent. During agent startup I monitored the ClientIDManagerStartup.log to verify successful registration. Once that happened, I waited a minute (or two) for prosperity and updated a collection containing the resource and low and behold, the client was now properly showing in the console. I truly have no idea what the exact cause of this issue is/was either. Unfortunately, the actual client registration process is somewhat of a blackbox and very little documentation exists for it. I thought that the ConfigMgr team had recently posted an article with some more detail, but I can’t find it right now.
The next step is automating the certificate removal for systems experiencing the same which I haven’t quite figured out yet because certutil is not native to Windows XP (yes this customer is still stuck on XP, 3,000 systems worth) and as far as I can see certutil has no remote capabilities.