IIS 6.0 Architecture

Internet Information Services (IIS) – formerly called Internet Information Server – is a web server application and set of feature extension modules created by Microsoft for use with Microsoft Windows. IIS have several version and widely used are 6.0,7.0 and 7.5.Here,in this article i will try to explain IIS6 internals and its relation with ASP.Net.

HTTP.sys (HTTP Protocol Stack)

The HTTP listener is implemented as a kernel-mode device driver called the HTTP protocol stack (HTTP.sys). IIS 6.0 uses HTTP.sys, which is part of the networking subsystem of the Windows operating system, as a core component to receive and serve HTTP requests. Earlier versions of IIS use Windows Sockets API (Winsock), which is a user-mode component, to receive HTTP requests.

Kernel & User Mode

On widows (or most of modern OS) the program is allowed to run in kernel mode or user mode. When OS is first loaded, the windows kernel is started. It runs in kernel mode and set up paging and virtual memory.

The CPU is actually spending time in two very distinct modes:

• Kernel Mode: In Kernel mode, the executing code has complete and unrestricted access to the underlying hardware. It can execute any CPU instruction and reference any memory address. Kernel mode is generally reserved for the lowest-level, most trusted functions of the operating system. Crashes in kernel mode are catastrophic; they will halt the entire PC.
• User Mode: In User mode, the executing code has no ability to directly access hardware or reference memory. Code running in user mode must delegate to system APIs to access hardware or memory. Due to the protection afforded by this sort of isolation, crashes in user mode are always recoverable. Most of the code running on your computer will execute in user mode.

In windows task manager, under performance chart, the green line is total CPU time; the red line is Kernel time. The gap between the two is User time.

The two modes are enforced by CPU hardware, x86 CPU hardware actually provides four protection rings: 0, 1, 2, and 3. only rings 0 (Kernel) and 3 (User) are typically used.
Most of system drivers runs in kernel mode for maximum performance and other programs runs in User mode (some drivers may run in user mode) for maximum stability. User mode is clearly a net public good, but it comes at a cost.  Transitioning between User and Kernel mode is expensive. It’s why software that throws exceptions is slow, for example. Exceptions imply kernel mode transitions. Granted, we have so much performance now that we rarely have to care about transition performance, but when you need ultimate performance, you definitely start caring about kernel mode.
How HTTP.sys Works

When you create a Web site, IIS registers the site with HTTP.sys, which then receives any HTTP requests for the site. HTTP.sys functions like a forwarder, sending the Web requests it receives to the request queue for the user-mode process that runs the Web site or Web application. HTTP.sys also sends responses back to the client.

Other than retrieving a stored response from its internal cache, HTTP.sys does not process the requests that it receives. Therefore, no application-specific code is ever loaded into kernel mode. As a result, bugs in application-specific code cannot affect the kernel or lead to system failures.

HTTP.sys provides the following services in IIS 6.0:

• Routing HTTP requests to the correct request queue.
• Caching of responses in kernel mode.
• Performing all text-based logging for the WWW service.
• Implementing Quality of Service (QoS) functionality, which includes connection limits, connection timeouts, queue-length limits, and bandwidth throttling.

When IIS 6.0 runs in worker process isolation mode, HTTP.sys listens for requests and queues those requests in the appropriate queue. Each request queue corresponds to one application pool. An application pool corresponds to one request queue within HTTP.sys and one or more worker processes.

When IIS 6.0 runs in IIS 5.0 isolation mode, HTTP.sys runs like it runs in worker process isolation mode, except that it routes requests to a single request queue.

If a defective application causes the user-mode worker process to terminate unexpectedly, HTTP.sys continues to accept and queue requests, provided that the WWW service is still running, queues are still available, and space remains in the queues.

When the WWW service identifies an unhealthy worker process, it starts a new worker process if outstanding requests are waiting to be serviced. Thus, although a temporary disruption occurs in user-mode request processing, an end user does not experience the failure because TCP/IP connections are maintained, and requests continue to be queued and processed.

Note : A web farm is a multi-server scenario. So we may have a multiple servers for an application. If the load on one server is in excess then the other servers step in to bear the brunt.How they bear it is based on various models.

• RoundRobin. (All servers share load equally)
• NLB (economical)
• HLB (expensive but can scale up to 8192 servers)
• Hybrid (of 2 and 3).
• CLB (Component load balancer).

A web garden is a multi-processor setup. i.e. a single server . How to implement webfarms in .Net:

