icrosoft recently rolled out its next-generation operating system (OS), Windows Vista. One of the core Vista components is a new version of Microsoft’s web server?Internet Information Services version 7.0 (IIS 7.0). IIS 7.0 will also be part of Windows Server “Longhorn”, which is expected to ship in mid 2007. This article provides a developer-centric look at IIS 7.0.

IIS in Recent Times
If you think back a few years to IIS 5.0, the future for Microsoft’s web server looked rather bleak, because network-savvy worms such as Nimda, Code Red, Code Red II, and their variants were affecting thousands of computers worldwide, and rapidly damaging IIS’s reputation. Microsoft introduced the IIS lockdown tool to combat these exploits and, with the release of IIS 6.0, made “locked down” mode settings the default at installation, which helped minimize such security problems, and helped IIS 6.0 recapture a major part of trust that IIS 5.0 lost. No major security disasters have been reported since the release of IIS 6.0.

A recent market survey (Netcraft Web Server Survey?April 2007 ) indicated that Microsoft’s IIS has a 31.13 percent market share, which places it in second position behind the open source Apache Web Server. Another survey by Port80 Software that takes Fortune 1000 companies into consideration reports that IIS has overtaken Apache among Fortune 1000 sites.

Figure 1. IIS 7.0 Core Components: IIS 7.0 is composed of three core components.

Now, Microsoft is looking to consolidate IIS 7.0’s position as a secure and robust web server.

IIS 7.0 Core Components
IIS 7.0’s core components differ from those in IIS 6.0. IIS 7.0 is made up of three core components as illustrated in Figure 1.

• Protocol Listeners: A protocol listener listens to specific requests based on a specific protocol and sends the request to the IIS worker process for processing. Protocol listeners provided with IIS 7.0 include HTTP.sys, NET.TCP, NET.MSMQ and NET.PIPE.
• WWW Service: This service acts as a listener adapter for the HTTP.sys protocol listener and monitors the HTTP requests.
• Windows Activation Service (WAS): WAS is a new service in IIS 7.0 that manages application pool configuration and worker processes. In IIS 6.0, this responsibility was part of the WWW Service. The shift to a separate core component ensures that developers can use the same process model and configuration for both HTTP and non-HTTP based sites. It is possible to configure the other three protocol listeners (NET.TCP, NET.MSMQ and NET.PIPE) using WAS.
  

  Figure 2. IIS 7.0 Pillars: The figure shows the five major focus areas of IIS 7.0 in which Microsoft made improvements.

  For example, when the NET.TCP protocol listener is configured it listens for TCP requests. WAS can also be used to host a Windows Communication Foundation (WCF) based service.

IIS 7.0 Pillars
Apart from the change in the core components Microsoft made various changes in five major focus areas. These five areas (see Figure 2) form the pillars of IIS 7.0.

The next page provides a more detailed look at each of the five major focus areas.

Five Major Focus Areas
Security: Security is a subject that any large enterprise must consider before making the decision to adopt a particular web server. IIS 7.0 continues the security initiatives incorporated in IIS 6.0, taking them a step forward by offering a much more modular design. The new modular design splits the features/functionality offered by IIS into multiple fine-grained services that need not be installed when a specific is not required. Figure 3 below illustrates the installation options available for adding or removing a service. IIS 7 ships with more than 40 modules or services that can be added to or removed from an installation as required.

Figure 3. IIS 7.0 Role Services: From this installation dialog, you can choose from among more than 40 different modular role services that you can add to IIS 7.0.

The main advantage of the new modular design is that it helps reduce the footprint of IIS. A reduced footprint maps directly to a reduced surface area for attacks, thus making the web server more secure.

Extensibility: IIS 7.0 has a new set of public APIs that developers can use to extend IIS. Integration with ASP.NET and managed code now lets developers write modules in managed .NET code. Further, IIS sports a unified pipeline, which means that the managed modules do not need to be mapped to the ASP.NET ISAPI to participate in request processing. This means that developers now have a choice of either writing modules using managed code or using the native API to build ISAPI modules. Because IIS is highly modular it is also possible to replace any of the built-in modules with custom built modules if necessary.

Configuration: IIS configuration management has been integrated with the configuration for ASP.NET. This means that IIS also uses a web.config file for storing configuration information, and that you can deploy a specific web server configuration by simply copying the correct web.config file. In IIS 7.0, the metabase has been completely replaced with the web.config file; IIS 7.0 no longer uses the metabase repository used by earlier IIS versions for storing configuration settings.

System Management: IIS 7.0 moves away from the traditional MMC snap-in used by earlier versions and provides a new, more intuitive administrative user interface (see Figure 4) that also integrates and manages ASP.NET configuration information.

Figure 4. IIS 7.0 Management UI: The figure shows the IIS Manager application replacement for the old MMC snap-in management applet.

Figure 5. ASP.NET Session State Configuration: Here’s how the IIS Manager application looks when configuring ASP.NET Session State.

