Beginners Guide: How IIS Process ASP.

NET Request
This article describes how the IIS process clients requests and responses. Introduction When request come from client to the server a lot of operation is performed before sending response to the client. This is all about how IIS Process the request. Here I am not going to describe the Page Life Cycle and there events, this article is all about the operation of IIS Level. Before we start with the actual details, lets start from the beginning so that each and everyone understand it's details easily. Please provide your valuable feedback and suggestion to improve this article. What is Web Server ?

When we run our ASP.NET Web Application from visual studio IDE, VS Integrated ASP.NET Engine is responsible to execute all kind of asp.net requests and responses. The process name is "WebDev.WebServer.Exe" which actually takw care of all request and response of an web application which is running from Visual Studio IDE. Now, the name Web Server come into picture when we want to host the application on a centralized location and wanted to access from many locations. Web server is responsible for handle all the requests that are coming from clients, process them and provide the responses.

What is IIS ? IIS (Internet Information Server) is one of the most powerful web servers from Microsoft that is used to host your ASP.NET Web application. IIS has it's own ASP.NET Process Engine to handle the ASP.NET request. So, when a request comes from client to server, IIS takes that request and process it and send response back to clients.

Request Processing :

Hope, till now its clear to you that what is Web server and IIS is and what is the use of them.

Now lets have a look how they do things internally. Before we move ahead, you have to know about two main concepts 1. 2. Worker Process Application Pool

Worker Process: Worker Process (w3wp.exe) runs the ASP.Net application in IIS. This process is responsible to manage all the request and response that are coming from client system. All the ASP.Net functionality runs under the scope of worker process. When a request comes to the server from a client worker process is responsible to generate the request and response. In a single word we can say worker process is the heart of ASP.NET Web Application which runs on IIS. Application Pool: Application pool is the container of worker process. Application pools is used to separate sets of IIS worker processes that share the same configuration. Application pools enables a better security, reliability, and availability for any web application. The worker process serves as the process boundary that separates each application pool so that when one worker process or application is having an issue or recycles, other applications or worker processes are not affected. This makes sure that a particular web application doesn't not impact other web application as they they are configured into different application pools.

Application Pool with multiple worker process is called Web Garden. Now, I have covered all the basic stuff like Web server, Application Pool, Worker process. Now lets have look how IIS process the request when a new request comes up from client. If we look into the IIS 6.0 Architecture, we can divided them into Two Layer 1. 2. Kernel Mode User Mode

Now, Kernel mode is introduced with IIS 6.0, which contains the HTTP.SYS. So whenever a request comes from Client to Server, it will hit HTTP.SYS First.

Now, HTTP.SYS is Responsible for pass the request to particular Application pool. Now here is one question, How HTTP.SYS comes to know where to send the request? This is not a random pickup. Whenever we creates a new Application Pool, the ID of the Application Pool is being generated and its registered with the HTTP.SYS. So whenever HTTP.SYS Received the request from any web application, it checks for the Application Pool and based on the application pool it send the request.

So, this was the first steps of IIS Request Processing. Till now, Client Requested for some information and request came to the Kernel level of IIS means at HTTP.SYS. HTTP.SYS has been identified the name of the application pool where to send. Now, lets see how this request moves from HTTP.SYS to Application Pool. In User Level of IIS, we have Web Admin Services (WAS) which takes the request from HTTP.SYS and pass it to the respective application pool.

When Application pool receive the request, it simply pass the request to worker process (w3wp.exe) . The worker process w3wp.exe looks up the URL of the request in order to load the correct ISAPI extension. ISAPI extensions are the IIS way to handle requests for different resources. Once ASP.NET is installed, it installs its own ISAPI extension (aspnet_isapi.dll) and adds the mapping into IIS. Note : Sometimes if we install IIS after installing asp.net, we need to register the extension with IIS using aspnet_regiis command.

When Worker process loads the aspnet_isapi.dll, it start an HTTPRuntime, which is the entry point of an application. HTTPRuntime is a class which calls the ProcessRequest method to start Processing.

When this methods called, a new instance of HTTPContext is been created. Which

is accessible using HTTPContext.Current Properties. This object still remains alive during life time of object request. Using HttpContext.Current we can access some other objects like Request, Response, Session etc.

After that HttpRuntime load an HttpApplication object with the help of HttpApplicationFactory class.. Each and every request should pass through the corresponding HTTPModule to reach to HTTPHandler, this list of module are configured by the HTTPApplication. Now, the concept comes called HTTPPipeline. It is called a pipeline because it contains a set of HttpModules ( For Both Web.config and Machine.config level) that intercept the request on its way to the HttpHandler. HTTPModules are classes that have access to the incoming request. We can also create our own HTTPModule if we need to handle anything during upcoming request and response.

HTTP Handlers are the endpoints in the HTTP pipeline. All request that are passing through the HTTPModule should reached to HTTPHandler. Then HTTP Handler generates the output for the requested resource. So, when we requesting for any aspx web pages, it returns the corresponding HTML output. All the request now passes from httpModule to respective HTTPHandler then method and the ASP.NET Page life cycle starts. This ends the IIS Request processing and start the ASP.NET Page Lifecycle.

Conclusion

When client request for some information from a web server, request first reaches to HTTP.SYS of IIS. HTTP.SYS then send the request to respective Application Pool. Application Pool then forward the request to worker process to load the ISAPI Extension which will create an HTTPRuntime Object to Process the request via HTTPModule and HTTPHanlder. After that the ASP.NET Page LifeCycle events starts. This was just overview of IIS Request Processing to let Beginners know how the request get processed in backend. If you want to learn in details please check the link for Reference and further Study section.

Beginner's Guide: Exploring IIS 6.0 With ASP.NET

Table of Contents

Introduction What is a Web Server Introduction to IIS o Overview of IIS o IIS Version in Different OSs o How to Install IIS 6.0 IIS 6.0 Process Model and Request Processing Deploying Your Web Sites on IIS o Creating a Virtual Directory o Configuring a Virtual Directory Virtual Directory Documents ASP.NET Directory Security Custom Errors Application Pool o How to Create an Application Pool

Create a New Application Pool Create from an Existing Configuration File o Configure Application Pool Properties Recycling What Happens During Application Pool Recycling Performance Health Identity Debugging Your Application That is Hosted on IIS Summary My IIS Articles @ CodeProject Reference and Further Study Points of Interest History

Introduction
In the past, I have written a few articles for beginners and had got a very good response from all readers. This time I have planned to write an article on IIS 6.0 and Integration of IIS with ASP.NET. I have worked on IIS 5.1, IIS 6.0, and IIS 7.0. Though the purpose of all IIS servers are the same, they are very different in their architecture and use. Don't worry, I am not going to explain the differences of those three versions of IIS. The purpose of this article is completely different. While answering in the ASP.NET forum, I found many questions on deploying websites, the security settings of IIS, different authentication types, Application Pool, recycling of application pool, etc. This is an "All in One" article for IIS. This will help beginners know what IIS is, how to install IIS, how to deploy sites on IIS, create an Application Pool, web garden, etc. This article is all about IIS 6.0. If anybody is interested in IIS 7.0, please read the article Deploying ASP.NET Websites on IIS 7.0. Please give your valuable suggestions and feedback to improve this article.

What is a Web Server

Visual Studio has its own ASP.NET engine which is responsible for running your web application so you don't have any problems running an ASP.NET application from the VS IDE. When you want to host your site for others to access, the concept of a "Web Server" comes into picture. A web server is responsible for providing a response to requests that come from clients. So when multiple users come in, multiple requests also come in and the web server will have a response for each of them. IIS (Internet Information Server) is one of the most powerful web servers from Microsoft that is used to host ASP.NET web applications. IIS has its own ASP.NET Process to handle ASP.NET requests. If you look at this picture:

