I've encountered this error twice in the past month, with the second time being too far into development to start over with a clean slate. So after looking into the cause and solution, I thought I'd post my findings here.
I was configuring a web server with multiple sites on it, ranging in technologies from .NET to ColdFusion to straight html. The content was moved to the server and then the various IIS sites were set up. During this second step (IIS configuration) IIS7 places a web.config file at the root of each site. The web.config file is basically a skeleton file which will contain any unique configurations you choose for the specific site (such as special Handler Mappings, etc.).
IIS will access this file whenever the web site is requested, regardless of whether the site is .NET or not, and regardless of whether the web.config contains any relevant settings for the site or not. (For example, the web.config is created even for ColdFusion sites which have their own "config" files, and IIS will consult this web.config *prior* to reading any other config files.)
Since IIS creates this web.config file, certain permissions are assumed and implemented by IIS. The 500.19 error above occurs when subsequent site configurations conflict or overwrite these permissions.
In my particular scenario, after setting up the sites in IIS and assuring that all the sites were working correctly, we began to set up the permissions we intended for user groups. The first step in this is creating Shares on relevant folders/directories. You can initiate this in one of two ways, both through the Right-click context menu. Right clicking on the target folder/directory will display both a "Share With" menu option (we'll call this option C) and the "Properties" option.
Let's first talk about the folder Properties option. Within the "Sharing" tab there are actually two ways of creating shares, the seemingly "default" option (option A in the graphic) and the "advanced sharing" option (B in the graphic). If you take a moment and go back to the "Sharing" option C mentioned above, you'll notice that it is the same as option A here, the "default" method.
In a nutshell, if you use option A or C to create a share on a root directory of an IIS site, certain permissions are automatically removed (unbeknownst to you) which make IIS unable to read the web.config file it created. In particular, these Share creation methods remove the "Creator Owner" and "Users" groups from the folder's security list (pictured below). If the folder in question is a subdirectory of the root (in which the web.config resides) the removal of these permissions may not cause any problems. But if the security items are removed from a parallel or parent directory of the web.config, the entire site will become inaccessible and the dreaded 500.19 error will display.
And of course, simply removing the problematic share will not restore the removed permissions. If you are lucky, your OS will place a tiny lock icon on the folder, indicating that certain shared properties remain in place even though all other indications suggest there is no share. That lock icon occurs *because* the Creator Owner and Users groups have been removed, and these removals will continue to block IIS's access to the web.config file.
So at this point, the only remedy (other than to remove and then recreate the site and its web.config through IIS) is to restore the security permissions for the Creator Owner and Users groups. If you have googled this problem, you will find recommendations to *add" permissions on the web.config file for the IUSR and IIS_IUSR groups. This will only partially restore what the Share creation removed, since IUSR and IIS_IUSR are members of the removed groups.
In my scenario, I opted to restore the original permissions rather than pursue a more fragmented solution of adding specific rights to specific files. Since my sites are load balanced across several servers, the more uniform (and basic) the site configurations, the better.
So this is how you can solve the problem once it occurs. But what about the inevitable situation when more shares must be created in the future? Well, fear not.
Using Share creation option B above will NOT result in the removal of these security permissions. And will not interfere with existing IIS permissions (unless you explicitly remove them).
So in the future, just remember to use the Advanced Sharing option to avoid potential headaches and wasted time.
Here's the actual error:
HTTP Error 500.19 - Internal Server Error
Description: The requested page cannot be accessed because the related configuration data for the page is invalid.
Module: IIS Web Core
Handler: Not yet determined
Error Code: 0x80070005
Config Error: Cannot read configuration file due to insufficient permissions
Config File: \\?\ C:\Inetpub\wwwroot\web.confi
Requested URL: http://localhost
Physical Path: C:\Inetpub\wwwroot
Logon User: Not yet determined
Logon Method: Not yet determined
Error code 0x80070005 can be translated to mean: "E_ACCESSDENIED - General access denied error"