Go to web.config and here for mode you have 4 options.

• Say mode inproc (non web farm but fast when you have very few customers).
• Say mode StateServer (for webfarm).
• Outproc

 Whether to use option b or c depends on situation. StateServer is faster but SqlServer is more reliable and used for mission critical applications.

IIS 6.0 provides four Internet services

• WWWServices :The World Wide Web Publishing Service (WWW service) for hosting Internet and intranet content.
• FTP Service :The File Transfer Protocol (FTP) service for hosting sites where users can upload and download files.
• NNTP Service :The Network News Transfer Protocol (NNTP) service for hosting discussion groups.
• SMTP Service :The Simple Mail Transfer Protocol (SMTP) service for sending and receiving e-mail messages.

The World Wide Web Publishing Service

The World Wide Web Publishing Service (WWW service) provides Web publishing for IIS, connecting client HTTP requests to Web sites running on an IIS-based Web server.

The WWW service manages and configures the IIS core components that process HTTP requests. These core components include the HTTP protocol stack (HTTP.sys) and the worker processes.

The WWW service includes these subcomponents: Active Server Pages (ASP), Internet Data Connector, Remote Administration (HTML), Remote Desktop Web Connection, server-side includes (SSI), Web Distributed Authoring and Versioning (WebDAV) publishing, and ASP.NET.
¦lt;br /> Worker Processes (IIS 6.0)

A worker process is user-mode code whose role is to process requests, such as processing requests to return a static page, invoking an ISAPI extension or filter, or running a Common Gateway Interface (CGI) handler.

In both application isolation modes, the worker process is controlled by the WWW service.  However, in worker process isolation mode, a worker process runs as an executable file named W3wp.exe

Worker processes use HTTP.sys to receive requests and to send responses by using HTTP.  Worker processes also run application code, such as ASP.NET applications and XML Web services. You can configure IIS to run multiple worker processes that serve different application pools concurrently. This design separates applications by process boundaries and helps achieve maximum Web server reliability.

By default, worker processes in worker process isolation mode run under the Network Service account, which has the strongest security (least access) compatible with the functionality that is required. IIS 5.0 isolation mode will be discussed later in this article.

Inetinfo.exe (IIS 6.0)

When IIS 6.0 runs in worker process isolation mode,Inetinfo.exe is a user-mode component that hosts the IIS metabase and that also hosts the non-Web services of IIS 6.0, including the FTP service, the SMTP service, and the NNTP service. Inetinfo.exe depends on IIS Admin service to host the metabase.

When IIS 6.0 runs in IIS 5.0 isolation mode, Inetinfo.exe functions much as it did in IIS 5.0. In IIS 5.0 isolation mode, however, Inetinfo.exe hosts the worker process, which runs ISAPI filters, Low-isolation ISAPI extensions, and other Web applications.

In IIS6.0, regardless of the application isolation mode used, the services that run in Inetinfo.exe run as dynamic-link libraries (DLLs) under the Local System account. Because a Local System account allows users access to every resource on the local computer.

IIS 5.0 isolation mode

IIS 5.0 isolation mode provides compatibility for applications that were designed to run in earlier versions of IIS. When IIS 6.0 is running in IIS 5.0 isolation mode, request processing is almost identical to the request processing in IIS 5.0. When a server is working in IIS 5.0 isolation mode, application pools, recycling, and health monitoring features are unavailable.
Figure 2 : below shows the IIS 5.0 isolation mode.

Note : Use IIS 5.0 isolation mode only if components or applications do not function in worker process isolation mode.

COM makes it possible to create DLL servers that can be loaded into a surrogate EXE process. This combines the ease of writing DLL servers with the benefits of executable implementation.The dllhost.exe process goes by the name COM Surrogate ,which is an general purpose executable to host dlls out of process.If there is any unhandlled error in user dll which may crash the COM Surrogate process leaving the originating process intact.

Application Pools

When you run IIS 6.0 in worker process isolation mode, you can separate different Web applications and Web sites into groups known as application pools.Every application within an application pool shares the same worker process. Because each worker process operates as a separate instance of the worker process executable, W3wp.exe, the worker process that services one application pool is separated from the worker process that services another. Each separate worker process provides a process boundary so that when an application is assigned to one application pool, problems in other application pools do not affect the application. This ensures that if a worker process fails, it does not affect the applications running in other application pools.

Use multiple application pools when you want to help ensure that applications and Web sites are confidential and secure.