IIS Server Overview

The first client will make a request to the web server (IIS), the web server checks the request and will pass the request to the ASP.NET Process (don't get confused here, I have explained the details), the ASP.NET process engine will process the request and pass the response to the client via the web server. One of the major roles of IIS is handling each and every request. Don't worry, I have explained each and everything in more detail later. So far I hope it is clear why we are using a web server.

Introduction to IIS
IIS 6.0 provides a redesigned World Wide Web Publishing Service architecture that can help you achieve better performance, reliability, scalability, and security for your web sites. In this section, I have described an overview of IIS and an installation guide for IIS 6.0.
Overview of IIS

Internet Information Server is one of the most powerful web servers provided by Microsoft that is able to host and run your web applications. IIS supports the following protocols: FTP, FTPS, SMTP, NNTP, HTTP/HTTPS. We can host our web sites on IIS, we can use it as an FTP site also. For more information, click here.
IIS Version in Different OSs

Below is a list of IIS versions that support the following Oerating Systems:
Operating System Windows Windows Ultimate Windows Windows Windows Server 2008 Vista - Home Premium/ Server 2003 XP Professional 2000 Server IIS 5.0 IIS Version IIS 7.0 IIS 7.0 IIS 6.0 IIS 5.1 IIS 5.0

How to Install IIS 6.0

Installation of IIS is very similar to installing any other system application from the Control Panel. We have to start navigation from Control Panel > Add/Remove Programs, then select Add/Remove Windows Component. Follow the screen given below.

IIS installation

Select "Application Server" from the checkbox list. This will open a new window, select IIS, and click on OK.

IIS installation selection

This will initiate IIS installation. The OS will show a continuous progress bar during installation and will show a final message after installation is complete.

IIS installation progress

Note: During the installation period, it may ask for some OS files. You need to provide the paths for them. After successful installation of IIS, go to Start > Run > Inetmgr to launch IIS. The below screen will appear, which indicates that IIS has been successfully installed in your system.

IIS installed successfully

IIS 6.0 Process Model and Request Processing

Before starting with a virtual directory and Application Pool and all other stuff, let us have a quick look into the IIS 6.0 Process module and IIS request processing. This topic is a huge one. Here I am just giving you an overview. We can divide the whole architecture into two layers.

Kernel Mode o HTTP.SYS User Mode o Web Admin Service o Virtual Directory o Application Pool

IIS 6.0 Process module

As per the above diagram, IIS has two modes, Kernel and User. HTTP.SYS is the heart of kernel mode which accepts raw requests from the client and pass it to a particular application pool. Below are the steps of IIS request processing.
1. Client requests for a page from the browser by hitting the site URL. 2. Request comes to kernel level. HTTP.SYS catches the requests and creates a separate queue for each and every application pool.

Note: Whenever we create an application pool, IIS automatically registers the pool with HTTP.SYS to identify it during request processing. Then HTTP.SYS forwards the request to the Application Pool.
3. A request coming to the application pool means the worker process (w3wp.exe) starts action by loading the ISAPI Filter. 4. Based on the requested resource, w3wp.exe loads "aspnet_isapi.dll" for an APSX page and starts an HTTPRuntime which is the entry point of an application. 5. Then the HttpRuntime.ProcessRequest method signals the start of processing. 6. The HttpContext object represents the context of the currently active request, as it contains references to objects you can access during the request lifetime, such as Request, Response, Application, Server, and Cache. 7. The HttpRuntime creates a pool of HttpApplication objects. 8. The request passes through the HTTP Pipeline. 9. HTTP Modules are executed against the request until the request hits the ASP.NET page HTTP Handler. 10.Once the request leaves the HTTP Pipeline, the Page life cycle starts.

If you want to know the details of IIS request processing, I will suggest you read the article ASP.NET Internals: Request Architecture.

Deploying Your Web Sites on IIS

In this section, I discuss how to host a site on IIS, how to create a virtual directory, configure a virtual directory, etc. Let's start with virtual directory creation.
Creating a Virtual Directory

There are various way to host a web application on IIS. Visual Studio has some inbuilt features to host and create a virtual directory on IIS directly. Here is one of my articles on hosting a site on IIS from Visual Studio. But in this section, Idiscuss the basic steps for creating a virtual directory. First, right click on Default web sites > New > Virtual Directory.

Virtual directory creation

By selecting "Virtual Directory...", the virtual directory creation wizard will start. Click on "Next".

Virtual directory creation

Give the "Alias" name and proceed for "Next". The alias name is your virtual directory name.

Virtual directory creation

As its name implies, a "virtual directory" does not contain any physical file. We need to define the physical file path that it will refer to. We have to browse the physical path over here.

Virtual directory creation

Now based on your requirements, you can select the check boxes and click on "Next". Generally, we select only the "Read" option.

Virtual directory creation: Permission settings

Below is a list of permissions that we can use:

Read: It is the most basic and is mandatory to access webpages of your application. Run Scripts: It is required for ASPX pages, not for static HTML pages because ASPX pages need more permissions so they could conceivably perform operations. Execute: This allows the user to run an ordinary executable file or CGI application. This can be a security risk so only allow when it is really needed. Write: It allows to add, modify, or remove files from the web server. This should never be allowed. Browse: This allows one to retrieve a full list of files in a virtual directory even if the contents of the files are restricted. It is generally disabled.

You are done! The virtual directory has been created successfully. You will get a final message. Click on "Finish" to close the window and move forward.

Virtual directory creation: Finish

There are other alternative options that you can use for creating a virtual directory.
1. Copy the physical directory to the wwwroot folder. 2. Physical Folder Properties > Web Sharing. Configure Virtual Directory

The items listed below are very important for the configuration of any web application.

Virtual Directory Documents Documents ASP.NET Directory Security Custom Errors

I have explained each of them step by step. Apart from them, a Virtual Directory can have settings like BITS Server Extension, HTTP Header, etc. I haven't covered those in this article. Let us start with the "Virtual Directory" tab.
Virtual Directory

This is the most important configuration section for a virtual directory. To open this tab, we need to select the newly created virtual directory.

Virtual directory configuration

Right click on it > Properties. The below screen will come up:

Virtual directory properties

Here we can change the local path (physical path). Before looking into other stuff, first look into the "Application Settings" section. It seems the application name is disabled. So first we need to click the "Create" button, which will enable the rest of the settings. Check the below image.

Virtual directory creation

Here we can change the execution setting and application pool name. Choosing "None" for Execute Permission will restrict the access to the web site. Now we will move to the "Documents" tab.
Documents

The Documents tab is used to set the default page of your web application. We can add or remove the page name in this section. To configure, we have to move to the "Documents" tab.

Virtual directory creation

This is useful when you want to access the site directly with the virtual directory name. For example, if your virtual directory name is "mywebsite" and your home page name is "home.aspx", then you can access the page as follows:
Collapse | Copy Code
http://<ip>/mywebsite/home.aspx

but if you define home.aspx in the Documents section, you need to only use this at the address bar to access the site:
Collapse | Copy Code
http://<ip>/mywebsite

ASP.NET

If IIS is registered with multiple .NET Framework versions, the ASP.NET version dropdown list shows all of them. But based on the application, we need to change the framework version. E.g.: If our application was developed in .NET 2.0, then the version should be 2.0.X.X.

ASP.NET version selection

Tip: If .NET Framework is already installed in your system when you are installing IIS, then ASP.NET will not be registered with IIS. So if you host an application on IIS, it will not work. To register IIS with the ASP.NET version, you need to run the aspnet_regiis -i command from the command prompt. This will automatically register the .NET Framework with your IIS. For more info, please read this.
Directory Security

Directory security enables all kinds of security access for your web application. For directory, we need to move to the "Directory Security" tab.

Directory security settings

Click on the "Edit" button to modify the directory security settings. After clicking on the Edit button, the below screen will come up.

Directory security settings

Below are the commonly used IIS security settings:

Anonymous Integrated Windows Authentication Basic Authentication Digest Authentication

Anonymous

Anonymous authentication means the site is accessible to all. This is the default authentication mode for any site that is hosted on IIS, and it runs under the "IUSR_[ServerName]" account. We can change it by clicking on the "Browse" button.
Integrated Windows Authentication

This authentication mode is generally used for Intranet sites. Users are authenticated from the Active Directory. Integrated Windows authentication is also known as NTLM authentication. If browser settings automatically login for trusted sites for Windows authentication then the site will be logged in automatically with the Windows user credentials.
Basic Authentication

This is supported by all browsers and is a part of the HTTP standard. This shows a login dialog control which accepts the user name and password. The user ID and password are passed to IIS to authenticate the user from the Windows credentials.
Digest Authentication

The disadvantages of Basic authentication mode is that it sends a password as plain text. Digest authentication does almost the same thing as basic authentication but it sends the "hash" of the password rather than sending plain text.

Integrated Windows, Basic Authentication, and Digest Authentication use Active Directory to authenticate the user. Note: There are many things related with IIS and ASP.NET Security configuration. I am not covering all these in detail. I am just giving a brief overview so that you are comfortable with all this stuff. For configuring SSL, please read the reference link that I have provided in the References section.
Custom Errors

The Custom Errors tab allows us to specify the error page that will be displayed for any specific type of HTTP Error.

Directory security settings

We can also customize the setting at our application level by configuring the web.config settings or changing the htm file path by clicking on the "Edit" button. This is all about the basic overview of creation of virtual directories and setting up. Hope you are now comfortable with all this stuff.

Application Pool
Application pool is the heart of a website. An Application Pool can contain multiple web sites. Application pools are used to separate sets of IIS worker processes that share the same configuration. Application pools enable us to isolate our web application for better security, reliability, and availability. The worker process serves as the process boundary that separates each application pool so that when a worker process or application is having an issue or recycles, other applications or worker processes are not affected.

Application pool - IIS

Generally we do it in our production environment. The main advantages of using an application pool is the isolation of worker processes to differentiate sites and we can customize the configuration for each application to achieve a certain level of performance. The maximum number of application pools that is supported by IIS is 2000. In this section, I have discussed about the creation of application pools, application pool settings, and assigning an application pool to a web site.
How to Create an Application Pool?

Application pool creation in IIS 6.0 is a very simple task. There are two different ways by which we can create an application pool. There is a pre-defined application pool available in IIS 6.0, called "DefaultApplicationPool". Below are the two ways to create an application pool:

Create New Application Pool Create From Existing Configuration File

Create a New Application Pool

First of all, we need to open the IIS Configuration Manager. Then right click on Application Pool and go to New > Application Pool.

Create new application pool

The below screen will appear, where we need to mention the application pool name.

New application pool name

When we create a new application pool, we can use the default application setting for it. The selection of "Default Settings" means by default the application pool setting will be the same as the IIS default settings. If we want to use the configuration of an existing application pool, we need to select the section option "Use existing application pool as template". Selecting this option will enable the application pool name dropdown.

Application pool template selection

If we select an existing application pool as a template, the newly created application pool should have the same configuration of the template application pool. This reduces the time for application pool configuration. That is all about creating a new application pool. Now let us have a look at the creation of an application pool from an existing XML configuration file.
Create From Existing Configuration File

We can save the configuration of an application pool into an XML file and create a new application pool from that. This is very useful during the configuration of an application pool in a Web Farm where you have multiple web servers and you need to configure the application pool for each and every server. When you are running your web application on a Load Balancer, you need to uniquely configure your application pool. So first of all, you need to save the application pool configuration in a server. Check the below image for details.

Application pool template selection

During this operation, we can set the password for the configuration file which will be asked during the import of the application pool on another server. When we click on "Save Configuration to a file", the below screen will appear.

Save configuration as XML file

Where we need to provide the file name and location. If we want, we can set a password to encrypt the XML file. Below is a part of that XML:
Collapse | Copy Code
Location ="inherited:/LM/W3SVC/AppPools/StateServerAppPool" AdminACL="49634462f0000000a4000000400b1237aecdc1b1c110e38d00" AllowKeepAlive="TRUE" AnonymousUserName="IUSR_LocalSystem" AnonymousUserPass="496344627000000024d680000000076c20200000000" AppAllowClientDebug="FALSE" AppAllowDebugging="FALSE" AppPoolId="DefaultAppPool" AppPoolIdentityType="2" AppPoolQueueLength="1000" AspAllowOutOfProcComponents="TRUE" AspAllowSessionState="TRUE" AspAppServiceFlags="0" AspBufferingLimit="4194304" AspBufferingOn="TRUE" AspCalcLineNumber="TRUE" AspCodepage="0"pre>

Now we can create a new application pool for this configuration file. While creating a new application pool, we have to select the "Application Pool ( From File )" option as shown in the below figure.

Application pool creation from a configuration file

When we select this option, a screen will come where we need to enter the file name and the password of that file.

Application pool creation from configuration file

Select the file and click on the "Read File" button. This will show you the imported application pool name. Click "OK" to import the full configuration.

Application pool creation from configuration file

Here we need to mention the new application pool name or we can have another option where we can replace an existing application pool. For moving ahead, we need to provide the password.

Password to import application pool configuration

This is the last step for creating a new application pool from an existing configuration file.
Configure Application Pool Properties

This is one of the most important tasks for web server configuration and this is important when we are hosting on a production server. As I have already discussed, the application pool is the heart of any web application hosted on IIS. We need to know each and every configuration of the application pool. To start configuration, we need to go to the Properties of the application pool.

Application pool properties

We need to configure the following things in the application pool:

Recycling Performance Health Identity

Recycling

Recycling the application pool means recycling the worker process (w3wp.exe) and the memory used for the web application. It is a very good practice to recycle the worker process periodically, which wll keep the application running smooth. There are two types of recycling related with the application pool:

Recycling Worker Process - Predefined settings Recycling Worker Process - Based on memory

Recycling Worker Process - Predefined Settings

Worker process recycling is the replacing of the instance of the application in memory. IIS 6.0 can automatically recycle worker processes by restarting the worker processes that are assigned to an application pool and associated with websites. This improves web site performance and keeps web sites up and running smoothly.

Application pool recycling- Worker process

There are three types of settings available for recycling worker processes:

In minutes Number of requests At a given time

Recycle Worker Process (In Minutes)

We can set a specific time period after which a worker process will be recycled. IIS will take care of all the current running requests.
Recycle Worker Process (Number of Requests)

We can configure an application with a given number of requests. Once IIS reaches that limit, the worker process will be recycled automatically.
Recycle Worker Process (In Minutes)

If we want to recycle the worker process at any given time, we can do that configuration on IIS. We can also set multiple times for this.

Application pool recycling - Worker process: Time setting Recycling Worker Process - Based on Memory

Server memory is a big concern for any web application. Sometimes we need to clean up a worker process based on the memory consumed by it. There are two types of settings that we can configure in the application pool to recycle a worker process based on memory consumption. These are:

Maximum virtual memory used Maximum used memory

Application pool recycling - Worker process.

At any time, if the worker process consumes the specified memory (at memory recycling settings), it will be recycled automatically.
What Happens During Application Pool Recycling

This is quite an interesting question. Based on the above settings, an application pool can be recycled any time. So what happens to the users who are accessing the site at that time? We do not need to worry about that. This process is transparent from the client. When you recycle an application pool, HTTP.SYS holds onto the client connection in kernel mode while the user mode worker process recycles. After the process recycles, HTTP.SYS transparently routes the new requests to the new worker process.
Performance

Moving to the Performance tab in the Properties dialog box results in the following output.

Application pool performance

To improve the performance of a web application, we can setup the performance settings of the application pool. We can set the shut down time of the worker process based on the ideal time. The worker process will be shut down at a given time period if it is ideal. Whenever a new requests comes, it will live again. Another important thing for improving the performance is "Web Garden".
Web Garden Overview of Web Garden

By default, each application pool runs with a single worker process (W3Wp.exe). We can assign multiple worker processes with a single application pool. An application pool with multiple worker processes is called a Web Garden. Many worker processes with the same application pool can sometimes provide better throughput performance and application response time. And each worker process should have its own thread and memory space.

Web Garden (Application pool with multiple worker processes)

As Shown in the picture, in IIS Server, there may be multiple application pools and each application pool has at least a single worker process. A Web Garden should contain multiple worker processes. There are certain restrictions in using a Web Garden with your web application. If we use Session Mode as "in proc", our application will not work correctly because the Session will be handled by a different worker process. To avoid this, we should use Session Mode as "out proc" and we can use "Session State Server" or "SQL-Server Session State".
How to Create a Web Garden?

We need to increase the number of worker processes on the Performance tab.

Web garden creation

Main advantage: The worker processes in a web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue processing the requests.
Health

Now we move to the "Health" tab. When wel select the "Health" tab, it will show the following screen:

Health monitoring setting

IIS provides a couple of settings to improve the health of an application pool. There are also a few settings for measuring the worker process health. These are:

Enable Pinging Enable Rapid-fail protection Startup time limit Shutdown time limit

Enable Pinging

This property specifies whether the WWW Publishing Service should periodically monitor the health of a worker process. Checking this option indicates to the WWW service to monitor the worker processes to ensure that worker processes are running and healthy. By default, it sets to 30s. This is also needed to check if a service is staying ideal or not. If it is ideal it can be shutdown until the next request comes. The Windows Activation Process maintains all this stuff.
Enable Rapid-fail Protection

When enabling Rapid Fail Protection, the application pool is shut down if there are a specified number of worker process crashing within a specified time period. When this happens, the WWW Publishing Service puts all applications in the application pool "out of service". Failure Count: The default value for failure count is 5 minutes. This property specifies the maximum number of failures allowed within the number of minutes specified by the "Time Period" property before the application pool is shut down by Rapid Fail Protection. If the number of failure is more than the specified in a given time, the application pool should be put on "out of service mode". Time period: This property specifies the number of minutes before the failure count for a process is reset. By default, it is set to 5 minutes.
Startup time limit

The Start up time limit property specifies the amount of time that the WWW Publishing Service should wait for a worker process to finish starting up and reporting to the WWW Service. In general it means the time taken to start a worker process.
Shutdown time limit

This is the shutdown time for a worker process. This is the time required to execute all old running worker process requests before it shuts down during recycle time.
Identity

This is the last and final setting for an application pool. An application pool has three types of identity: "Network Service" is the default Identify. "defaultappPool" also runs under the "Network Service" Identity. Below are the listed application pool identities with description:

Identity

Description A built-in account that has administrative privileges on the server. It can access both local and remote resources. For any kind accessing LocalSystem of server files or resources, we have to set the Identity of the application pool to Local System. Built-in account has privileges of an authenticated local user LocalServices account. It does not have any network access permission. This is the default Identity of an application pool. NetworkServices NetworkServices has privileges of an authenticated local user account.

Navigating to the Identity tab will show the following screen:

Application pool identity configuration

We can also configure the application pool under a given user account. For that, we need to select the "Configurable" option on "Identity" tab. This is all about the application pool. Hope now you have a very good understanding on what application pool is, how to create and configure the application pool. Q: You are using a file upload control in your web application and it is working fine on Visual Studio but when you host the same code on IIS, it is not working. This is a very common problem in web hosting when file upload is involved. A: When a web application runs under Visual Studio - ASP.NET engine integrated with visual studio takes care of all the executions. And this engine has sufficient rights so that it can write data on your disk. But when you host the site on IIS, as I have already mentioned, it runs under the "Network Services" Identity, which has very minimum rights on your system. The user can only have read access on the site. So for resolving file upload issues, you need to change the Identity of the application pool from "Network Service" to "Local System". Local System identity means the client can have write access on your hard drive. This will resolve your issue of file uploading on the server. You can also resolve this issue by giving Write access permission to the file destination folder for "Everyone".

Enabling Web Service Extension

IIS 6.0 provides a certain type of configuration from where we can enable/disable web service extensions. If we want to prohibit/restrict any kind of extension, we need to select the extension and click on the "Prohibit" button.

Web Service extension vonfiguration

Note: If the ASP.NET v 2.0.X.XXXX extension is prohibited over here, you will not be able to access the site which is running on .NET 2.0.

Debugging Your Application That Hosted on IIS

If your site is hosted on IIS and we want to debug the site, the main thing that we need to do is attach a worker process with Visual Studio. There are two possible scenarios for debugging from IIS:
1. Site is hosted on local IIS server: Local IIS debugging 2. Site is hosted on remote IIS server: Remote IIS debugging

I have already published two complete articles on CodeProject on the above topic. Please refer to those for details.

Summary
To summarize, this article is for beginners who are trying to learn about IIS. This article gives a complete coverage of IIS, hosting sites on IIS, application pool creation, etc. I have also mentioned a few tips which are very commonly used in dealing with IIS. Hope this will help beginners struggling with site hosting on IIS and configuring it. There are so many things related with IIS and it is not possible to mention all of them in a single article. This is just an overview. I hope that in future I will publish a few more articles on IIS in detail. Please give your valuable feedback and suggestions in order to improve the article. Thank you.

IIS 8.0 Using ASP.NET 3.5 and ASP.NET 4.5

Compatibility Versi on IIS ASP.NET 8.0 supported IIS ASP.NET 7.5 supported IIS ASP.NET 7.0 supported Notes 3.5 on IIS 3.5 on IIS 3.5 on IIS and 8.0. and 7.5. and 7.0. ASP.NET ASP.NET ASP.NET 4.5 4.5 4.5 are are are

Contents Problem Solution Step by Step Instructions o Setting up IIS 8.0 with support for ASP.NET 3.5 and 4.5 o Exploring the IIS 8.0 Installation o Running both ASP.NET 3.5 and ASP.NET 4.5 Applications Summary

Problem
Windows Server 2012 includes .NET Framework 4.5 by default, as well as optional installation of the .NET 3.5 Framework. Developers frequently need to run mixed web applications across multiple .NET Framework versions.

Solution
IIS 8.0 on Windows Server 2012 runs ASP.NET applications on all .NET Framework versions supported on Windows Server 2012. This means ASP.NET applications can run on IIS 8.0 using either .NET Framework 3.5, or .NET Framework 4.5. IIS 8.0 hosts versions of the .NET Framework in different application pools, thus allowing multiple ASP.NET applications with different .NET Framework versions to run simultaneously on Windows Server 2012. IIS 8.0 also supports managing both ASP.NET 3.5 and ASP.NET 4.5 applications using both the graphical IIS Manager tool as well as IIS' command-line management tools. Refer to this article for more information.

Step by Step Instructions

Prerequisites: IIS is installed on Windows Server 2012. To learn more about installing IIS 8, see Installing IIS 8 on Windows Server 2012.

Setting up IIS 8.0 with support for ASP.NET 3.5 and ASP.NET 4.5

In Windows Server 2012, both the .NET Framework 3.5 and .NET Framework 4.5 are natively recognized by the operating system. This means both UI-based and command-line driven setup can be used to turn on both versions of the .NET Framework, as well as enabling integration of both versions of ASP.NET with IIS 8.0. For this walkthrough we will use the new Server Manager UI in Windows Server 2012 Server to demonstrate enabling both ASP.NET 3.5 and ASP.NET 4.5 on IIS 8.0.
1. When you first login to a new Windows Server 2012 machine, the new Server Manager UI will display. Click add roles as shown below:

2. On the first screen of Add Roles and Features Wizard, click Next. This display a page where you select the desired installation type. Choose either Role-based or Feature-based installation as shown below:

3. Click Next. The next screen of the wizard asks you to choose the server that you are configuring. 4. On the next wizard step you will be asked to select one or more server roles. Scroll down in the Roles list, and make sure to check the Web Server (IIS)

checkbox as shown below:

5. Click Next to proceed to the next step, which enables you to select additional specific features to install on the server. Click Next again and proceed to the next step. 6. The next wizard step displays some introductory information about the Web Server (IIS) role. Click Next again and proceed to the next step. Now you should be at a wizard step that looks like the following:

7. Note that a number of default sub-features for IIS have already been turned on because you selected the Web Server (IIS) server role earlier. However we want to enable both ASP.NET 3.5 and ASP.NET 4.5 to run on IIS 8.0, so we need to enable some additional IIS related features. Scroll down in the Role services list until the Application Development node is showing. This node is collapsed initially, click on the node and expand it so that its children

are showing:

8. The Application Development node is where we enable ASP.NET integration with IIS. Note that there are a few checkboxes in the feature list with similar names. The pair of checkboxes that are of interest for this walkthrough are: o ASP.NET 3.5 - This option enables ASP.NET 3.5 to run on IIS 8.0. Note that with Windows Server 2012, .NET Framework 3.5 is not available as a part of the base OS image. Instead, the payload is downloaded from the Internet and you need to connect to the Internet. o ASP.NET 4.5 - This option enables ASP.NET 4.5 to run on IIS 8.0. 9. First click the ASP.NET 3.5 check box. When you do so an additional dialog box will popup as shown below:

10.Since ASP.NET 3.5 is integrated into the Windows Server 2012 setup, Windows Server 2012 knows all of the related dependencies necessary to enable ASP.NET 3.5 on IIS 8.0. This popup dialog is just showing you what will be automatically pulled in and installed. Since we do want ASP.NET 3.5 enabled, click Add Required Features.

11.Next, click the ASP.NET 4.5 check box in the Role services feature list. The end result of clicking both ASP.NET related checkboxes is shown below:

12.Even though you only directly selected the ASP.NET 3.5 and ASP.NET 4.5 features, the wizard automatically turned on a number of other items. This is done automatically so that developers do not have to explicitly choose the various component pieces needed to "assembly" of ASP.NET on Windows Server 2012. At this point click Next to accept the changes. 13.The Confirm installation selections step displays a list of all of features that are installed if you accept the changes.

14.At this point, click Install to accept the changes and install full ASP.NET support on Windows Server 2012. 15.Since the installation will take a small amount of time to complete, the wizard displays a progress dialog while the installation progresses:

16.After a few minutes the wizard shows that the installation has completed:

17.At this point, you can click Close and exit the wizard. Exploring the IIS 8.0 Installation

With both IIS 8.0 and ASP.NET integration installed we can take a look at the basic ASP.NET footprint for IIS 8.0.
1. From the Windows Start menu select All Programs and then expand the Administrative Tools menu. In the resulting list, find Internet Information Services (IIS) Manager and select it to launch the graphical IIS management tool:

2. Once the IIS Manager starts up, expand the server node in the left-hand window so that both the Application Pools node and Sites node are showing. When you do this the IIS Manager will popup a dialog asking if you want to stay connected with the latest Web Platform Components. For this walkthrough, you can click No. However on real-world installations you will probably want to click Yes so that the Web Platform Installer is available for your use to download various IIS extensions such as the URL Rewrite Module.

At this point the IIS Manager looks like the following picture:

3. Click the Application Pools node to display the application pools that have now been installed for use by IIS 8.0:

4. You can see that six different application pools are created by default when both ASP.NET 3.5 and ASP.NET 4.5 are enabled for IIS 8.0. Four of the applications are new for IIS 8.0, while two other application pools have been carried forward from previous Windows releases. o Note that although the .NET Framework Version column shows "v2.0" and "v4.0" for .NET Framework versions, these equate to ASP.NET 3.5 and ASP.NET 4.5. Due to the internals of how application pools bind to .NET Framework versions, the actual version name written to configuration (and thus displayed in the tool) corresponds to the original .NET Framework file version. o Classic .NET AppPool and DefaultAppPool existed in previous versions of Windows, and thus continue to be created for IIS 8.0. Note however that since .NET 4.5 is the default .NET Framework for use by Windows Server 2012, the "DefaultAppPool" on IIS 8.0 also defaults to using the newer version of the .NET Framework. o The other four application pools are new in Windows Server 2012. There are two application pools for running .NET Framework 3.5 ( .NET v2.0 and .NET v2.0 Classic), and two application pools for running .NET Framework 4.5 (.NET 4.5 and .NET 4.5 Classic). o The difference between "classic" and "not classic" application pools is the managed pipeline mode supported in each application pool type. The two application pools ending in "Classic" support the older Windows Server 2003-era classic pipeline mode for ASP.NET, while the other two application pools use the newer integrated pipeline mode for ASP.NET introduced in Vista/IIS7.0.

5. Exploring a little bit further, expand the Sites node in the left-hand side of the screen so that the Default Web Site node is visible:

6. Default installations of IIS always have a "Default Web Site" configured to listen for HTTP requests on port 80. Drill into the "Default Web Site" to see what version of ASP.NET it supports by default. Right-click Default Web Site, then select Manage Website, and select Advanced Settings as shown below:

7. The Advanced Settings dialog pops up, showing (amongst other things) the application pool used to run the "Default Web Site". As shown in the picture below, the "Default Web Site" runs in the application pool called "DefaultAppPool":

8. If you click the small ellipsis-button on the right-hand side of the application pool , an additional dialog pops up displaying more information about the "DefaultAppPool". As noted earlier the "DefaultAppPool" defaults to ASP.NET 4.5 for IIS 8.0, so ASP.NET 4.5 applications deployed in the "Default Web Site"

will work without any further configuration.

9. At this point, click Cancel to cancel both the Select Application Pool dialog, and the Advanced Settings dialog. Running both ASP.NET 3.5 and ASP.NET 4.5 Applications

Now that you have explored the setup state of IIS 8.0, try running some sample ASP.NET code to confirm that both ASP.NET 3.5 and ASP.NET 4.5 applications can run simultaneously on a single IIS 8.0 installation. Sample code for both ASP.NET 3.5 and ASP.NET 4.5 is contained in the following .zip:

First, set up a simple ASP.NET 3.5 application on IIS 8.0:

1. Open the "examples.zip" file. 2. In Windows Explorer on your Windows Server 2012 machine, navigate to the "wwwroot" directory for your IIS installation. For example if you installed IIS on the "C:\" drive, the "wwwroot" directory will be at "c:\inetpub\wwwroot". 3. Copy the folder "example35" from "examples.zip", and paste it into the directory "c:\inetpub\wwwroot". When you are done the directory structure should look like the following:

4. The newly created "example35" folder needs to be configured as an ASP.NET 3.5 application in the IIS Manager. Go back to the IIS Manager window, click on the Default Web Site node, and select Refresh. The treeview of child

nodes under the Default Web Site now shows the "example35" folder:

5. Right-click the example35 folder and select Convert to Application:

6. The Add Application dialog will pop up. By default all directories within Default Web Site are part of the application pool called DefaultAppPool. This means that newly created folders containing ASP.NET run as ASP.NET 4.5 applications by default.

7. Since we want to run the example35 folder as an ASP.NET 3.5 application, the application pool needs to be changed. Click Select, and the Select Application Pool dialog that pops up. Change the application pool to .NET

v2.0 as shown below:

8. Click OK button to accept the application pool change, and then click OK again to commit the changes to IIS. The IIS Manager window appears again. In the treeview showing "Default Web Site", the icon for "example35" is changed to indicate it is now a separate ASP.NET application.

9. At this point start an instance of Internet Explorer and navigate to the following Url:

http://localhost/example35
After a short pause the application displays a list of .NET Framework features supported in this application. 10.in Windows Explorer, if you navigate to the "c:\inetpub\wwwroot\example35" directory, you can use notepad to look at the code for "default.aspx" and the information in "web.config". For example, the contents of web.config include directives that configure the .NET Framework compilers to run in "3.5" mode. The .NET Framework code in "default.aspx" demonstrates some C# constructs that were introduced in .NET 3.5 - specifically LINQ-to-Object queries.

Now that there is an ASP.NET 3.5 application running, you can create a second ASP.NET application, but this time configure it to use .NET 4.5.
1. Go back to the Windows Explorer window that has the .zip file "examples.zip" open. 2. Open up the contents of the "example45" folder. 3. In the second Windows Explorer window that you have open, navigate to "c:\inetpub\wwwroot". 4. Copy the "default.aspx" file from the .zip file and paste it directly into "c:\inetpub\wwwroot". The folder contents for "c:\inetpub\wwwroot" should

now look like:

5. Now go back to Internet Explorer and navigate to the following Url:

http://localhost/default.aspx
After a short pause a second application pool will start running an ASP.NET 4.5 application for the "Default Web Site". The browser once again displays a list of .NET Framework features supported in this application with a new entry at the end of the list for dynamically typed variables (i.e. the dynamic keyword introduced in .NET 4.0/4.5). Notice that unlike the "example35" application that required special web.config entries, no web.config file was required to configure and run the "default.aspx" page in the "Default Web Site". This is because .NET Framework 4.5 is the default .NET Framework used by ASP.NET applications in IIS 8.0, and as a result no extra configuration is required. 6. If you use Notepad to open the "default.aspx" page that you just copied, you will also see a few changes compared to the version in the "example35" directory. There are no namespace directives at the top of the page since the .NET Framework 4.5 is the default on IIS 8.0. The code on the page demonstrates using a dynamic variable, which is a compiler concept introduced in .NET 4.0/4.5.

Summary
IIS 8.0 supports running both ASP.NET 3.5 and ASP.NET 4.5 applications on the same machine using different application pools to host each .NET Framework version. IIS 8.0 supports for multiple .NET Framework versions enables developers and administrators to take full advantage of IIS 8.0 while maintaining backward compatibility with web applications carried over from Windows Server 2008 R2.

Introduction to IIS Architecture

Introduction
Internet Information Services (IIS) 7 and above provides a request-processing architecture that includes:

The Windows Process Activation Service (WAS), which enables sites to use protocols other than HTTP and HTTPS. A Web server engine that can be customized by adding or removing modules. Integrated request-processing pipelines from IIS and ASP.NET.

This article describes the components, modules, and request-processing architecture in the following sections:

Components in IIS Protocol Listeners Hypertext Transfer Protocol Stack (HTTP.sys) World Wide Web Publishing Service (WWW service) Windows Process Activation Service (WAS) Modules in IIS Native Modules Managed Modules Request Processing in IIS Application Pools in IIS HTTP Request Processing in IIS

Components in IIS
IIS contains several components that perform important functions for the application and Web server roles in Windows Server 2008 (IIS 7.0) and Windows Server 2008 R2 (IIS 7.5). Each component has responsibilities, such as listening for requests made to the server, managing processes, and reading configuration files. These components include protocol listeners, such as HTTP.sys, and services, such as World Wide Web Publishing Service (WWW service) and Windows Process Activation Service (WAS).

Protocol Listeners
Protocol listeners receive protocol-specific requests, send them to IIS for processing, and then return responses to requestors. For example, when a client browser requests a Web page from the Internet, the HTTP listener, HTTP.sys, picks up the request and sends it to IIS for processing. Once IIS processes the request, HTTP.sys returns a response to the client browser. By default, IIS provides HTTP.sys as the protocol listener that listens for HTTP and HTTPS requests. HTTP.sys was introduced in IIS 6.0 as an HTTP-specific protocol listener for HTTP requests. HTTP.sys remains the HTTP listener in IIS 7 and above, but includes support for Secure Sockets Layer (SSL).

To support services and applications that use protocols other than HTTP and HTTPS, you can use technologies such as Windows Communication Foundation (WCF). WCF has listener adapters that provide the functionality of both a protocol listener and a listener adapter. Listener adapters are covered later in this document. For more information about WCF, see Windows Communication Foundation on MSDN.

Hypertext Transfer Protocol Stack (HTTP.sys)

The HTTP listener is part of the networking subsystem of Windows operating systems, and it is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). HTTP.sys listens for HTTP requests from the network, passes the requests onto IIS for processing, and then returns processed responses to client browsers. In IIS 6.0, HTTP.sys replaced Windows Sockets API (Winsock), which was a user-mode component used by previous versions of IIS to receive HTTP requests and send HTTP responses. IIS 7 and above continue to rely on HTTP.sys for HTTP requests. HTTP.sys provides the following benefits:

