Probably the most common error that is encountered with web.config and machine.config relates to capitalization. Tags and elements within both these files are case-sensitive. Tags and elements follow the naming convention referred to as camel-casing, in which the first letter of the first word of the element or attribute is lowercase, and the first letter of each subsequent word is uppercase. Attribute values are also case-sensitive, but do not follow any particular naming convention.
While the ability of applications and folders to inherit settings from parent web.config files is very convenient, it presents security implications. For example, the <appSettings> element can be used to store key/value pairs for runtime retrieval from your application. If this element is used to store values in the machine.config file, these values are available to any application on that machine. In a shared server environment, this could potentially expose information to others in undesirable ways.
Another security issue with both machine.config and web.config is how to prevent modification of inherited settings. For example, a server administrator might want to configure authentication settings globally in the machine.config file and prevent application developers from overriding these settings in their applications. This can be accomplished by using the <location> element, setting its allowOverride attribute to False and, optionally, setting the path attribute to an application path (if the locked-down settings are to apply only to a specific file or folder).
It is important to exercise caution when working with the machine.config file to avoid making changes if you are uncertain of their impact (particularly on other applications). Remember that machine.config contains configuration settings not only for all ASP.NET web applications for a given machine, but also for all .NET applications on that machine. Thus, changes to machine.config can have a broad impact. It's a good idea to back up the machine.config file before editing it, so that if your changes result in problems, you can always restore the previous copy. Another alternative is to place the machine.config file under a source code control system, such as Visual Source Safe, and require checkout of the file to make modifications. This provides the ability to roll back changes, as well as the additional ability to track who has made changes to the file.
Finally, your application is required to have a web.config file. If the default settings from machine.config (or a parent web.config) file serve your needs, then omitting this file will simplify your deployment and maintenance tasks. Use web.config only when you need to make changes to the default configuration provided by machine.config.