3

Certain IIS7/7.5 500.19 configuration errors only render on a browser running on the local server.

This appears to happen regardless of whether I set <httpErrors errorMode="Detailed" existingResponse="PassThrough" /> in the system.webServer section of a site's web.config file (or even globally for that matter).

For example, I had a developer who reported that he was just getting the generic IIS7 500 error page:

enter image description here

This was happening even though he had the following configured in his web.config:

<configuration>
  <system.webServer>
    <httpErrors errorMode="Detailed" existingResponse="PassThrough" />
  </system.webServer>
</configuration>

If I browse to the site on the server itself I see (some sensitive info redacted): enter image description here

Would the reason for this be that if the web.config has errors it therefore can't be parsed. Because it can't be parsed the local <httpErrors> setting doesn't get read and thus causes IIS to revert to default settings (i.e. DetailedLocalOnly)?

Update:

@LazyOne - suggested setting the above config at the server level which I already tried. This resulted in just raw 500 errors:

enter image description here

Kev
  • 7,777
  • 17
  • 78
  • 108
  • _"Because it can't be parsed the local setting doesn't get read and thus causes IIS to revert to default settings (i.e. DetailedLocalOnly)?"_ -- You can quickly test this theory by changing error response mode for the **whole** server (which is "detailed local and custom for remote" by default): IIS Manager | Error Pages | Edit Feature Settings... – LazyOne Jun 29 '11 at 15:16
  • @lazyone - see my update. – Kev Jun 29 '11 at 15:40

1 Answers1

2

Having poked around some more, I've worked out how to get 500.19 errors to appear remotely even if the site web.config is clobbered.

The trick is to set (globally) errorMode="Detailed" and existingResponse="Replace".

The existingResponse="Replace" setting is a bit counter intuitive but does make sense.

Kev
  • 7,777
  • 17
  • 78
  • 108