With Failed Request Tracing, you need to setup the rule, but as a separate step you must turn it on. In the Failed Request Tracing, check the Action pane on the right, that will have an option to enable it. That's my guess as to why the tracing isn't working.
My recommendation on any configuration in IIS7 where you have 1 site per app pool, or when all sites trust each other and the sites are stable, is to set Anonymous authentication to use the identity of the app pool. That gives you one less user to deal with. Then make sure that the app pool identity is granted permission on disk.
You mention that it doesn't work in the subfolder. It is possible to have different permissions or a different app pool used for a sub-application. Double check the app pool being used, and anonymous auth settings.
Finally, use Process Monitor as Colin suggested. Get it from www.sysinternals.com. It's free, safe to run on a production server and you'll figure it out in under 10 minutes. That will tell you exactly which user is denied access to which folder (or registry key).
That's by design. The <modules>
section of system.webServer essentially defines IIS itself. If you <clear />
, you won't be left with anything. In applicationHost.config, you should have something like this:
<modules>
<add name="HttpCacheModule" lockItem="true" />
<add name="DynamicCompressionModule" lockItem="true" />
<add name="StaticCompressionModule" lockItem="true" />
<add name="DefaultDocumentModule" lockItem="true" />
<add name="DirectoryListingModule" lockItem="true" />
<add name="IsapiFilterModule" lockItem="true" />
<add name="ProtocolSupportModule" lockItem="true" />
<add name="HttpRedirectionModule" lockItem="true" />
<add name="StaticFileModule" lockItem="true" />
...
Notice the lockItem properties. Because there are 1 or more lock items, will throw a lock violation.
So, you either need to specifically remove just the items that you don't want from web.config, or if you really need to clear them all and add back your own, then in applicationHost.config remove the lockItem="true" on each of those elements, and make sure to add enough of them back so that your web server will actually work.
Edit
(Appended further information from Daniel, per his request. (Scott))
Here is what I did based on what Scott said:
Opened applicationHost.config in %windir%\system32\inetsrv\config. Note that in 64 bit Windows Server 2008, you'll need to edit the file with a 64 bit editor (the native Notepad will do, but Notepad++ won't be able to find the file). See here for more information about this.
In the <system.webServer>
element, change the lockItem attribute on all modules to false.
In my web application's web.config file, was then able to do the following:
<system.webServer>
<modules>
<clear />
</modules>
</system.webServer>
Of course, as Scott points out, this means there's no web server left, so here is the minimum set of modules I needed to get my stuff running again (YMMV):
<add name="HttpRedirectionModule" lockItem="false" />
<add name="StaticFileModule" lockItem="false" />
<add name="CustomLoggingModule" lockItem="false" />
<add name="CustomErrorModule" lockItem="false" />
<add name="IsapiModule" lockItem="false" />
<add name="AnonymousAuthenticationModule" lockItem="false" />
Also, for anyone interested, here's the backstory as to why I'm doing this.
Best Answer
Login as an admin on the IIS server, open IIS 7 Manager, the open the Asp icon under the Web site you want to change the error messages for (it'll be on the right with all the other icons; it's the first one).
Scroll down and change Send Errors To Browser to True. Might have to
iisreset
, not sure.