ConfigMgr client problems downloading packages that include .aspx pages

Recently I have looked into an issue with package downloads freezing half way through the download and never complete. This is normally a fairly simple process of checking in the IIS logs for what file is stopping the download and then changing the applicationhost.config file to add the file extension, under requestFiltering section and set it to true (or simply change allowUnlisted to be true and remove all the pre-defined extensions completely). Unfortunately for this particular file, with a .aspx extension, this method didn’t work.

This became quite frustrating but after a bit of reading it looks like that it is actually a limitation of BITS, which is by design. The problem is that by default, IIS passes requests for certain file types to be serviced by ASP.NET. Files with extensions such as .aspx, .asmx and .ashx are mapped to the ASP.NET ISAPI extension (Aspnet_isapi.dll) which means the files are never downloaded by BITS.

Initially I was very annoyed as it seems pretty ridiculous it can’t be changed and would mean us having to edit a number of our packages. Thankfully, there is a work around though.

Within IIS, under Application Pools, there should be a SMS Distribution Points Pool and the Managed Pipeline setting will be set to ‘Integrated’. I changed this setting to ’Classic’ as the problem affects, among others, managed handlers in IIS 7.0 that are running in Integrated mode. Once we changed this setting, then ran an IISRESET, the files downloaded fine.

Obviously, you don’t want to do this on all your sites manually, so you can also this below script:

%WINDIR%\system32\inetsrv\appcmd set apppool “SMS Distribution Points Pool” /managedPipelineMode:”Classic”
IISRESET

Finally, this shouldn’t cause any other problems as ConfigMgr 2007 was designed to work with IIS 6, where only the ’Classic’ mode was available.

Thanks
Nik

Advertisements

Controlling concurrent package distribution in SCCM

I normally only write blog posts about subjects that aren’t covered particuarly well on the web or that seem, on the whole, to be misunderstood and I think this area is certainly one of them.

Recently we had some issues on one of our primary SCCM site servers, that has around 70 secondary sites, which caused a huge backlog of packages, over 3000, waiting to install. Of the many different packages that were waiting to be sent, one package was over 10GB in size and two were nearly 4GB. As you can imagine sending this much data, to 70 different sites, was taking a long time and as new packages were being distributed all the time the queue was only getting longer. Now obviously if we had left the sending capacity as default it would have eventually cleared the backlog, once the large packages had finally sent, but it was starting to affect operations as software waiting to go live couldnt, due to waiting for distribution. So we decided to crank up sending capacity.

Now I’ve always assumed the way to do this was from Site Settings > Component Configuration > Software Distribution > Distribution Point tab and there is the “Concurrent distribution settings” options, which allow you to change “Maximum number of packages” and “Maximum threads per package”.

What I have done in the past is put the “Maximum number of packages” to 7 (which is the maximum) and set “Maximum threads per package” to 10, as there is no real guidance as what this should be set at (the max is 50). Now at this point I just assumed the amount it sent would increase and think nothing else of it but this time I wanted to monitor what was being sent and to what secondary sites.To do this I used a small application that a friend of mine developed called Sender Analyser (http://www.danrichings.com/?p=90) that reads the sender.log and inteprets it to give you a list of active sending jobs. Its much easier than trying to read the sender.log, I promise you!

The results of the Sender Analyser showed the following:

and the sender.log showed this:

Both show that the Primary server was only sending 5 (out of a maximum of 5) packages to the secondary sites at any one time, even though I set both “Concurrent distribution settings” values to 7 and 10. This started me thinking whether these settings I’d changed had anything to do with site to site distribution of packages at all but were actually settings designed to control the distribution of packages to local or remote DP’s of its own site only.

To check I decided to have a look at the distmgr.log of my primary site and the first thing I noticed was this:

So the distmgr.log was allowed to process up to 7 packages at a time, exactly what I had set the”Maximum number of packages” value to. To test my theory I changed the same setting to 6 and the distmgr.log responded by showing “Used 0 out of 6 allowed…” exactly like I thought it would.

So what does this mean? Well the SMS_DISTRIBUTION_MANAGER component is mainly used to uncompress the compressed package files that are sent to it from its parent site into proper package format that can be downloaded by the clients. If the primary or secondary site has multiple servers setup as DPs in its own site, either locally or remote, this is the component in charge of copying these package files from the site server to the DP. The “Concurrent distribution settings” are the way you control how many packages and how many threads (I’m not sure if threads apply to concurrent number of servers or processor threads) it can handle at one time. What seems clear to me is that it doesn’t affect the way that packages are sent from a parent site to a child site.

So, you may be asking, how do you increase the amount of concurrent packages a parent site can send to its child sites from the, apparent, default of 5? Simple. All you need to do is change the properties for your Sender.

By going to Site Settings > Senders > Standard Sender > Advanced tab. Here is the “Maximum concurrent sendings” options, which allow you to change the maximum number of objects that can be sent to “All sites” or “Per site”:

As you will see the default for “All sites” is 5 and in our previous sender.log we saw the max sending capacity was also 5. Coincidence? No I didnt think so either, so I started increasing the “All sites” value slowly and seeing if it matched what the sender.log told me, eventually increasing it to 220. The sender.log showed this:

This quite clearly showed that the values in the “Maximum concurrent sendings” setting and the sender.log matched and this was backed up by the Sender Analyser.

The sender was now able to send nearly 50 times as many packages as the default amount and its fair to say that my package backlog didnt take long to clear! I eventually settled on “All sites” to 200 and “Per site” to 20 but the all sites capacity rarely got above 100, I guess there is something else causing the bottleneck, still that was plenty enough. Please note that I was able to use these high values due to the spec of my server, my LAN and WAN capacities, DON’T ASSUME YOU CAN USE THE SAME. I strongly recommend speaking to your network team first and slowly raising the values until you are happy.

So there we have it, if you are looking to increase the capacity to send more packages to your child sites, make sure you change the right setting 🙂