For the whole of last week I was unable to readily make general use of IIS 7 on my upgraded laptop. New virtual directories I created to point to a web application did not allow me to alter the Default Document property. It kept spewing 0x80070005 E_ACCESSDENIED messages when I tried to modify it just "default.aspx" instead of the inherited list from the site root. The odd thing I noticed was virtual directories that existed when it was IIS 5.1 (winXP) could modify their Default Document just fine.
I could not search out any relevant information linking IIS 7 and that error code together, so I casted my nets across various communities hoping somebody would have a clue what is causing this odd error. Or at least tell me something extra to do that could reveal more telling evidence. I eventually got the latter.
The advice? Put on sackcloth and scatter dust on myself, pray to the Sysinternals Twin Lords Mark Russinovich and Bryce Cogswell. I asked, and I received Process Monitor v1.12. "Go", said the Help File, "apply some filters to gather all activities your process has carried out to all the ends of the operating system." So I did. Lo and behold, the startling revelation before my eyes
Operation: Create File
Result: ACCESS DENIED
Detail: Desired Access: Generic Write, Read Attribute, Disposition: Openlf ........
The site content was under source control, and being read-only, web.config was not available for modification. But why does IIS 7 want to modify web.config for a web server aspect? Because IIS 7's model of configuration has been redesigned to allow the web developer make specifications in .config files, rather than rely on the administrator perform these less-than-interesting chores to save them in the restricted metabase. I checked out the web.config file, and the modification finally proceeded without rebuke. I ordered the fatted calf be slaughtered.
I had completely forgotten about this. The new configuration interface puts the "Default Document" property icon under "HTTP Features" when in Category group view, and under "IIS" when in Area group view. Since it will never show up under the ASP.NET group, I did not make an association with web.config. IIS itself by merely buzzing "E_ACCESSDENIED", without stating what and why, certainly did not help contribute in pointing this out.
Yet another fine example of what an error message must contain - the exact cause and practical remedy steps - in order to be useful for the user to do something about it. And also testimony that getting down on your knees and calling upon the name of Mark and Bryce can indeed bring salvation to your system.