Note : You can’t configure two diferent version of ASP.Net (say 1.1 and 2.0) application is single application pool (same IIS process) because different versions of the .NET Framework and run time cannot coexist side by side within the same process. For this to work you need to create atleast pools each version of ASP.net application.

ISAPI

Internet Server Application Programming Interface (ISAPI), is an API developed to provide the application developers with a powerful way to extend the functionality of Internet Information Server (IIS). ISAPI extensions are true applications that run on IIS and have access to all of the functionality provided by IIS. As an example of how powerful ISAPI extensions can be, ASP.Net pages are processed through an ISAPI extension called aspnet_isapi.dll. ISAPI extensions are implemented as DLLs that are loaded into a process that is controlled by IIS. Like ASP and HTML pages, IIS uses the virtual location of the DLL file in the file system to map the ISAPI extension into the URL namespace that is served by IIS.Extensions and filters are the two types of applications that can be developed using ISAPI.

Application mappings

Application mappings (or script mappings) are the Web server equivalent of file associations in Windows.In IIS, ASP.Net functionality is contained in an ISAPI extension called aspnet_isapi.dll. Any file that is requested from the IIS server that ends in “.aspx” is mapped to aspnet_isapi.dll which is assigned to process the file before displaying its output in the client’s window.On arrival of first request on IIS , IIS loads appropriates ISAPI extenstion dll and call  ISAPI extension’s HttpExtensionProcfunction,the ISAPI extension carries out the actions it was designed to perform: for example, reading more data from the client (as in a POST operation), or writing headers and data back to the client.For each request, IIS perform all initialization and uninitialization from within HttpExtensionProc.

In the next article of this series “ASP.Net Internals“ we will discuss in detail how ASP.Net is related to worker process and how it gets activated when HTTP.sys recieves an request for aspx resouce on you web server (IIS).

Reference:

http://www.rajneeshnoonia.com/blog/2010/05/iis6-architecture/

Getting Started with IIS 7.0

Every IT shop is different; each has its own unique set of needs and objectives, especially when it comes to the hosting of Web sites or services. Web servers may need a sprinkle of this or a dash of that to meet the requirements of the organization, and then there's the challenge of

replicating that recipe to multiple servers while at the same time managing them all efficiently. Some of the biggest changes in IIS 7.0 aim to help IT shops do exactly that when building a Web server or Web farms.

As I ran down the list of all the great features in IIS 7.0, I became very excited to share the details of these features with you. When I realized I couldn't possibly cover all of them here, I decided to focus on some of the most significant features and biggest changes in IIS 7.0. For even more information, visit the IIS community Web site at IIS.net.

New Architecture

Core changes in IIS 7.0 relate to the architecture, request processing, PHP application framework support, and the configuration store. With IIS 6.0, the features were basically an all-or-nothing proposition. You had to install all of the features and could only customize IIS using ISAPI.

IIS is built on the premise that a Web administrator wants to start from a base set of functionality, then layer on only the required additional functionality desired in his environment. You know your environment the best, so IIS 7.0 gives you the building blocks to create your own custom Web server. By doing so, it lowers your administrative overhead by reducing the attack surface of your server and eliminating the need for updates to components that are not used. The key to this new approach is the modular architecture of IIS 7.0.

IIS 7.0 has a new design that lets you choose the functionality, known as modules, to be installed on the server. These modules plug directly into the integrated request pipeline. This new modular design has several benefits, including reducing both the attack surface and the footprint of your Web server.

IIS currently has 40 default modules—for example, basic, anonymous, and Windows® authentication are now individual modules that can be added to the request pipeline independently. For simple classification, the modules are grouped in eight subcategories (see Figure 1).

Figure 1 IIS 7.0 modules are classified into eight functional areas (Click the image for a larger view)

This means you now have the ability to build a customized Web server exactly tailored to your environment. But what if you need functionality that the 40 default modules don't supply, perhaps some sort of custom authentication or content modifier? No problem. You can write a module in native or managed code to fill this need and plug it right into the pipeline. This also allows Microsoft to write and release new modules individually so you don't have to wait for the next service pack or major product release. IIS 7.0 also grants you the ability to overwrite any of the 40 default modules with your own custom modules. For more information on how to build your own module, see IIS.net.

Integrated Request Pipeline