Kernel-mode caching. Requests for cached responses are served without switching to user mode. Kernel-mode request queuing. Requests cause less overhead in context switching because the kernel forwards requests directly to the correct worker process. If no worker process is available to accept a request, the kernelmode request queue holds the request until a worker process picks it up. Request pre-processing and security filtering.

World Wide Web Publishing Service (WWW service)

In IIS 7 and above, functionality that was previously handled by the World Wide Web Publishing Service (WWW Service) alone is now split between two services: WWW Service and a new service, Windows Process Activation Service (WAS). These two services run as LocalSystem in the same Svchost.exe process, and share the same binaries. Note You may also see the WWW Service referred to as W3SVC in documentation.
How WWW Service works in IIS 6.0

In IIS 6.0, WWW Service manages the following main areas in IIS:

HTTP administration and configuration Process management Performance monitoring

HTTP Administration and Configuration

The WWW Service reads configuration information from the IIS metabase and uses that information to configure and update the HTTP listener, HTTP.sys. In addition, WWW service starts, stops, monitors, and manages worker processes that process HTTP requests.
Performance Monitoring

The WWW Service monitors performance and provides performance counters for Web sites and for the IIS cache.
Process Management

The WWW Service manages application pools and worker processes, such as starting, stopping, and recycling worker processes. Additionally, the WWW Service monitors the health of the worker processes, and invokes rapid fail detection to stop new processes from starting when several worker processes fail in a configurable amount of time.
How the WWW Service works in IIS

