Whether it is an administrator struggling to meet the uptime guaranteed in a service level agreement, or a developer working to meet a delivery deadline, both developers and network administrators have wrestled with web server configuration since Microsoft first introduced Internet Information Server (IIS) many years ago. While there will still be plenty of challenges for both administrators and developers, Microsoft Windows Server 2008 has made many tasks easier by overhauling the way in which IIS 7 handles configuration. From shared configuration for web farms, to xcopy deployment there are many changes in IIS 7 on Windows Server 2008 to be excited about.

Who has server access?

The crux of the problem in prior versions was access to configuration settings. In IIS 6 and prior, only administrators on the server could make configuration changes. Many of these configuration changes were commonly requested by developers working on web applications, especially in shared server environments where developers could not gain administrative access. In IIS 7 the server configuration is based on distributed XML files that contain the settings for not only IIS, but also ASP.Net and other components. Microsoft has done away with the Metabase in favor of a much more open system. In the same way web.config files in ASP.Net applications let developers set policies based on a hierarchy, developers now get the same function in IIS configuration and even leverage the same configuration files from ASP.Net configuration. These files include the machine.config, which handles overall .Net configuration; web.config, which can be set at many levels and mostly has to do with web site configurations; and applicationHost.config, which is where global web server settings for IIS 7 are located. It is with this last file where the real changes have occurred; most of the settings available through the IIS User Interface can be set directly though the applicationHost.config or even delegated to the local web.config via settings in the applicationHost.config.

While this may seem like a small feature, this means that a developer can be granted access to their own web.config file to make changes to the settings within IIS for their particular website. There is no need to allow the developer administrator authority over the entire server just so they can change a couple of configurations settings.

Custom Shared Hosting Systems

This change has major implications for shared hosting services. Traditionally, shared hosting servers have very few settings that can be modified for customers, and many of those settings cannot be modified directly by the customer. With the implementation of IIS 7, developers will be able to change the settings for their website without having to contact their hosting provider to make the change for them.

This can dramatically reduce the time and cost of developing new web applications. As an example, imagine a developer working on a website hosted on a shared hosting server. The code is throwing an error, and the developer feels that it can be corrected by a configuration change in IIS. In systems using IIS 6, the developer will need to contact the hosting company in order to make this change. Once the host makes the change and responds back, the developer can then test the application again. If the configuration change does not correct the error, or if further changes need to be made, the developer will need to contact the hosting company again and wait for the changes to be made.