TABLE OF CONTENTS Since IIS 4.0, administrators have grown to love the metabase, whereas developers did quite the opposite. The metabase offered a complex, ID-based system, with tight security. In fact, to have write access to the metabase required that a user account have administrative privileges on the Web server. In IIS 7.0, out with the old (metabase) and in with the new (applicationHost.config, web.config) was the order of the day. IIS 7.0 built on the successful and highly popular .config infrastructure ASP.NET used to build the next-generation Web server configuration.The major items introduced to this XML configuration were the System.WebServer and the System.ApplicationHost namespaces designed to give administrators and developers a multitude of access points to configuration. IIS 7.0 also enables system administrators (Windows administrators) to delegate sections of the configuration to nonadministrators easing the burden of management on themselves. Beyond that, Web farm synchronization has never been easier than it is with IIS 7.0 s distributed configuration capabilities.
The metabase lived a long, strong, and good life. It wasn t until security, and developer productivity, came to the forefront that the metabase s shortcomings were exposed. The metabase was not architected in a manner that offered an easy, yet productive mechanism to delegate write capabilities to nonadministrator users. Furthermore, it offered undesirable child behavior not enabled at the parent level by copying the entire parent metadata to the child potentially doubling the size of the metabase. With the new configuration, called ApplicationHost.config, IIS 7.0 natively supports the IIS 6.0 configuration while also...
