https://www.iis.net/configreference/system.applicationhost/sites/site/application/virtualdirectory

allowSubDirConfig:

• Optional Boolean attribute.
• Specifies whether IIS looks for Web.config files in content directories lower than the current level (true) or does not look for Web.config files in content directories lower than the current level (false).
• The default value is true.

The description is quite clear. Basically, IIS will stop looking for Web.config files in sub directories when allowSubDirConfig=false. Actual, it is recommended to set it to false to improve Web Application performance as explained by the article below:
https://blogs.msdn.com/b/carmelop/archive/2012/12/27/iis7-s-performance-slower-than-iis6.aspx

But one should ask what IIS is trying to find. By setting the flag to "false", does it tell IIS to ignore all the web.config files in sub directories or just settings related to IIS?
Indeed, because of the distributed nature of IIS configurations, it is possible that IIS settings being spread across multiple web.config files as described by this article:
https://www.iis.net/learn/get-started/planning-your-iis-architecture/the-configuration-system-in-iis-7

So a Web.config for a subdirectory will be accessed if one of these two conditions is true:

1. If the directory is set up as a virtual directory, rather than a subdirectory.
2. If there is a request to an aspx page, which causes asp.net to be involved. Which means that asp.net will apply the settings from <System.web> in the config file even if allowSubDirConfig=false. For settings outside of <System.web>, they will be ignored when allowSubDirConfig=false. They will also be locked out from the configuration editor in IIS manager.

Beware of these rules whenever you want to change allowSubDirConfig setting from "true" to "false" as it may affect the behavior of your website.

Cheers.

This error reappears every times you try to save the Shared Configuration Settings. To fix it, you can install the Central SSL Certificate Support role service from Server Manager like below:

If you do not wish to do that, then you have to create this key in the registry and voila:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS\CentralCertProvider

Start-CacheCluster : Error occurred while performing the operation :
ErrorCode<ERRCAdmin025>:SubStatus<ES0001>:Time-out occurred in starting the
cluster.
At line:1 char:1
+ Start-CacheCluster
+ ~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Start-CacheCluster], DataCach
   eException
    + FullyQualifiedErrorId : ERRCAdmin025,Microsoft.ApplicationServer.Caching
   .Commands.StartCacheClusterCommand

According to the AppFabric Error Code reference (https://msdn.microsoft.com/en-us/library/ff921008(v=azure.10).aspx), this is a Cache Administration timeout.  

Maybe there was so some permission issue with the DB. So I switched to using XML configuration with no luck. So what is really causing this? Another great place to look is the AppFabric Event logging located in "Application and Service Logs -> Microsoft -> Windows -> Application server - system services -> Admin"

In there one of the top error is ErrorCode<ERRCMS0011>:SubStatus<ES0001>:The host cache data size specified must be less than total physical memory.
That is! Earlier I forgot that I had decreased the size of our physical drive on the AppFabric Server. Reducing the cache size setting (less than the physical memory size)in the cluster configuration solved the issue.

https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization

While toying with it today by following the instructions in the link above, I received a nasty 500.21 error page like the one below. The "preload" functionality was working fine but the redirection to the splash page would generate the error.

Based on the error page, we can conclude that the Application Initialization configuration seems to be working at the server level. But every request during the warm up process is still being handled by a managed handler.

The "interweb" didn't yield anything (which prompted me to write this blog). So looking into my applicationhost.config in C:\System32\inetserv\config, I discovered that nowhere the warmup module is being specified. A quick way to do this is to go to the Module feature in the IIS Manager. I selected at the web site level but it shouldn't matter. In the Module feature, select "Configure Native Modules" in the Actions pane. All I have to do is to select the ApplicationInitializationModule check box and click ok (given that the feature has been installed properly). And VOILA, my splash page now shows up correctly while the warm up is in process.