I had fun this morning at work hunting down something highly interesting in regards to IIS7.
What was happening, is that a client had kind of.... deleted the virtual server on which a web application resided. So, it was getting redeployed to a Windows 2008 box that also performed as a SQL SERVER 2008 box.
Well, my boss deployed the application, and when he went to test, it all worked, but the reports. Every time he attempted to run a report, the only thing that came back was a "Service Unavailable" message.
He upgraded the application from .NET 1.1 to 3.5, he played with the configuration values, and a host of other things up to and including special logging just for the 503 error hiding behidn the "Service Unavailable" message.
Nothing worked. Every other piece of the application was happy, but any of the reports.
So, we get together and start trouble shooting.
First thing we do, is create a blank ASPX file that just implements a report viewer, and it still comes back as "Service Unavailable."
Well, we add another new blank ASPX file, thsi time with out even the report viewer, and it still comes back as "Service Unavailable."
Then we drop in a old-fashioned HTML file, and get... the exact same results.
One is starting to get frustrated at this point.
So, we create a new folder, and try the HTML file in it. And we get served the HTML file.
So, we copy one of the existing reports into the new folder... and it works.
Confused, we discuss things, and I had the brilliant idea that maybe, the system was expecting the RDLC files to be located in a different folder than the ASPX files that display them. After all, copying over the one report caused it to work, and that ASPX file points to the path of the RDLC file which it is designed to load.
So, we create a new RDLC folder, move the RDLC files over to it, update all the aspx files to point to the new RDLC folder, publish, test and....
get "Service Unavailable."
So, we back out of all of those changes, republish, and are still getting "Service Unavailable."
I have him rename the folder in Visual Studio and republish and...
it works.
So, we're wondering if it was just a bad compile or something. So we rename the folder back to REPORTS and republish, and upon testing get...
"Service Unavailable."
One can imagine the head banging upon wood desks that began at this moment.
Then a horrible, horrible idea came upon me: what if "reports" was a reserved word in IIS7.
Almost fearful of the results, we just change the folder name on the server from "reports" to "reporting" and it works.
One is flabbergasted.
So, we rename the folder in Visual Studio and then update all the links to the reports and republish, and it's happy as a lark. It works, spits out the report and as far as it is concerned, life is good.
Of course, neither myself nor my boss could believe that Microsoft would make the word REPORTS a reserved keyword for IIS.
The very thought is insane, but that appeared to be what was happening.
So, of course, this demanded some Google time.
Ultimately, this link was found, and it explained the reason why the REPORTS folder was giving us a 503 error.
It seems that when SQL SERVER 2008 is installed with REPORTING SERVICES, the system registered the REPORTS name with the HTTP.SYS process, which means that the request for the REPORTS folder was never actually making it to IIS.
Which explained why the ASPX page wasn't being served, and why the standard HTML file wasn't being served, in fact it explained just about everything.
The only thing it didn't explain is why on earth Microsoft would make this decision!