You can group the different configurable items based on categories (such as “Application Development” and “Health and Diagnostics”) or group them based on Area (such as ASP.NET and IIS). Figure 5 shows the IIS Manager while setting ASP.NET Session configuration.

Diagnostics: IIS 7.0 includes a Failed Request Tracing feature that enables web administrators to capture information related to requests that failed. You can configure failed request processing by setting up rules that set criteria for filtering and logging failed requests. The trace criteria can be configured to monitor only ASP.NET content, or only ASP content or all content as required. You can use status codes to further filter the requests and log the information. IIS 7 provides a wizard-driven interface for defining the rules. Figure 6 shows the wizard interface where you configure the status codes, while Figure 7 shows the log file after a failed request as viewed in an Internet Explorer web browser.

Figure 6. Failed Request Trace Log File: Here’s an example of creating a rule that logs failed requests for specific status codes.

Figure 7. Another Failed Request Trace Log File: Here’s how the trace log looks in Internet Explorer, viewed after a failed request.

Exploring the Runtime State and Control API
Microsoft ships a new managed API called the Runtime State and Control API (RSCA)) that provides access to runtime information from an IIS-based web server. This API provides information about the different IIS worker processes that are currently running. The API not only lets you gather state information from running processes, it also allows you to modify the state of those processes.

To use the Runtime and State and Control API you need to add a reference to the Microsoft.Web.Administration.dll file, which you’ll find on your installation drive in the WindowsSystem32inetsrv folder. Figure 8 shows the hierarchy of classes in the Microsoft.Web.Administration namespace.

Figure 8. Class Hierarchy: The figure shows the class hierarchy in the Microsoft.Web.Administration namespace.

At the top of the hierarchy is the ServerManager class. The ServerManager class can be used to access the three important aspects related to IIS?the WorkerProcess, the Site, and the ApplicationPool. An instance of ServerManager would hold collections of each of these.

The Sites collection shown in Figure 8 represents the web sites in IIS. It is possible to create new sites as well as iterate through web sites using the object model. The code snippet below illustrates how to create a new web site:

   //Create a New Site   ServerManager objServerManager = new ServerManager();   objServerManager.Sites.Add("MyNewSite",       @"C:inetpubwwwrootMyNewSite", 101);    objServerManager.CommitChanges();

The next snippet demonstrates how to iterate through all the web sites, starting any web site not already running:

   //Iterate through all Sites   foreach (Site objSite in objServerManager.Sites)   {      string strName = objSite.Name;      string strState = objSite.State.ToString();      if (objSite.State != ObjectState.Started)          objSite.Start();   }           

You use the WorkerProcesses collection to obtain a reference to any worker process running on the server. For example, to iterate through all the worker processes on a server and display the ProcessId and State properties of each worker process, you’d write code like this:

   //Iterate through all Workerprocesses   ServerManager objServerManager = new ServerManager();   foreach(WorkerProcess objWorkerProcess in        objServerManager.WorkerProcesses)   {      string strProcessId = objWorkerProcess.ProcessId.ToString();        string strState = objWorkerProcess.State.ToString();   }

The WorkerProcess can also be used to examine the requests that have been processed by a web server. The code snippet below demonstrates the usage of the API to view the requests.

   WorkerProcess objWorkerProcess = objServerManager.WorkerProcesses[0];   RequestCollection objRequests =  objWorkerProcess.GetRequests(0);   foreach (Request objRequest in objRequests)   {       MessageBox.Show(objRequest.Verb);       MessageBox.Show(objRequest.ClientIPAddr);       MessageBox.Show(objRequest.Url);         }

Finally, you use the ApplicationPools collection to access the application pools on a server. Again, you can iterate through the pools to perform various operations, such as recycling a pool. The code snippet below iterates through the AppplicationPools collection and recycles each application pool.

   foreach (ApplicationPool objApplicationPool in       objServerManager.ApplicationPools)   {      string strPoolName = objApplicationPool.Name;      string strPoolState = objApplicationPool.State.ToString();      objApplicationPool.Recycle();    }

You can download the IIS 7 Managed Module Starter Kit to get a project template and a guide to help you through your first development project.

Performance Improvements
IIS 7.0 sports performance gains due to improvements in HTTP.sys and because of the Longhorn Networking and file system improvements. Because IIS 7.0 and its corresponding server operating system (Windows Longhorn Server) are still in beta, there are no real-world benchmarks available to provide a more in-depth performance comparison or analysis. Nevertheless, the improvements and optimizations made should result in performance gains.

IIS 7.0 and Windows Editions
IIS 7.0 is available on Windows Vista and will of course be available on Windows Server “Longhorn” Operating Systems as well. Because Windows Vista is a client operating system, there are limitations imposed on IIS on that OS, including simultaneous request execution limit as well as other feature limitations. Only Windows Vista Professional (Professional Edition corresponds to Vista Enterprise, Business, and Ultimate Editions) supports all the IIS features found on the Server Edition, and even that version has a limit of no more than seven simultaneous requests.