In IIS, the WWW service no longer manages worker processes. Instead, the WWW Service is the listener adapter for the HTTP listener, HTTP.sys. As the listener adapter, the WWW Service is primarily responsible for configuring HTTP.sys, updating HTTP.sys when configuration changes, and notifying WAS when a request enters the request queue. Additionally, the WWW Service continues to collect the counters for Web sites. Because performance counters remain part of the WWW Service, they are HTTP specific and do not apply to WAS.

Windows Process Activation Service (WAS)

In IIS 7 and above, Windows Process Activation Service (WAS) manages application pool configuration and worker processes instead of the WWW Service. This enables you to use the same configuration and process model for HTTP and non-HTTP sites. Additionally, you can run WAS without the WWW Service if you do not need HTTP functionality. For example, you can manage a Web service through a WCF listener adapter, such as NetTcpActivator, without running the WWW Service if you do not need to listen for HTTP requests in HTTP.sys. For information about WCF listener adapters and about how to host WCF applications in IIS 7 and above by using WAS, see Hosting in WCF on MSDN.
Configuration Management in WAS

On startup, WAS reads certain information from the ApplicationHost.config file, and passes that information to listener adapters on the server. Listener adapters are components that establish communication between WAS and protocol listeners, such as HTTP.sys. Once listener adapters

