Over the years, the structure of IIS has undergone several changes. IIS 7.0, which is the most recent edition of it, is quite different from IIS 6.0. However, though the code base has been completely rewritten, most of the concepts are still the same.

A marking difference that any newbie would note about IIS 7 is its modular structure. Let me take you across the basic architecture of IIS 7 through this article.

This will get you an idea about the following areas:

• Basic architecture of IIS 7
• New configuration structure of IIS 7 (Various configuration files and its uses)
• Modular structure of IIS 7
• HTTP Request Processing in IIS 7.0

The basic functionality of the IIS web server is broken into 3 parts.

If you are familiar with IIS 6, then you will notice that the basic structure of IIS 7 is same as that of IIS 6. The major difference lies in the implementation of the worker processes. Even though the application pools executes requests independently, the way in which the worker processes handle the requests is entirely new.

In the new architecture, every piece of functionality that was earlier handled by the worker process is now delegated to a module which can be enabled or disabled as per our wish.

By default, IIS includes more that 40 individual modules. You can create a perfectly functional web server with a handful of default modules.

IIS 7 allows the services that are provided by both native and managed modules to apply to all requests, with no regard to the handler.

We will come back to this with a simple example of enabling modules per server and in sites. For the time being, I will focus on the configuration changes in IIS 7 with respect to its earlier editions.

In IIS 6, ASP.NET was included as an ISAPI filter and its requests exited the pipeline, to be processed by the aspnet.dll (ASP.NET processing pipeline). It was then returned to the core IIS processing pipeline for further processing.

In the architecture of IIS 7, ASP.NET plays a much larger role that ever before. Here the ASP.NET processing pipeline is included with the core IIS processing pipeline. The performance of ASP.NET is also improved, since the ASP.NET application does not need to exit the pipeline and then load the ISAPI process in order to handle the ASP.NET requests. This tight integration of ASP.NET means that, its specific features such as authentication can be now used with any kind of files, such as HTML, Perl etc.

The decision that led to the new configuration structure was a battle between IIS and ASP.NET. In the end, the IIS development team decided to make ASP.NET configuration structure as a new standard. The old metabase configuration structure is now replaced with the XML based method. This is indeed a welcome change for those who are familiar with ASP.NET. The bottom line is that the web.conf files of the websites and the applications now control both IIS and ASP.NET configuration.

By now, you should be familiar with the configuration structure of IIS7. Let me now explain the modular structure of IIS 7 with a simple example of enabling / disabling modules per server and on site basis.

Suppose, I am configuring a web server capable of hosting only plain old HTML web sites and I do not want to host any sites which needs application processing. In this case, I need to only enable the following modules.

• StaticFileModule – It provides the access to the file system.
• AnonymousAuthenticationModule – It defines the user credentials that are needed to access the file system.

In addition to these 2 modules, I am also enabling following two:

• DefaultDocumentModule – It adds the default document to the incoming request URL, when a document name is not explicitly requested.
• StaticCompressionModule – It is to reduce bandwidth usage while accessing images and static content.

In the new architecture, every piece of functionality that was earlier handled by the worker process is now delegated to a module which can be enabled or disabled as per our wish.

Let’s now see how we can achieve the configuration task.

  Start off by creating a backup of the system configuration.

 %windir%\system32\inetsrv\appcmd add backup original

  You can restore the configuration to its original state by executing the following command.

 %windir%\system32\inetsrv\appcmd restore backup original

  Open %windir%\system32\inetsrv\config\applicationhost.config. Find the section for HTTP modules and replace the contents with the following:

<modules>
<add name=" StaticFileModule" />
<add name="AnonymousAuthenticationModule" />
<add name="DefaultDocumentModule"/>
<add name="StaticCompressionModule"/>
</modules>

  Now, restart the IIS service.

The customization that we have just displayed will affect the entire webserver. However, it is rare to see all the websites on a given server have identical functional requirements. But, it is possible to customize the module configuration for individual websites. If you need to configure a website to load only StaticFileModule, AnonymousAuthenticationModule and DefaultDocumentModule, do the following:

Create a web.config file in the web root of the site with the following contents:

<? xml version="1.0" encoding="UTF-8?>
<configuration>
     <system.webserver>
          <modules>
             <clear/>
            <add name=" StaticFileModule" />
            <add name="AnonymousAuthenticationModule" />
            <add name="DefaultDocumentModule"/>
            </modules>
      </system.webserver>
</configuration>

NB: By default, the worker process of this website will inherit all the modules from the <modules> section of applicationhost.config file. The <clear/> tag will block the inheritance of the default <modules> configuration that is defined in applicationhost.config file.

By now, you should be having a fair understanding of the configuration structure and modular nature of IIS 7. Let’s now check out the request processing in IIS 7. We can briefly illustrate it as follows:

• HTTP.sys intercepts the incoming HTTP request.
• The HTTP.sys contacts WAS( Windows Activation Service) to obtain the information from the configuration store (applicationHost.config)
• WAS obtains the configuration information from the applicationHost.config.
• The WWW Service receives the configuration information which includes the application pool and site configuration.
• The WWW Service then configures HTTP.sys using this configuration information.
• The WAS then starts the corresponding worker process to which request was made.
• The worker process is responsible for processing the request and giving the response to HTTP.sys.
• The response is then sent back to the client.

The main benefits of integrating the ASP.NET runtime with the core web server in IIS 7 are as follows:

• It allows the services that are provided by both native and managed modules to apply to all requests, with no regard to the handler.
• It empowers the ASP.NET components to provide functionalities that was previously unavailable to them because of their placement in the server pipeline.
• It provides a single place to implement, configure, monitor and support server features.

I hope this article has helped you get familiarized with IIS 7 and also in devolving an interest to learn more about it.. So, now get started with IIS 7.0, which provides you a secure, easy way to manage web platforms for reliably hosting rich web applications and web services.

About the Author :

Hari Vishnu, Software Engineer has been working with Bobcares for more than an year now. He has expertise in both Windows and Linux server Administration, and he is considered to be a master when it comes to Windows servers. Apart from the technical side, he has gained a reputation as a gifted stage performer too.