IIS 6.0 and ASP.NET, Part 1

IIS 6.0 is the next generation of Web server available in the Windows Server 2003 platform. IIS 6.0 provides several enhancements over IIS 5.0 that are mainly intended to increase reliability, manageability, scalability, and security. IIS 6.0 is a key component of the Windows Server 2003 application platform, using which you can develop and deploy high performance ASP.NET Web applications, and XML Web Services. In this series of articles, we will take a look at the new features of IIS 6.0 such as new scalable HTTP request processing architecture, the ability to store IIS configuration settings in XML file, improved reliability by means of application pools, and so on. We will also demonstrate how to create effective ASP.NET Web applications that can leverage the features of IIS 6.0. Along the way, we will also illustrate the changes in the security model of IIS 6.0 and how they affect your ASP.NET applications. In Part 1 of this article, we will look at the steps to follow to install IIS 6.0 and then understand how to host ASP.NET applications in IIS 6.0. We will also review the different isolation modes of IIS 6.0 and how they impact ASP.NET applications.

Introduction

A new generation of Web applications puts a greater demand on performance and scalability attributes of Web servers. For example, the Web server is expected to increase the speed at which HTTP requests are processed, but still allowing more applications and sites to run on one server. This also means that very few servers are needed to host a site, allowing the existing hardware investments to sustain longer while being able to handle greater capacity. Another important aspect of the Web server is its reliability. IIS 6.0 has been designed from the ground up to allow us to create reliable applications. For example, in IIS 6.0, you can isolate each application or Web site to run in its own process space. By doing this, you can ensure that applications are isolated and problems in one site do not affect the rest of the applications on the same server.

IIS 6.0 Architecture

Before we take a look at IIS 6.0's architecture, let us take a moment to understand the IIS 5.0 architecture. In IIS 5.0, there was only one main process, represented by the executable inetinfo.exe, that was designed to function as the main Web server process, which could route requests to one or more out-of-process applications that are running within the dllhost.exe. With this architecture, Inetinfo.exe is the master process through which each request must traverse regardless of isolation mode. IIS 5.0 had three isolation modes: In-Process, Out-of-process, and Pooled. In the In-Process mode, all the applications run in the same process as that of the Web server (inetinfo.exe). The IIS 5.0 default mode is Pooled, in which the Web server (Inetinfo.exe) runs in its own process and all other applications will run in one single-pooled process (dllhost.exe). You can set high-priority applications to run as Isolated, which creates another instance of dllhost.exe. Even though this out-of-process isolation allows you to increase the fault-tolerance of your Web server, it is slow in terms of performance. The Pooled mode is the best performance/isolation tradeoff, but there is only one pool on a server and all pooled applications must use the same pool.

In this section, we will look at the architecture of IIS 6.0 to understand the compelling features provided by IIS 6.0 that contribute to the increase in scalability, reliability, and manageability.

IIS 6.0 has been totally re-designed with a new request processing architecture that has the benefits of high isolation without incurring the out-of-process cost, as well as much higher levels of reliability and scalability. You can split the main components of IIS 6.0 into the following two broad categories.

• HTTP.SYS—HTTP.SYS is a kernel-mode HTTP listener that listens for incoming requests and queues those requests up on the appropriate queue. Each request will be serviced by one application pool. An application pool in IIS 6.0 can contain one or more applications. Another important thing to note is that no third-party code can run in HTTP.SYS, improving the stability of the Web server.
• WAS (Web Administration Service)—WAS is a user-mode configuration and process manager. The Web Administration Service component performs the following two operations: Configuration and Process Management. Again, no third party is allowed here. When the Web server is first initialized, the WAS configures HTTP.SYS and the application pools. It is also responsible for monitoring and controlling the lifetime of the worker processes. To this end, the WAS also can perform activities such as health monitoring of processes, recycle worker processes automatically based on admin set criteria, start and stop worker processes, and so on.
• Application Pool—Application pools are used to manage a set of Web sites and applications. Each application pool corresponds to one request queue within HTTP.sys and the one or more Windows processes that process these requests. IIS 6.0 can support up to 2,000 application pools per server, and there can be multiple application pools operating at the same time. For example, a departmental server might have HR in one application pool and finance in another application pool. An Internet Service Provider (ISP) might have the Web sites and applications of one customer in one application pool, and the Web sites of another customer in a different application pool. Application pools are separated from other application pools by Windows Server 2003 process boundaries. Therefore, an application in one application pool is not affected by applications in other application pools, and an application request cannot be routed to another application pool while being serviced by the current application pool. Applications can easily be assigned to another application pool while the server is running.
• Worker Process—A worker process services requests for the Web sites and applications in an application pool. All Web application processing, including loading of ISAPI filters and extensions, as well as authentication and authorization, is done by a new WWW service DLL, which is loaded into one or more host worker processes. The worker process executable is named W3WP.EXE.

Benefits of the IIS 6.0 Request Processing Architecture