receive configuration information, they configure their related protocol listeners and prepare the listeners to listen for requests. In the case of WCF, a listener adapter includes the functionality of a protocol listener. So, a WCF listener adapter, such as NetTcpActivator, is configured based on information from WAS. Once NetTcpActivator is configured, it listens for requests that use the net.tcp protocol. For more information about WCF listener adapters, see WAS Activation Architecture on MSDN. The following list describes the type of information that WAS reads from configuration:

Global configuration information Protocol configuration information for both HTTP and non-HTTP protocols Application pool configuration, such as the process account information Site configuration, such as bindings and applications Application configuration, such as the enabled protocols and the application pools to which the applications belong

If ApplicationHost.config changes, WAS receives a notification and updates the listener adapters with the new information.
Process Management

WAS manages application pools and worker processes for both HTTP and non-HTTP requests. When a protocol listener picks up a client request, WAS determines if a worker process is running or not. If an application pool already has a worker process that is servicing requests, the listener adapter passes the request onto the worker process for processing. If there is no worker process in the application pool, WAS will start a worker process so that the listener adapter can pass the request to it for processing. Note: Because WAS manages processes for both HTTP and non-HTTP protocols, you can run applications with different protocols in the same application pool. For example, you can develop an application, such as an XML service, and host it over both HTTP and net.tcp.

