Two attributes come handy when you need to enforce settings in your hosting environment: overrideModeDefault and allowDefinition. Trying to override settings when these attributes are used may cause users to see HTTP Error 500.19.
Let’s say you don’t want anybody to change the default document. Use overrideModeDefault attribute in the applicationHost.config as the example below.
<sectionGroup name="system.webServer">
<section name="defaultDocument" overrideModeDefault="Deny" />
</sectionGroup>Looking for a way to ignore web.config files in application subfolders? Check this post out.
HTTP Error 500.19
If an application owner tries to set the default document in a web.config file, this error message will appear:
HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.
In this case, if you try to change the default document via IIS Manager, you will receive this error message:
There was an error while performing this operation.
This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.
Choose which configuration files can override settings
If you want to specify which configuration file can edit which tags, use allowDefinition attribute.
For example, let’s say you want to allow server-level configuration and deny application-level configuration. In your applicationHost.config file:
<sectionGroup name="system.webServer">
<section name="defaultDocument" overrideModeDefault="Allow" allowDefinition="MachineToWebRoot" />
</sectionGroup>When an application owner tries to set the default document in a web.config file, the error message below will appear.
Configuration section can only be set in machine.config or root web.config
The reason behind is that we specified MachineToWebRoot in allowDefinition attribute. It means that only machine.config, applicationHost.config, and root web.config file (the one in the same folder as machine.config) can override this setting.
Here are other values you can use withallowDefinition attribute (Source):
| “Everywhere” | The section can be defined in any configuration level. The default value. |
| “MachineToApplication” | The section can be defined in the Machine.config or ApplicationHost.config file. |
| “MachineOnly” | The section can be defined only in the Machine.config file. |
| “MachineToWebRoot” | The section can be defined in the Machine.config, ApplicationHost.config, or Web.config file. The Web.config file is stored in the Web site root. |
| “AppHostOnly” | The section can be defined only in the ApplicationHost.config file. |
Prevent machine.config to be overridden
For preventing machine.config settings to be overridden by child web.config files, you can use location tag with overrideMode attribute. For example:
<location path="" overrideMode="Deny">
<system.web>
…
</system.web>
</location>Please note that the changes in the machine.config affect all the applications in the web server. So that make sure to test changes in development environment first.
Error “Absolute physical path is not allowed”
One of the error messages 500.19 status code is associated is this: “Absolute physical path is not allowed in system.webServer/httpErrors section in web.config flie. Use relative path instead”. Error code: 0x8007000d
This error is expected when there is an in-place upgrade from 2008 R2 to 2012 R2 because absolute paths are not supported in 2012 R2 and newer versions by default.
In order to solve this error, add allowAbsolutePathsWhenDelegated=”true” to httpErrors section in the applicationHost.config file:
<httpErrors allowAbsolutePathsWhenDelegated="true" errorMode="Custom" lockAttributes="allowAbsolutePathsWhenDelegated,defaultPath">Make sure to reset IIS and test the website after this change.