Think of the integrated request pipeline as the essential set of linear steps that must occur every time a page is served up (as seen in Figure 2). Typically, some sort of authentication must take place, followed by authorization to retrieve content, determination and execution of the handler needed for that content, performance of any necessary logging, and finally sending a response. The integrated request pipeline provides IIS 7.0 the flexibility to run different application frameworks at the same time. For example, you can run Forms authentication on top of PHP content with a custom logging module, all together in the same pipeline.

Figure 2 IIS 7.0 integrated pipeline and modules (Click the image for a larger view)

Each Web site on the server has an integrated request pipeline and can be run in one of two modes, Integrated and Classic. Integrated, the default, allows particular pieces of functionality to be plugged into the pipeline, giving you granular control over the request process. For compatibility, Classic mode reproduces IIS 6.0/ISAPI functionality through an ISAPI module into the pipeline. This is very helpful when migrating your applications to IIS 7.0.

Default Installation

Now let's talk about setting up your new modular Web server. If you look at a default install of IIS 7.0, you'll notice that only 10 modules (if you include the Windows Process Activation Service) are included. IIS 7.0 setup provides the base functionality of IIS when installing the Web Server Role, specifically only the modules needed to serve up static content, like plain HTML or classic ASP. What is installed on the server after this is strictly up to you. Here is the functionality included in a default installation:

• Common HTTP features including Static Content, Default Document, Directory Browsing, and HTTP errors
• Health and Diagnostics features such as HTTP Logging and Request Monitor
• Security features such as Request Filtering
• Performance features such as Static Content Compression
• Management Tools including IIS Management Console
• Windows Process Activation Service

As you can see, this is a bare minimum server that doesn't include ASP.NET or other new IIS 7.0 functionality like the diagnostic and troubleshooting features. To enable additional functionality on the server, such as the ability to deliver dynamic content like ASP.NET and FastCGI (PHP), is simple. Select the set of modules that you would like to install from the Web role's "Add Role Services" within Windows Server® Manager.

New Configuration Store

Another key change to IIS 7.0 that will make your life easier is the new configuration store. The metabase, now an optionally installed component for backward compatibility, has been replaced by an XML configuration system. I can hear you already, "But the metabase was XML!" Yes, it was. But it was cumbersome and not easy to read (at least not by humans). It has been replaced with a more flexible XML system. Like ASP.NET, IIS 7.0 uses .config files—clean, simple, portable, and easy-to-read .config files.

Moving to this format means that the configuration system is now machine-independent, unlike the metabase that was keyed to an individual machine. As a result, you can now easily port the config system over to other servers with a simple drag and drop or xcopy, and away you go.

This new config system also works wonders for Web farms by utilizing a new feature in IIS 7.0 called Shared Configuration. Since this new config system is portable, you can share one master .config file among all nodes in the farm. Shared Configuration allows you to export the config of a known good pre-production server and then share it across your production or "live" environment.

When exporting the .config file you must provide it with an encryption key password. This protects the .config file from a rogue Web server attempting to mimic your server's .config without authorization.

Enabling Shared Configuration is simple. In the server node of IIS Manager, select Shared Configuration, which is located under the Management section of the task pane. Simply check "Enable shared configuration," provide the physical path of the configuration you are going to share (typically this will be a UNC share), enter the credentials needed to access the physical path, and click Apply. When the .config is found, you will be prompted its the encryption password. Once this process is completed, restart IIS Manager so it will pick up the new .config.

The structure of the new configuration system is different from that which you're used to, so let's go over the basics. As Figure 3 shows, the configuration of IIS 7.0 has been broken into two categories, server-wide settings and site-specific settings. All server-wide settings are stored within applicationhost.config, which is located in %systemroot%\windows\system32\inetsrv\config. This includes all modules installed, sites on the server, and so forth. Site-specific settings are stored in individual web.config files.

Figure 3 There is one .config file for server-wide settings and separate individual ones for each Web site on that server (Click the image for a larger view)

If you've used ASP.NET, you're probably familiar with web.config files. IIS 7.0 uses web.config files to store settings specific to individual Web sites, such as a site's default document and application settings, as well as ASP.NET settings. This means you will have a web.config file for each site on your server.

A site's web.config file is located in the physical path of the site, such as %systemroot%\inetpub\wwwroot, for example. This design yields the same portability benefits noted earlier but at the site level. You can easily develop a site on a test server, for example, and then simply drag and drop, or xcopy, the site's web.config and application files over to a production server.