Modules in IIS
IIS provides a new architecture that is different from previous versions of IIS. Instead of keeping the majority of functionality within the server itself, IIS include a Web server engine in which you can add or remove components, called modules, depending on your needs. Modules are individual features that the server uses to process requests. For example, IIS uses authentication modules to authenticate client credentials, and cache modules to manage cache activity. The new architecture provides the following advantages over previous versions of IIS:

You can control which modules you want on the server.

You can customize a server to a specific role in your environment. You can use custom modules to replace existing modules or to introduce new features.

The new architecture also improves security and simplifies administration. By removing unnecessary modules, you reduce the server's attack surface and memory footprint, which is the amount of memory that server worker processes use on the machine. You also eliminate the need to manage features that are unnecessary for your sites and applications.

Native Modules
The following sections describe the native modules that are available with a full installation of IIS 7 and above. You can remove them or replace them with custom modules, depending on your needs.
HTTP Modules

Several modules in IIS 7 and above perform tasks specific to Hypertext Transfer Protocol (HTTP) in the request-processing pipeline. HTTP modules include modules to respond to information and inquiries sent in client headers, to return HTTP errors, to redirect requests, and more.

Module Name

Description Sends default and configured HTTP error messages when an error status code is set on a response. Supports configurable redirection for HTTP requests.

