Bummer to hear this is messing up your Christmas. Hopefully this will help (and though it's Christmas morning, I had time to offer this reply. Sorry that it's lengthy, but if it was an easy problem to solve, you wouldn't be struggling so.)
The problem is almost certainly the previous configuration of IIS done by CF8 (or CF9). This is nearly ALWAYS a problem when you try to put CF10 or above on a machine that had CF9 or earlier.
There are two things you can check, to confirm what’s amiss. (Fixing these can be a good bit more challenging.) The first is about mime types (and the possibility of their being an AIR mime type). The second is about handler mappings and/or isapi filters (and the possibility that there are left over CF8 mappings that need to be removed). I suspect the latter is why you’re seeing the challenge you are (where you feel you need to configure “every site”.) Let me explain both, as usually both happen if one does.
It’s also important (for solving this problem) to understand some aspects of how IIS configuration works (in terms of the files where the configuration works, and the inheritance mechanism IIS uses).
Some people understand only 1 or 2 of the 3 things above, or find resources only explaining one of the three or only very briefly, and they “try to fix things” and find that it “doesn’t work”, and they wonder why CF doesn’t work, and how anyone ever can get things working…So it takes time to explain things. Hope you’ll stick with me to the end here.
1) First, if you look in IIS at the site that is not working, and you open the “mime types” feature for that site, it will likely list hundreds in alphabetical order. Is there one for “.air”? If so, that’s something from CF9 and before that is nearly always not needed (unless you serve up Adobe AIR apps from that web site).
How do you solve that? Well one way is that you could remove that from the site, and see if things work. For some problems, that is all that is needed.
The other way to solve this problem, if you know that you don’t need the “.air” mimetype for ANY sites, is you could probably remove it from the top-level (server-level), which also has a “mime types” feature. If you remove it from there, and find that it IS gone from the site in question (and better if you find it gone from all sites that you check), then the setting was only there, and was being inherited by all the rest. If that’s it, great.
But if you remove it from the server level, but still find it at the site level, then it means your old CF version (or someone) defined it at the site level. In that case, you would need to remove it from the site level (and all site-level mime type features where it may still exist).
2) BTW, if you may be interested in resolving this by modifying instead the underlying IIS xml config file that controls this, it either be defined either in the web.config of the root of some or all web sites, or it could be defined in the server-wide applicationhost.config (found in C:\Windows\System32\inetsrv\Config). The web.config file would override whatever is in the applicationhost.config. And within that file, there are also a set of elements that represent things at the server level (setting the default for all sites), and then optionally a set of elements at one or more site levels. More on that in a moment, as it’s very commonly a much bigger challenge when one moves from CF9 or before to CF10 or above, on the same machine.
3) The second, common problem is about handler mappings. If you look in IIS for the site in question, at the “handler mappings” feature, do you see any cfm file handlers that point to your CF8? Or if you look at its “isapi filters”, is there one for CF8? If there is, then you want to remove those (any isapi filters pointing to 8, and any and all handler mappings pointing to cf8). But again how you would do that depends on IIS configuration settings and its inheritance.
First, look at the server level, and see if there were either CF8 isapi filters and/or handler mappings there. If so, if you remove those from there, do they then disappear also from the site in question (indeed, all sites)? If so, then great. Test your site. Does it work? If so, great.
If not, then you would need to next check things at the site level, and remove it/them from that site.
And if that’s the case, then THAT’s why you found that it was not enough to just run the CF2016 web server config tool. It only can configure things for “all sites” (which means configuring the server-level settings, presuming things are not over-ridden at any site levels), or it can configure them at each site’s level.
Either way, even that tool may not help if the problem is that you have still CF8-versions (or if someone else had CF9 versions) of the isapi filter and/or handler mapping settings. It doesn’t know to remove those for you.
4) Worse, and the most cause of the kind of challenges you’re describing, is that you may find if you dig into the IIS applicationhost.config file that CF8 had created a separate duplicate settings for EVERY site (this is NOT the way CF10 and above would do it, and they don’t check to see if you previously had that).
Look toward the bottom of the file, and see if there is a “location path” XML element (with possibly several dozen handler elements) for each of many (or all) sites. If so, it’s that the CF8 connector has (or CF9 would have also) duplicated ALL the handlers elements--the handler mappings for each file extension.
The difference is that your CF2016 web connector tool (or anyone with CF10 and above would find that it) instead configures only what it presumes is needed for “all sites” to be configured—it has put in the handlers elements for CF files at the TOP level XML element (the one for location path=””, for “all sites”), while all these subsidiary “locations paths” (one for each site) are STILL pointing the sites to CF8.
I’m not saying this is DEFINITELY your problem, but I have seen it dozens of times over the years.
5) So how would one (who understood and confirmed all the above) fix things? Well, if all the handler elements within each of those lower-level handler elements was confirmed to be identical to each other (and identical to the one at the top level, for “all sites”, at least before the CF10, 11, or 2016 values were added), then all those lower-level handler sections can be removed. THEN the top-level ones will be inherited. Same for the isapi filters.
If they are NOT all identical (at the site level within the applicationhost.config), then instead one would have to surgically remove each of the CF8 handler mappings from each site. Really, though, it's almost always as important to remove the duplicates of all the other mappings. It just is very challenging. (Removing any duplicate isapi filters at the site level within the file should be a good bit easier.)
If all that sounds overwhelming, I will say that I can take your applicationhost.config file and look for and remove the problems above, in likely less than an hour. (Unfortunately, these things can’t be easily modified in an automated fashion…or at least such a tool would need to be quite aware of these possibilities and flexible enough to anticipate and handle all the variabilities.)
6) One last thing: this might possibly have been resolved if before you installed CF10 or above (and before uninstalling CF9 or below), you had run the web server config tool (in your case for CF8) to first REMOVE all the configuration it had done. That MIGHT have set things back to a nice starting point, but in truth many people over the years (since CF8 came out over 10 years ago) have done lots of manual tweaks to get things working, so that even that step might not have gotten things back to a good "square one".
Hope that helps. (And the complexity should explain why you won’t find this to be well-discussed elsewhere.)
/charlie
/Charlie (troubleshooter, carehart.org)
48
Replies
AdChoices