The IIS 6.0 request processing architecture explained in the previous section delivers very high levels of reliability without sacrificing performance. Especially,

• Increased reliability—IIS 6.0 worker process isolation mode prevents Web sites and applications from affecting each other or the server as a whole.
• Fewer server restarts—The user will likely never need to restart the server or shut down the entire WWW service, due to a failed application or common administration operations, such as upgrading content or components, or debugging Web applications.
• Increased application availability—IIS 6.0 supports auto restart of failed applications and periodic restart of misbehaving applications, or applications with faulty code.
• Increased scalability—IIS 6.0 supports scaling to ISP scenarios, where there may be hundreds to thousands of sites on a server. IIS 6.0 also supports Web gardens, where a set of equivalent worker processes on a server each receive a share of the requests that are normally served by a single worker process.
• Strong application platform support—IIS 6.0 supports the application as the unit of administration. This includes making the application the unit of "robustness" by enabling application isolation, and also enabling resource throttling and scaling based on the application.

In the following section, we will illustrate the procedures for installing IIS in your Windows 2003 Server.

Installing IIS 6.0

Once you install Windows server 2003, by default, only the necessary components of the operating system will be installed, meaning that you need to explicitly install the required components such as IIS 6.0. You can install IIS 6.0 using either one of the following two options:

• Configure your Server wizard—To configure your server as an application server, you use the Configure your Server Wizard that can be found in the Manage Your Server->Add or Remove Roles option.
• Add/Remove Components option in Control Panel—Using this option, you can install the necessary components such as IIS 6.0, ASP.NET, COM+, and MSMQ. This option has an added advantage in that it gives more granular control over the specific sub-components that will be installed.

Creating a new ASP.NET Web Application in IIS 6.0

Now that you have installed IIS 6.0, let us go ahead and create a new ASP.NET application using Visual Studio.NET 2003. Open up Visual Studio.NET 2003, and select the File->New Project dialog box and specify information as shown in the following screenshot.

Click here for a larger image.

Once you click OK on the above screen, you will see the following message box that says ASP.NET applications are locked down in IIS.

Click here for a larger image.

In the case of IIS 5.0, once you install IIS, it is ready to serve up all static (such as HTML pages) as well as dynamic content (such as ASP pages). But now in IIS 6.0, installation alone is not enough. You need to explicitly configure IIS to allow specific types of applications such as ASP, ASP.NET, CGI, ISAPI, and so on to be created on the server. To enable ASP.NET Web applications, you need to use the new feature called Web Service Extensions in IIS Manager, which we will look at in the following section.

Enabling ASP.NET Applications in IIS

But, when you install IIS 6.0, it is installed in a highly secure and locked mode, meaning that IIS serves only static content, and dynamic content such as ASP, ASP.NET, and so on are not enabled. To enable dynamic content, you need to use what is known as Web Service Extensions and modify the settings in IIS Manager. A Web Service Extension is nothing but a specific type of handler that is used to handle requests for a specific type of dynamic content. For example, requests for ASP.NET pages are processed by a handler, ASPNET_ISAPI.dll. If you want to allow ASP.NET pages to be served up from your Web server, you need to explicitly allow this handler, using the Web Services Extension from IIS. Using the Web Service Extensions feature that is accessible through the IIS manager, Web site administrators can enable or disable IIS 6.0 functionality based on the individual needs of the organization. This functionality is globally enforced across the entire server. Apart from the graphical interface, IIS 6.0 also provides programmatic, command-line, and graphical interfaces for enabling Web service extensions. To enable Web service extensions, select Web Service Extensions node from the IIS Manager. This will result in all the Web service extensions being displayed in the listview on the right side of the screen.

Click here for a larger image.

To enable a specific Web service extension, select the Web service extension, right-click it and select Allow from the context menu. Once you enable the Web service extension, the value of the Status column in the listview changes to Allowed from Prohibited. Because we want to allow ASP.NET applications on the server, select the Web Service Extensions ASP.NET v1.1.4322 from the list, and right-click it to select Allow from the context menu. This is illustrated in the above screenshot. When you upgrade your ASP applications to run in IIS 6.0, you may need to evaluate what Web service extensions need to be enabled. Enabling all of the Web service extensions ensures the highest possible compatibility with your existing ASP and ASP.NET applications. However, enabling all of the Web service extensions creates a security risk because it increases the attack surface of IIS by enabling functionality that might be unnecessary for your server. When you right-click the Web Service Extensions node in the IIS manager, the context menu displays a number of options that allow you to perform this. This is shown in the following screenshot.

Click here for a larger image.

Now that you have enabled ASP.NET Web Service Extensions from IIS Manager, if you go back to Visual Studio.NET and create the ASP.NET Web Application project again, you will find that the project is created properly.

Different Modes of Operation Available in IIS 6.0

IIS 6.0 has two modes of operation:

• Worker Process Isolation Mode—This is the native mode in IIS 6.0, in which all application code is run in an isolated environment, but without the performance penalty of previous IIS Versions. HTTP requests are routed through the kernel-mode driver (HTTP.SYS) to the correct application pool queue. User-mode processes that are serving an application pool directly pull the requests from HTTP.SYS and eliminate the unnecessary process hops encountered when having to send a request to an out-of-process DLL host and back again.
• IIS 5.0 Isolation Mode—This mode allows you to ensure compatibility for applications developed using IIS 5.0. In this mode, HTTP.SYS works similar to the Worker Process Isolation mode except that it routes requests only to a single request queue that is maintained by the WWW service. Then, depending on how the isolation is configured (in-process, out-of-process, or pooled), the request will be either processed in inetinfo.exe or dllhost.exe. In this mode, features such as application pooling, recycling, and health detection features are not available.

To configure the appropriate IIS operation mode for your Web server, right-click the Web Sites folder from the treeview and select Properties from the context menu. Then, navigate to the Service tab in the Properties dialog box. In this window, you can modify the mode by selecting the checkbox that is right next to the Run WWW service in IIS 5.0 isolation mode option. This is illustrated in the following screenshot.

Click here for a larger image.

Once you select this option, the Applications Pools node in the IIS manager treeview will no longer be available because you can't configure application pools when running your server in IIS 5.0 isolation mode. In the next section, we will see how these different modes of isolation impact the version of the .NET Framework that is used to service all the applications running on that particular server.

Configuring IIS 6.0 to Use the Correct Version of the ASP.NET

When migrating your existing ASP.NET applications to run in IIS 6.0, you may need to install the .NET Framework version 1.0 on the target server to ensure that the applications continue to function properly. As you might recall, by default, when you install IIS 6.0, it also installs .NET Framework, version 1.1. After you manually install version 1.0 of the .NET Framework, both version 1.0 and 1.1 of the .NET Framework are available on the target server. This is referred to as side-by-side installation.

Even after installing the .NET Framework version 1.0, you will find all the ASP.NET applications running on the server still use version 1.1 of the .NET Framework. If you want your ASP.NET applications to use the .NET Framework version 1.0, you need to run IIS in IIS 5.0 isolation mode because, by default, IIS 6.0 runs in Worker Process Isolation mode. This means that your ASP.NET applications can only use version 1.1 of the .NET Framework. In most cases, your existing ASP.NET applications will function correctly with version 1.1 of the .NET Framework. When your ASP.NET application is incompatible with version 1.1 of the .NET Framework, configure the application to use version 1.0 of the .NET Framework. To accomplish this, you need to run IIS in IIS 5.0 isolation mode.

It also is possible for you to configure each ASP.NET application to use a specific version of the .NET Framework by registering a script map in IIS for the application. A script map associates a file name extension and an HTTP verb with the appropriate ISAPI for script handling. For example, when IIS receives a request for an .aspx file, the script map for the corresponding application directs IIS to forward the requested file to the appropriate version of the ASP.NET ISAPI for processing. The script map for each ASP.NET application can be applied directly to an application, or inherited from a parent application. However, ASP.NET supports only one version of the .NET Framework for each application pool.

Impact in ASP.NET Configuration Settings

The configuration method for ASP.NET is determined by the application isolation mode that you use to configure IIS 6.0. When you run IIS in Worker Process Isolation mode, you must use the IIS Manager to make changes to the ASP.NET configuration settings. If you are running your IIS in IIS 5.0 Isolation mode, you must use machine.config to make changes to the ASP.NET configuration settings. When IIS 6.0 is configured to run in IIS 5.0 isolation mode, the .NET Framework uses the <processModel< section of the machine.config file (in the <Drive Name>:\systemroot\Microsoft.NET\Framework\versionNumber\Config folder) for its configuration and no additional steps are required. However, when IIS 6.0 is configured to run in worker process isolation mode, the .NET Framework ignores the <processModel> section of the machine.config file, and instead gets its process configuration from the IIS 6.0 Metabase.

Conclusion

In Part 1 of this article series, we have understood the new request processing architecture of IIS 6.0. We also illustrated the steps for installing IIS, and then how to enable ASP.NET applications using the Web Service Extensions. We also demonstrated how to configure IIS to use the appropriate version of the .NET Framework. In Part 2 of this series, we will see how to leverage application pools to increase the reliability of ASP.NET Web applications.

About the Author

Thiru has six years of experience in architecting, designing, developing and implementing applications using Object Oriented Application development methodologies. He also possesses a thorough understanding of software life cycle (design, development and testing).

He is an expert with ASP.NET, .NET Framework, Visual C#.NET, Visual Basic.NET, ADO.NET, XML Web Services and .NET Remoting and holds MCAD for .NET, MCSD and MCP certifications.

Thiru has authored numerous books and articles. He can be reached at thiruthangarathinam@yahoo.com.

# # #