Resource

CustomErrorModule

Inetsrv\Custerr.dll

HttpRedirectionModule

Inetsrv\Redirect.dll

Performs protocol-related actions, such as ProtocolSupportModule setting response headers and redirecting headers based on configuration. RequestFilteringModule

Inetsrv\Protsup.dll

Added in IIS 7.5. Filters requests as configured Inetsrv\modrqflt.dll to control protocol and content behavior. Added in IIS 7.5. Allows more secure Inetsrv\WebDAV.dll publishing of content by using HTTP over SSL.

WebDAVModule

Security Modules

Several modules in IIS perform tasks related to security in the request-processing pipeline. In addition, there are separate modules for each of the authentication schemes, which enable you to select modules for the types of authentication you want on your server. There are also modules that perform URL authorization, and a module that filters requests.

Module Name

Description Performs Anonymous authentication when no other authentication method succeeds. Performs Basic authentication. Performs Certificate Mapping authentication using Active Directory. Performs Digest authentication.

Resource

AnonymousAuthenticationModule

Inetsrv\Authanon.dll

BasicAuthenticationModule

Inetsrv\Authbas.dll

CertificateMappingAuthenticationModule

Inetsrv\Authcert.dll

DigestAuthenticationModule

Inetsrv\Authmd5.dll

Performs Certificate Mapping authentication IISCertificateMappingAuthenticationModule using IIS certificate configuration.

Inetsrv\Authmap.dll

RequestFilteringModule

Performs URLScan tasks such as configuring allowed verbs and file Inetsrv\Modrqflt.dll name extensions, setting limits, and scanning for bad character sequences. Performs URL authorization. Performs NTLM Inetsrv\Urlauthz.dll Inetsrv\Authsspi.dll

UrlAuthorizationModule WindowsAuthenticationModule

integrated authentication. Restricts IPv4 addresses listed in the ipSecurity list in configuration.

IpRestrictionModule
Content Modules

Inetsrv\iprestr.dll

Several modules in IIS perform tasks related to content in the request-processing pipeline. Content modules include modules to process requests for static files, to return a default page when a client doesn't specify a resource in a request, to list the contents of a directory, and more.

Module Name CgiModule

Description Executes Common Gateway Interface (CGI) processes to build response output. Attempts to return a default document for requests made to the parent directory. Lists the contents of a directory. Hosts ISAPI extension DLLs. Supports ISAPI filter DLLs.

Resource Inetsrv\Cgi.dll

DefaultDocumentModule DirectoryListingModule IsapiModule IsapiFilterModule

Inetsrv\Defdoc.dll Inetsrv\dirlist.dll Inetsrv\Isapi.dll Inetsrv\Filter.dll Inetsrv\Iis_ssi.dll Inetsrv\Static.dll Inetsrv\iisfcgi.dll

ServerSideIncludeModule Processes server-side includes code. StaticFileModule FastCgiModule

Compression Modules

Serves static files. Supports FastCGI, which provides a highperformance alternative to CGI.

Two modules in IIS perform compression in the request-processing pipeline.

Module Name DynamicCompressionModule

Description

Resource

Compresses responses and applies Gzip Inetsrv\Compdyn.dll compression transfer coding to responses. Performs pre-compression of static content. Inetsrv\Compstat.dll

StaticCompressionModule
Caching Modules

Several modules in IIS perform tasks related to caching in the request-processing pipeline. Caching improves the performance of your Web sites and Web applications by storing processed information, such as Web pages, in memory on the server, and then reusing that information in subsequent requests for the same resource.

Module Name FileCacheModule

Description Provides user mode caching for files and file handles. Provides kernel mode and user mode caching in HTTP.sys.

Resource Inetsrv\Cachfile.dll

HTTPCacheModule

