Another one of my favorite features is the IIS7 Detailed Errors feature. Thomas wrote a great article titled Understanding Custom and Detailed Errors which provides a good overview of this simple, yet powerful feature. (though it needs to be updated for RC1+)
In using IIS7 the past two years, while it has been under development, I can honestly say that Detailed Errors are the single biggest help in making IIS easier to use. If you haven't read Thomas' article yet, let me summarize how Detailed Errors works:
By default IIS now returns two kinds of errors when a problem occurs. The first kind you are used to if you've used IIS before. They are our standard custom errors, which a terse error description and error code. If you don't like how our custom errors look, you can always configure IIS to return your own custom error message and away you go. The second kind of error we now call "Detailed Error" which, by default, we only return to requests from localhost. You can also configure IIS to return detailed errors all the time (if you want the application in debug mode) or to never return detailed errors - always return custom errors (if you get annoyed by our debug information).
Here is a screenshot of the administration UI for this feature, which is pretty straightforward:
Error Pages UI (click for full size image)
Note: the schema for this feature changed slightly between Beta 2 and RC1. The config section for this feature is <httpErrors> and the errorMode attribute descripes which behavior to use on the server. Here is the relevant schema:
<attribute name="errorMode" type="enum" defaultValue="DetailedLocalOnly">
<enum name="DetailedLocalOnly" value="0" />
<enum name="Custom" value="1" />
<enum name="Detailed" value="2" />
The detailed error information we return is pretty darn helpful. It includes a bunch of details about the request, like which pipeline notification the error occured during, which module and / or handler threw the error, the physical path which was processed for the request, the logon user and method (if available), and more goodies. Even better than that, we do our best to provide possible causes that lead to the error, based on the error code, sub-error code, and win32 hresult returned from the offending party. And even better, we also try to give you some help in terms of next steps you should take to resolve the problem. And last, if those don't work, we also provide a "more information" link which hooks up to our error database (not yet online) which will return the latest troubleshooting instructions we have for the particular error you've encountered! Now that is cool. Here is a sample of one particular error that I end up running into from time to time, when I type too fast and end up with invalid XML in my web.config file. Notice how it even tells me where the XML problem occured:
Server 500 Error - Vista Edition (click for full size image)
And so this is how detailed errors works, and what you can expect in Vista. One of the bits of polish we're working on for IIS7 in Longhorn Server (and will also most likely get updated in SP1 of vista) is a cleaner look for the error pages to make them easier to read. I wanted to provide a preview of the current mock-ups and ask for your feedback. What do you think, are they an improvement? What would you do different?
The same Server 500 Error - Draft for Longhorn Server Edition (click for full size image)
Here is another example of a Server 401 error. Note the "most likely cause" and "things to try" sections:
Server 401.1 Error - Draft for Longhorn Server Edition (click for full size image)
So what do you think? Are these an improvement? Leave your comments below.