Whenever porting or sharing .config files, watch for machine-specific information like IP addresses and drive letters. IIS 7.0 provides a remedy for this possible oversight with support for OS environment variables (such as %systemroot%). Also ensure that the same set of modules is installed across the test and production servers. This will help avoid unexpected application errors. Errors can also occur if the web.config references a module that isn't installed or if a default module conflicts with a custom module.

Managing Your Web Server

So now you have this great, new, customizable, flexible, and portable Web server. How are you going to manage it? Management was a big part of the planning and building of IIS 7.0, and there are several ways to handle administrative chores.

Management preferences typically fall into at least one of three categories: point-and-click administration from the UI, entering commands at the command line, and writing scripts to automate as much as possible. Let's start with the UI.

In IIS 6.0, the UI Microsoft® Management Console (MMC) snap-in had two basic, familiar views, Tree view and Tab view. To drill into a setting, you'd right-click, select Properties, and then you'd be presented with a bunch of tabs, not to mention the Radio buttons and checkboxes.

Happily, the UI in IIS 7.0 has been completely revamped. This UI, named IIS Manager, was designed to enable a task-oriented approach, as Figure 4 shows. There's also a Remote Manager for down-level clients such as Windows XP and Windows Server 2003. You can download it via IIS.net/downloads.

Figure 4 New UI in IIS 7.0 (Click the image for a larger view)

The new user interface consists of the Connections pane on the left, the Actions pane on the right, and the task pane or workspace in the middle. The connection manager tree on the left is similar to the IIS 6.0 tree view with parent and child nodes. New to the tree view is the ability create new connections, save current connections, or delete existing connections. The task pane is the UI's biggest improvement, with two views to work from. The feature view takes all configurable properties of IIS out from the old "tabs" view and groups them by administrative area, such as IIS, management, and security.

ASP.NET properties have also been integrated into IIS Manager, eliminating the need to use an additional MMC snap-in. Each configurable property has its own icon, making it easy to locate. And because IIS Manager was built as a Windows Forms application, you can easily add plug-in icons for any custom modules or functionality you write.

The task pane's second view is content view, which is very similar to IIS 6.0 in that you see what is in a site's content directory and can perform actions against that content. What is new here is the ability to select a specific piece of content, say a specific Web page, then switch to feature view to invoke certain settings on the selected content, which gives you granular control down to the page level.

Other Ways to Manage

For those who prefer the command line, there's a powerful new tool named APPCMD.exe that lets you perform simple tasks such as stopping a site or backing up the current .config file, as well as more complex tasks such as searching the configuration's schema. The syntax is very simple:

APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>. 

To list all objects available to APPCMD, type:

APPCMD /? 

Or, if you want to see the commands available for a certain object type, enter:

APPCMD (object-type) /?

For all the coders out there, a managed code API called Microsoft.Web.Administration and a new Windows Management Instrumentation (WMI) provider have been added to IIS 7.0. These two methods open up a ton of options to script, automate, and write tools to manage IIS 7.0. Both can be used with Windows PowerShell®, and the WMI provider can also be used with VBScript and JScript®. For additional information, seeblogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Remote Management and Delegated Administration

IIS 7.0 provides new ways to remotely manage your server, sites, Web applications, and securely delegated administration rights for non-administrators. First let's talk about the new remote management capabilities and how they can make your life easier.

In the past, there were two ways to manage an IIS server remotely: by using the remote management Web site or by using remote desktop/terminal services to access the UI. But if you were outside your firewall or not on-site, these options were not very useful. IIS 7.0 remedies this by building remote management capabilities directly into the UI that work via firewall-friendly HTTPS.

Remote management in IIS 7.0 makes life easier in several ways. First, you get the same UI experience as if you were logged on locally. Second, there's no need to open ports on your firewall since communication happens via HTTPS. Lastly, you can now manage several servers from a single UI. No need to have multiple Remote Desktop or remote Web site windows open at the same time.

The actual remote management service within IIS 7.0 is essentially a small Web application which runs as a separate service, under a Windows NT® local service account named NT Service\WMSVC. This design maintains the remote management functionality even if the IIS server itself is unresponsive.

Like most features within IIS 7.0, for security purposes, remote management is not installed by default. To install the remote management features, add role services for the Web Server role in the Windows Server 2008 Server Manager, which can be found under Management Tools. Once this feature is installed, you then have to enable remote connections and start the WMSVC service since it's stopped by default.