Inetsrv\Cachhttp.dll

Provides user mode caching of user name and token TokenCacheModule pairs for modules that produce Windows user Inetsrv\Cachtokn.dll principals. UriCacheModule Provides user mode caching of URL information. Inetsrv\Cachuri.dll

Logging and Diagnostics Modules

Several modules in IIS perform tasks related to logging and diagnostics in the request-processing pipeline. The logging modules support loading of custom modules and passing information to HTTP.sys. The diagnostics modules follow and report events during request processing.

Module Name

Description

Resource

CustomLoggingModule FailedRequestsTracingModule

Loads custom logging modules. Supports the Failed Request Tracing feature.

Inetsrv\Logcust.dll Inetsrv\Iisfreb.dll

HttpLoggingModule

Passes information and processing status to Inetsrv\Loghttp.dll HTTP.sys for logging. Tracks requests currently executing in worker processes and reports information with Runtime Status and Control Application Programming Interface (RSCA).

RequestMonitorModule

Inetsrv\Iisreqs.dll

TracingModule

Reports events to Microsoft Event Tracing Inetsrv\Iisetw.dll for Windows (ETW).

Managed Support Modules

A couple of modules in IIS support managed integration in the IIS request-processing pipeline.

Module Name

Description Resource Provides integration of managed code Microsoft.NET\Framework\v2.0.50727\webengin modules in e.dll the IIS requestprocessing pipeline.

ManagedEngine

ConfigurationValidationMod Validates Inetsrv\validcfg.dll ule configuratio n issues, such as when an application is running in

Integrated mode but has handlers or modules declared in the system.web section.

Managed Modules
In addition to native modules, IIS enables you to use managed code modules to extend IIS functionality. Some of the managed modules, such as UrlAuthorization, have a native module counterpart that provides a native alternative to the managed module. Note Managed modules depend on the ManagedEngine module. The following table lists the managed modules that are available with a full installation of IIS 7 and above. For more information about the managed modules, see the .NET Framework SDK 2.0 on MSDN.

Module Name

Description

Resource

Manages anonymous identifiers, which are used by AnonymousIdentificatio features that System.Web.Security.AnonymousIdentificationModul n support e anonymous identification such as ASP.NET profile. Ensures that an authentication System.Web.Security.DefaultAuthenticationModule object is present in the context.

DefaultAuthentication

FileAuthorization

Verifies that a user has permission to System.Web.Security.FileAuthorizationModule access the requested file. Supports authentication by using System.Web.Security.FormsAuthenticationModule Forms authentication . Supports output caching.

FormsAuthentication

OutputCache

System.Web.Caching.OutputCacheModule

Profile

Manages user profiles by using ASP.NET profile, which stores and System.Web.Profile.ProfileModule retrieves user settings in a data source such as a database. Manages a RolePrincipal instance for System.Web.Security.RoleManagerModule the current user. Supports System.Web.SessionState.SessionStateModule maintaining session state, which enables storage of data specific to a single

RoleManager

Session

client within an application on the server. Determines whether the current user is permitted access to the requested System.Web.Security.UrlAuthorizationModule URL, based on the user name or the list of roles of which a user is a member. Supports mapping a real URL to a System.Web.UrlMappingsModule more userfriendly URL.

UrlAuthorization

UrlMappingsModule

Sets the identity of the user for an ASP.NET WindowsAuthentication application System.Web.Security.WindowsAuthenticationModule when Windows authentication is enabled.

Request Processing in IIS

In IIS, the IIS and ASP.NET request pipelines combine to process requests with an integrated approach. The new request-processing architecture consists of an ordered list of native and managed modules that perform specific tasks in response to requests. This design provides several benefits over previous versions of IIS. First, all file types can use features that were originally available only to managed code. For example, you can now use ASP.NET Forms authentication and Uniform Resource Locator (URL) authorization for static files, Active Server Pages (ASP) files, and all other file types in your sites and applications.

Second, this design eliminates the duplication of several features in IIS and ASP.NET. For example, when a client requests a managed file, the server calls the appropriate authentication module in the integrated pipeline to authenticate the client. In previous versions of IIS, this same request would go through an authentication process in both the IIS pipeline and in the ASP.NET pipeline. Third, you can manage all of the modules in one location, instead of managing some features in IIS and some in the ASP.NET configuration. This simplifies the administration of sites and applications on the server.

Application Pools in IIS

Application pools separate applications by process boundaries to prevent an application from affecting another application on the server. In IIS 7 and above, application pools continue to use IIS 6.0 worker process isolation mode. In addition, you can now specify a setting that determines how to process requests that involve managed resources: Integrated mode or Classic mode. Note: In IIS 6.0, worker process isolation mode and IIS 5.0 isolation mode are set at the server level. This makes it impossible to run both isolation modes on the same server. However, in IIS 7 and above, Integrated mode and Classic mode are set at the application pool level, which enables you to run applications simultaneously in application pools with different process modes on the same server.
Integrated application pool mode

When an application pool is in Integrated mode, you can take advantage of the integrated request-processing architecture of IIS and ASP.NET. When a worker process in an application pool receives a request, the request passes through an ordered list of events. Each event calls the necessary native and managed modules to process portions of the request and to generate the response. There are several benefits to running application pools in Integrated mode. First the requestprocessing models of IIS and ASP.NET are integrated into a unified process model. This model eliminates steps that were previously duplicated in IIS and ASP.NET, such as authentication. Additionally, Integrated mode enables the availability of managed features to all content types.
Classic application pool mode

When an application pool is in Classic mode, IIS 7 and above handles requests in the same way as in IIS 6.0 worker process isolation mode. ASP.NET requests first go through native processing steps in IIS and are then routed to Aspnet_isapi.dll for processing of managed code in the managed runtime. Finally, the request is routed back through IIS to send the response. This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Additionally, managed code

features, such as Forms authentication, are only available to ASP.NET applications or applications for which you have script mapped all requests to be handled by aspnet_isapi.dll. Be sure to test your existing applications for compatibility in Integrated mode before upgrading a production environment to IIS 7 and above and assigning applications to application pools in Integrated mode. You should only add an application to an application pool in Classic mode if the application fails to work in Integrated mode. For example, your application might rely on an authentication token passed from IIS to the managed runtime, and, due to the new architecture in IIS 7 and above, the process breaks your application.

HTTP Request Processing in IIS

IIS 7 and above have a similar HTTP request-processing flow as IIS 6.0. The diagrams in this section provide an overview of an HTTP request in process. The following list describes the request-processing flow that is shown in Figure 1:
1. When a client browser initiates an HTTP request for a resource on the Web server, HTTP.sys intercepts the request. 2. HTTP.sys contacts WAS to obtain information from the configuration store. 3. WAS requests configuration information from the configuration store, applicationHost.config. 4. The WWW Service receives configuration information, such as application pool and site configuration. 5. The WWW Service uses the configuration information to configure HTTP.sys. 6. WAS starts a worker process for the application pool to which the request was made. 7. The worker process processes the request and returns a response to HTTP.sys. 8. The client receives a response.

Figure 1: Overview of an HTTP Request In a worker process, an HTTP request passes through several ordered steps, called events, in the Web Server Core. At each event, a native module processes part of the request, such as authenticating the user or adding information to the event log. If a request requires a managed module, the native ManagedEngine module creates an AppDomain, where the managed module can perform the necessary processing, such as authenticating a user with Forms authentication. When the request passes through all of the events in the Web Server Core, the response is returned to HTTP.sys. Figure 2, below, shows an HTTP request entering the worker process.

Figure 2: Detail of a HTTP request inside the Worker Process