The WMSVC service's default startup setting is manual. If you want the service to start automatically after a reboot, you will need to change the setting to automatic. You can do so via the command line by typing:

sc config WMSVC start=auto

When enabling remote connections via the management service, you'll see a list of settings such as Identity Credentials, Connections, and IPV4 Address Restrictions. The only decision that is critical at this point is determining which set of identity credentials to grant permission to connect to IIS 7.0: Windows credentials only or Windows and IIS Manager credentials.

The first option is fairly oblivious, indicating that you want to allow only Windows user accounts, whether local or domain. The second option involves both Windows users and a type of account that's completely new in IIS 7.0 and is not associated with Windows user accounts: IIS Manager Users. With IIS Manager Users, administrators have the ability to create user accounts that are known only in the context of IIS 7.0 and have no access to the OS. Lastly, by default, IIS provides a self-signed certificate to get started, but it is recommended that you add a valid signed SSL certificate. Now just apply your setting and start the service.

For additional control and security, IT administrators have the ability to securely delegate administration tasks of individual sites or Web applications to non-admins.

Delegated Administration is essentially remote administration, but it limits the scope of access to individual sites or Web applications. The IIS Manager Users feature is particularly handy here. You can create IIS users for those one-off site owners and delegate permission to administer their own site or application. They have no access to server-wide settings and are limited to settings only for their specific site or Web app.

You can also specify what features and settings users can change and even which appear in the UI. For example, if you don't want someone to change the type of authentication used for his site, you can set that feature to either read-only or not inherited. When a feature is read-only, users can still access the feature and determine the setting but not make changes; and with the not-inherited setting, the feature icon will not appear in the delegated user's IIS Manager view. This kind of feature delegation lets you provide strictly controlled access to others without providing administrative control over the Web server.

Moving Forward to IIS 7.0

When designing IIS 7.0, the team wanted to ensure the transition to it was as fluid as possible by allowing the use of some of your existing investments in management tools and scripts for IIS 6.0. A lot of thought was put into the backward compatibility of IIS 7.0 so it would work with your IIS 6.0 scripts. There is an entire set of tools—ranging from IIS 6.0 metabase compatibility to the actual IIS 6.0 management console—that you can install under the IIS 6.0 management compatibility node in setup.

The IIS 6.0 metabase compatibility infrastructure uses a component called ADOMapper. It allows you to run your IIS 6.0 Admin Based Object (ABO) and ADSI (Active Directory Services Interface) metabase scripts against the new config system, limiting it to only what IIS 6.0 could do. Thus, it can't read or write new IIS 7.0 properties, access new runtime data, or read or write ASP.NET properties or web.config files.

Troubleshooting and Diagnostics

Troubleshooting and diagnostics have always been time-consuming chores. Digging through logs and trying to reproduce a problem in a large Web farm or even a single server can be tough. IIS 7.0 has a tool called Failed Request Tracing to help relieve some of that pain and wasted time. It can be helpful in many situations, including when a request hangs or produces errors and for investigating authentication and authorization problems.

Failed Request Tracing uses tracing rules as a criterion to search for errors. Tracing rules can be created to look for types of behavior or errors by specifying the type of content you'd like to trace (such as all content on the server, only ASP.NET content, or custom content such as PHP) and under what conditions the trace should begin (such as a certain returned status code, time taken to serve the page, event severity, or a combination).

Suppose, for example, users report that a site is taking too long to load. That's a tough scenario to reproduce in any case but especially if you have thousands of hits per hour. With Failed Request Tracing, you simply add a tracing rule to start logging when a page takes more than the desired amount of time to load—for this example, I'll say two seconds—and wait for the server to reproduce the problem on its own (see Figure 5).

Figure 5 Using Failed Request Tracing for troubleshooting (Click the image for a larger view)

The difference between Failed Request Tracing and traditional logging is that the former only logs when a particular failed request criterion is detected. The log file itself is XML topped with an XML style sheet, making it clean and easy to read. Like most other IIS 7.0 features, this is not installed by default and can be found under the health and diagnostics section of setup. You must also enable it within IIS Server Manager.

IIS 7.0 is a great leap forward for all administrators. It's new architecture and capabilities provide the agility and flexibility needed to adapt to your ever-changing environment. With the management features, backward compatibility tools, and troubleshooting capabilities, it is ready to be deployed today and work with your existing environment.

Reference:

http://technet.microsoft.com/en-us/magazine/2008.03.iis7.aspx?pr=blog