IIS 7.0

Explore The Web Server For Windows Vista And Beyond

Mike Volodarsky

Contents

Modular Web Server
Simplified Deployment and Configuration
Improved Administration
.NET Framework and Scripting
Building Web Server Features
ASP.NET Integration
Improved Security
Improved Diagnostics
Diagnosing Errors without Debugging
Improved Performance
Backward Compatibility
Conclusion

I often hear people-both inside and outside of Microsoft-refer to the new IIS 7.0 Web server as one of the most important developments coming out of Microsoft over the past several years. This is a rather significant statement, given the impressive lineup of technologies released by Microsoft recently, including Windows Vista™!

The release of IIS 7.0 coincides with the ten-year anniversary of the release of the first version of IIS, in Windows NT® 4.0. In 2001, four versions later, IIS 5.0 became the most prevalent Web server on the Internet, though months later it fell victim to the infamous Code Red and Nimbda worms. IIS 6.0, released in Windows Server® 2003, was a major rewrite of the server, focused entirely on improving security, reliability, and performance. Since then, IIS 6.0 has proven to be a rock-solid Web server, achieving high reliability and security track records with only a single critical security bulletin since its release (which was not exploitable remotely).

In this article, I want to take the opportunity to present the major reasons why the next-generation IIS 7.0 Web server makes such a big difference to developers and administrators alike-and give you a head start in using many of its new features.

The vision for IIS 7.0 was to take the speed, reliability, and security of the IIS 6.0 codebase and turn it into a highly extensible and manageable Web server platform powerful enough to run Web applications of the future. The result is the most ambitious Microsoft Web server yet, delivering the largest number of architectural improvements in the history of IIS.

At the core of the IIS 7.0 release is a completely modular Web server, comprised of more than 40 features that can be assembled into small-footprint Web servers optimized for the desired role in your application topology. These features are built on top of a new extensibility layer that allows developers to extend or replace virtually any aspect of the server, in native code or with the Microsoft® .NET Framework. IIS 7.0 offers extensibility throughout its runtime, management, and operational features to help you build end-to-end solutions for your specific needs. On top of the core platform, IIS 7.0 tackles many of the problems associated with the manageability and operation of the server. It features a brand new configuration system that enables fully delegated management of sites and finally makes xcopy deployment of Web applications a reality. The new management APIs and diagnostic features make deployment, administration, and troubleshooting of the server significantly easier and more convenient than ever before.

But why should you start thinking about IIS, a server application, before the next version of Windows Server, code-named "Longhorn," is even near final release? It's important to start thinking about it now because Windows Vista ships with the same full-featured IIS 7.0 bits that are expected to be released in Windows Server "Longhorn." This means you can immediately take advantage of the new IIS 7.0 features to build your personal Web site and host it on Windows Vista. What's more, you can get a head start in developing and testing your production Web applications and Web server infrastructure on the same IIS platform you will be deploying them on when Windows Server "Longhorn" ships.

Intrigued? Let's dive into the details.

Modular Web Server

IIS 7.0 breaks up the Web server into a lightweight server core and more than 40 feature modules that can be plugged into this core. These modules -like StaticFileModule, which allows downloads of static Web content, or WindowsAuthModule, which supports integrated NTLM authentication -can be independently installed on the server to provide the exact functionality you need.

These modules can be completely uninstalled from the server at any time (see Figure 1) or specifically disabled for a particular application where they aren't needed. This allows server administrators to deploy minimal footprint servers quickly with dramatically reduced attack surface area and to significantly improve performance by executing only the required code.

Figure 1** Use Only the Features You Want **(Click the image for a larger view)

The componentized architecture is a critical property of IIS 7.0, leading to reduced security risks and minimized patching requirements. It also enables specialized server deployments, which combine select IIS features and custom components optimized for a specific server role in your application topology, such as reverse proxies and cache servers, HTTP protocol load balancers, or SSL and security sentinel servers.

All of the server features that ship with IIS 7.0 are built on top of new public extensibility APIs. As a developer, you have the ability to replace any of the existing server features with your own or build a new module to add to the IIS 7.0 feature set. Want to replace the built-in authentication mechanisms with a custom authentication module or provide a new form of response compression? Go ahead.

The new extensibility APIs are a fundamental improvement over the previous ISAPI extensibility model, enabling you to enhance the server with much more flexibility and ease. Virtually every single aspect of the server, starting with the core server and continuing to configuration, management, and diagnostics, provides extensibility to allow you to extend and tailor the server to your own needs. More about extensibility later in the article.

Simplified Deployment and Configuration

The centralized configuration store of the previous IIS releases, known affectionately as the metabase, is gone. IIS 7.0 features a new delegated configuration system based on a hierarchy of distributed XML configuration files. This hierarchy is comprised of a global applicationHost.config file, which contains server-level configuration defaults, and distributed web.config files within the application's directory structure. These are the same web.config files that are used by the ASP.NET application framework to store application settings in a portable way. This allows the side-by-side storage of IIS and ASP.NET configuration, using clean and strongly structured XML directives. Here's an example:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>
        <customErrors mode="Off" />
    </system.web>
    <system.webServer>
      <directoryBrowse enabled="true" />
    </system.webServer>
</configuration>

In the past, IIS application settings had to be explicitly configured in the machine-level metabase repository before the application could function correctly. With distributed web.config files, applications encapsulate the required server configuration within their directory structure. This dramatically simplifies deployment, allowing self-contained applications to be simply copied to the target server's application directory and thus be up and running immediately with the desired settings.

The new configuration system also gives comprehensive control to the server administrators, allowing them to delegate certain configuration options to the application while maintaining control over others for security or business reasons. In this way, applications on hosted servers can set essential configuration directly in their application without requiring the calling of the server administrator for help or using an external configuration panel.

In the true spirit of IIS 7.0, the configuration system is completely extensible. New modules can add their own configuration schema, enabling applications to configure their features side-by-side with the IIS and ASP.NET configuration:

<configuration>
    <system.webServer>
      <directoryBrowse enabled="true" />
    </system.webServer>
    <myBandwidthThrottler enabled="true" />    
</configuration>

The custom configuration sections use the same configuration schema as the configuration for the IIS 7.0 features, taking advantage of the strongly typed attribute values, collection syntax, and hierarchical overriding and locking semantics.

IIS 7.0 continues to support existing setup code that uses the Admin Base Object (ABO) APIs to write to the legacy metabase or scripts that use the higher-level Active Directory® Service Interfaces (ADSI) and Windows Management Instrumentation (WMI) objects to configure IIS. It does this by providing a compatibility layer that emulates the ABO APIs, on top of which all other legacy configuration APIs are based, allowing such scripts to read and change configuration just like they did in the previous releases of IIS. (For more information about metabase compatibility, see the "Improved Performance" and "Backward Compatibility" sections towards the end of this article.) While the new structured XML configuration format makes it easier to work with configuration in your favorite text editor, IIS also provides a host of management tools and APIs for administrators to simplify server management and enable automated configuration and deployment.

Improved Administration

IIS 7.0 offers a rich set of administration features that make managing the server possible in a wide range of scenarios. The new graphical IIS Manager administration tool, which replaces the InetMgr.exe MMC snap-in, makes manual server administration very simple with its task-based management interface (see Figure 2).

Figure 2** IIS Manager Provides Graphical Administration Tools **(Click the image for a larger view)

IIS Manager allows you to administer most IIS 7.0 features and monitor the server's operation. The tool supports remote administration over a firewall-friendly HTTP/SSL connection, with an option to support both Windows-based and other credentials for authentication.

What's more, the tool enables delegated management, letting application owners manage their applications remotely without having administrative access to the server computer. Armed with this capability, users of hosted services can run the administration tool on their home desktop and connect remotely to manage their applications on the hosted server. Server administrators, of course, have complete control over what management features are delegated to application owners.

Finally, the Administration tool is completely extensible, building on top of configuration system extensibility to allow custom management UI to be added to the tool. You can learn more about the IIS Manager tool and how to add your own administration plug-ins at iis.net/default.aspx?tabid=7&subtabid=73.

For more flexible command-line administration, IIS 7.0 offers the appcmd.exe command-line tool (see Figure 3). This tool provides a comprehensive set of management functionality and better support for bulk operations than the UI. This powerful utility makes it easy to read and write configuration, access site and application pool state information, and perform almost any other management task, all from the command prompt.

Figure 3** Appcmd.exe Command-Line Administration for IIS 7.0 **(Click the image for a larger view)

With appcmd.exe, you can create and configure sites, apps, application pools, and virtual directories. You can start and stop sites, recycle application pools, list running worker processes, examine currently executing requests, and search Failed Event Request Buffering (FREB) trace logs. You can also search, edit, export, and import IIS and ASP.NET configuration data.

The tool is built to allow flexible searches for supported server objects, for example, letting you quickly find sites with a particular setting set or application pools that are stopped. When performing a search, you can use any number of conditions on any of the object's properties, including using numeric ranges and simple wildcard string matching.

Appcmd also supports linked operations like those found in Windows PowerShell™, allowing multiple operations on a related set of objects to be performed together from a single command line. For example, you can find and recycle all application pools that host applications for a certain site in a single command. To learn how to manage IIS with AppCmd, check out iis.net/default.aspx?tabid=2&subtabid=25&i=954&p=1.

.NET Framework and Scripting

In addition to the manual server administration with IIS Manager or the appcmd.exe command-line tool, IIS 7.0 provides a wealth of options for programmatic administration. First, you can utilize the Microsoft.Web.Administration API to manage the server from .NET applications. Or you can use the new COM API to manage the IIS configuration system directly, or access it from a scripting environment such as ASP or Windows® Script Host (WSH). There is also a new WMI provider and support for legacy WMI and ADSI providers via the metabase compatibility layer.

Microsoft.Web.Administration, the new .NET Administration API, makes it easy for managed code applications to programmatically provision IIS sites and applications, access important state and diagnostic information, and otherwise configure the server. Enabling .NET Framework-based applications to easily access IIS configuration and state information opens up a world of possibilities for writing .NET-based setup and management applications or even carrying out management tasks directly from ASP.NET pages.

As an example, Figure 4 shows a small C# program that uses Microsoft.Web.Administration to create a new Web site from the command line.

Figure 4 Provisioning Sites with Microsoft.Web.Administration

using System;
using Microsoft.Web.Administration;

class CreateASite
{
    static void Main(string[] args)
    {
        ServerManager serverManager = new ServerManager();
        Site mySite = serverManager.Sites.Add(
            "MySite", "d:\\inetpub\\mysite", 8080);
        mySite.ServerAutoStart = true;
        serverManager.CommitChanges();
    }
}

Microsoft.Web.Administration makes IIS operations and configuration tasks a breeze, right inside your application in a .NET-compliant language of your choice. It also makes it easy to access runtime state information about the server, such as the running worker processes or currently executing requests.

The Microsoft.Web.Administration API serves as the foundation for accessing custom configuration inside custom .NET server modules and UI plug-ins for the IIS Manager tool. For an example of an end-to-end server package, including an image copyright handler to enhance the Web server and associated configuration and management components, take a look at iis.net/default.aspx?tabid=2&subtabid=25&i=1076.

In the Windows Server "Longhorn" timeframe, the IIS team is creating a unified extensibility model for adding custom management objects or extending existing ones, which will enable custom management functionality to be automatically exposed through the different management features including scripting and the Microsoft.Web.Administration API. While you cannot add or extend management objects in Windows Vista, you can use Microsoft.Web.Administration and other APIs to access and manipulate your custom configuration sections just like you can do with existing IIS configuration sections.

Building Web Server Features

IIS 7.0 enables you to mold the server into whatever you need it to be, letting you add or replace any feature in the server in order to provide the functionality you need. At the heart of this capability is a brand new Web server extensibility API on top of which all existing IIS 7.0 HTTP features are built. This API is public, which means that you can implement any of the features that ship with IIS 7.0. This is a first for IIS and a fundamental improvement over the previously limited ISAPI extensibility model.

The new extensibility API is a set of intuitive C++ classes that define the Web server object model and enable a module to provide request processing services on IIS. These classes are defined in the \inc\httpserv.h header file in the Windows Vista SDK.

Compared to ISAPI, these APIs are both more powerful and a lot easier to use. How is this possible? First, the new API features a type-safe, well-encapsulated object model. Development is much easier with the new server object model, which provides specialized interfaces for all of the basic server objects and tasks. This includes:

• Inspecting the request with the IHttpRequest class
• Manipulating the response with the IHttpResponse class
• Consuming useful utility functionality from the IHttpServer class
• Providing authentication with the IHttpUser class
• Accessing your module's custom configuration section with the configuration APIs

These classes expose a much greater set of the server's functionality than before (more than needed to build all of the features that ship with IIS), but are also much easier to use then the loosely typed ISAPI interfaces.

Developers will also benefit from improved patterns for memory and state management. Most of the IIS 7.0 server APIs use server-managed memory for data they return, instead of requiring you to allocate and manage the buffers as does ISAPI and the majority of existing Win32® APIs. In the past, this has been one of the most error-prone and tedious areas for ISAPI development. The new API also simplifies many complex request processing tasks, such as response buffering, authentication, and preparing response data for the client. A few months ago, I started a series of posts of my blog that explain the critical improvements and patterns in the new programming model.

IIS 7.0 also provides a fully integrated .NET Framework API for extending the server. What's more, this is the same API that's been provided by ASP.NET for building ASP.NET modules and handlers since the days of ASP.NET 1.0 on Windows 2000. But don't be fooled-while the familiar ASP.NET model allows existing ASP.NET modules and handlers to keep working on your IIS 7.0 server, it is actually far from the same old technology.

In IIS 7.0, ASP.NET comes in two versions: Classic mode and Integrated mode. Classic mode works exactly the same way as it did in previous versions of IIS. Integrated mode, the new platform default, uses a brand new engine to provide unparalleled integration with the IIS Web server. In Integrated mode, ASP.NET APIs can be used to develop IIS 7.0 modules that integrate directly with the Web server and are capable of providing virtually all of the services that are possible with the underlying C++ API.

This is basically the best of both worlds-the familiar interfaces and convenience of the .NET Framework and ASP.NET 2.0 application services like Membership and Role Management, plus the raw power to extend the server that was previously only available to C-based ISAPI components.

In addition to being able to write new ASP.NET modules that build on the specific benefits of the Integrated mode, many legacy ASP.NET modules can be made a lot more powerful just by changing a few configuration options in your web.config file.

ASP.NET Integration

With IIS 7.0, ASP.NET 2.0 becomes more than just an excellent framework for building dynamic applications. It becomes a platform for extending the IIS Web server, enabling ASP.NET components to become full members of the IIS request processing pipeline. Here's how it works.

In IIS releases up to version 6.0, ASP.NET connected to the Web server as a standalone application framework. It was responsible for processing the request extensions that were registered to it, typically .aspx and few others, and for those requests it offered powerful features like Forms Authentication, Response Output Caching, and others including services provided by custom ASP.NET modules. Because of this, only content types registered to ASP.NET could benefit from these services. Others, including ASP pages, PHP pages, images, and CGI applications could not. In addition, even for ASP.NET resources, certain Web server functions were not possible in ASP.NET because of runtime limitations. For example, it was not possible to inspect the set of outgoing HTTP response headers and modify them before being sent to the client.

When running in Integrated mode in IIS 7.0, ASP.NET modules run in the unified request processing pipeline side-by-side with native C++ IIS modules (see Figure 5). This means that existing ASP.NET services like Output Caching, URL Rewriting, and any others provided by your custom ASP.NET modules can now apply to any content type. Better runtime integration also enables ASP.NET modules to access previously unavailable server functionality, removing the need to write native IIS extensibility in most cases.

Figure 5** Integration with ASP.NET in IIS 6.0 and IIS 7.0 **(Click the image for a larger view)

Finally, in Integrated mode, ASP.NET provides a small number of new APIs that expose additional functionality available due to tighter integration with IIS. These include the ability to review all of the response headers regardless of who generated the response and the ability to fully rewrite request execution to another URL, among other features.

An existing application can often take advantage of Integrated mode without requiring new ASP.NET modules that use Integrated mode-specific functionality. Simply by changing configuration, an application can do things such as using ASP.NET Forms Authentication and URL Authorization to protect your entire Web site with user security or using ASP.NET URL Mapping to rewrite URLs in your application. For an example of leveraging Intergrated mode to stop Web leeches from hot-linking to your site's images, check out the sample ASP.NET module to do this on mvolo.com/stopping-hotlinking-with-iis-and-aspnet/. This is a good example of how you can get more bang out of existing third-party ASP.NET modules by using them in Integrated mode.

For a detailed walkthrough on taking advantage of Integrated mode for existing applications, check out my article at iis.net/default.aspx?tabid=2&subtabid=25&i=1081&p=1.

Improved Security

IIS 7.0 builds upon the IIS 6.0 code base, which has a proven security track record thanks to careful coding practices and secure-by-default design principles. On top of this, IIS 7.0 introduces a few architectural changes to provide even stronger security and a number of features to help you build secure Web applications.

Reducing the attack surface area is one of the fundamental principles of designing and deploying secure systems. Taking the lockdown-by-default approach of IIS 6.0 to the next level, IIS 7.0 installs fewer features by default, yielding an even more locked down server. By further taking advantage of the modular nature of the server to remove all unused features, you can reduce your server's attack surface to a minimum-significantly reducing the risk of your server being compromised by an attacker.

If a vulnerability is found in any of the components not in use on your server, you do not need to take the server out of rotation in order to prevent exploits or patch the vulnerable component immediately. This can result in increased availability of your application and lower patch management costs.

In addition to the core security improvements, IIS 7.0 offers a number of security features you can use to further lock down and deploy secure apps on your server. IIS has always provided strong support for protecting application content with authentication. Now, with ASP.NET Integrated mode, you can use the popular ASP.NET security features such as Forms Authentication, Membership, and Login controls to provide a complete authentication and access control solution for your entire app. You can often do this in minutes and without writing a single line of code.

The new URL Authorization feature, inspired by the ASP.NET URL Authorization feature, can be used to configure declarative access control rules for your entire application. The access rules can be used to allow or deny access to URLs within your application based on user names and roles. URL Authorization integrates seamlessly with the ASP.NET 2.0 Membership and Role Management features and can be used effectively with the ASP.NET Forms Authentication and Login controls to quickly enable user security for your applications.

The new request filtering feature provides powerful lockdown functionality, part of which was available in the popular URLScan tool. You can use request filtering to further lock down your site by rejecting requests containing suspicious data, protecting sensitive resources, or enforcing aggressive request limits.

IIS 7.0 also introduces a number of changes meant to make deployment and management of security settings easier. The new IIS_IUSR anonymous account is built in, which means that it is not affected by password expirations and does not require password synchronization between machines. The new IIS_IUSRS group, which replaces the IIS_WPG group, is automatically injected into the worker process' identity at run time, which alleviates the need to manually add the worker process identity to the group when using custom accounts.

Because of the built-in IIS_USR account and IIS_USRS group, application content that specifies access control lists (ACLs) for the anonymous IIS account and group can be simply copied from one IIS server to another without any extra steps required to preserve the security settings. This dramatically simplifies application deployment across the development-test-production cycle.

The distributed configuration system discussed earlier allows application owners to manage the necessary Web server settings directly in their application without having administrative access to the server. Application administrators can specify the required configuration in the web.config files inside their application content when uploading their applications to the server or use the IIS Manager tool in order to configure their applications remotely.

The IIS Manager tool offers secure remote administration via firewall-friendly HTTPS connections. With the ability to authenticate application administrators as either Windows users or custom user accounts via the Membership service, the Administration tool allows remote application management without the owner having any Windows access on the server.

As a server administrator, you have complete control over what settings are configurable by the application via the flexible locking support in the configuration system. Likewise, you can control which IIS Manager tool features are available to the application administrators managing their applications remotely.

Improved Diagnostics

Between all the new features supported in Windows, IIS 7.0, and your Web application, a Web server is a very a complicated system that often takes a lot of effort to troubleshoot. IIS 7.0 introduces a number of new features to help you monitor the operation of the server and debug application problems.

First, IIS 7.0 lets you peer into the real-time state of the server. This feature, called the Runtime State and Control API, or RSCA (pronounced "reeska"), exposes the active state of sites and application pools, running worker processes, and even allows you to view the currently executing requests on the server! It also enables you to control the state of the server, such as starting and stopping sites, or recycling application pools. In Windows Vista, you can access this information in the IIS Manager, via the appcmd.exe command-line tool, or programmatically using the Microsoft.Web.Administration API.

For example, you can view currently executing requests and the server stages where they are stuck. This lets you quickly resolve hanging request problems and track down which script is spinning your CPU (see Figure 6).

The RSCA capabilities come in very handy when you are investigating server issues or tuning server performance, both for being able to quickly see what's going on in the system and to control the server when performing troubleshooting. I often end up using appcmd.exe to view the state of application pools, examine worker processes, and start or stop offending applications pools to quickly zero in on the problem when investigating bugs in the office.

Figure 6** Tracking Down Stuck Scripts in IIS Manager **(Click the image for a larger view)

When errors occur in your Web application, they can be due to incorrect server configuration, application errors, or various environmental factors. The status code and standard error messages provide little clue to what went wrong and can make troubleshooting the server a nightmare. IIS 7.0 provides detailed error information about most errors, telling you exactly what went wrong, why, and how to fix it (see Figure 7).

Figure 7** Error Details Indicate the Problem and the Solution **(Click the image for a larger view)

The detailed errors follow a security scheme similar to the ASP.NET detailed errors. By default, you will only get the detailed information when browsing the Web site from the local machine. As before, you can also configure custom error pages for different error codes or redirect to a custom URL. The detailed error pages are also now localized, offering the error description in the preferred language of the client, if the language pack for the corresponding language is installed.

Diagnosing Errors without Debugging

What if the error condition you are experiencing is unknown or caused by a complex interplay of multiple Web server components? Not to worry-IIS 7.0 provides a comprehensive tracing mechanism that generates a verbose paper trail for each request, which can be used to track down the problem quickly.

IIS 7.0 adds more informational events on top of the Event Tracing for Windows (ETW) events added to IIS 6.0 in Windows Server 2003 Service Pack 1 (SP1). These events contain useful information about each stage of server processing you can examine to back-trace through request execution and pinpoint the place where things went wrong. These events can be routed to the Windows tracing infrastructure, which allows multiple Windows components including ASP.NET and SQL Server™ to link their tracing information into a single, logical execution trace for the request.

They can also be routed to the new Failed Request Tracing feature (also called FREB), which saves the trace logs into XML log files that can be viewed with the provided XSLT stylesheet (see Figure 8) or consumed programmatically.

Figure 8** Viewing XML Log Files **(Click the image for a larger view)

The coolest thing about Failed Request Tracing is that it can be left enabled on the server. It allows you to capture trace logs for requests that have encountered a configurable failure condition automatically while avoiding the performance penalty of saving the trace logs for requests that have completed successfully. For example, you can turn it on for requests that result in server errors or take more than a certain amount of time to complete.

With Failed Request Tracing, you can always capture the valuable tracing information when errors occur, even if they are intermittent or hard to reproduce. This can help diagnose and fix difficult problems that previously required hardcore debugging.

The underlying tracing infrastructure is exposed to IIS modules via the server extensibility model, allowing all server components, whether they ship with IIS or are developed by third parties, to emit detailed tracing information during request processing. IIS 7.0 tracing integrates with ASP.NET tracing via the System.Diagnostics API and the ASP.NET page trace, allowing managed modules to take advantage of the unified tracing model. To take things even further, you can write your own tracing modules that provide new ways to process and output the tracing information. For example, you can be the first one to write a module to save IIS tracing information to SQL Server or to a text file.

Improved Performance

While Windows Vista is a client operating system release and not intended for high-throughput production deployment (IIS on Windows Vista is limited to 10 concurrent requests at a time), it already showcases some of the major architectural improvements aimed at significantly increasing Web application performance. Coupled with the extensive performance work we are doing in the Windows Server "Longhorn" timeframe, these improvements will help IIS 7.0 elevate the performance of your server.

The first one is, of course, componentization. The modular nature of the server allows administrators to remove unneeded server features, saving memory and CPU usage during request processing. This can result in significant improvements in throughput and capacity on the machine. The ability to enable features in a granular way (turning them on and off for each application on your server) further enables applications to achieve performance gains in the case where only certain parts of your site require a particular feature.

The other notable performance feature in IIS 7.0 is the new IIS Output Cache. This feature provides support for re-using responses to expensive dynamic pages on the server, alleviating the need to perform the expensive rendering and database transactions in order to return the response to the client. The IIS Output Cache is a faster alternative to the existing rich output caching feature in ASP.NET, supporting a smaller set of caching functionality but providing enough flexibility to cache dynamic content in a performance-enhancing way.

By output caching your dynamic content, whether it is ASP.NET pages, PHP scripts, or CGI applications, you can frequently get a 5-10 times performance boost with much less load on your disk and database.

Backward Compatibility

IIS 7.0 should be able to run most existing applications without modification. This was a major feat given the extent of the architectural changes that were needed to support the innovation in this release. The configuration system has undergone the most changes, moving away from a centralized loosely typed configuration store to a delegated XML configuration file hierarchy. Both the structure and the storage of the configuration information are completely different from the IIS 6.0 metabase and do not enable access via the legacy configuration APIs.

IIS 7.0 solves this problem by providing an emulation layer for the metabase, which does on-the-fly translations between the underlying data in the configuration system and the interfaces exposed by the metabase ABO APIs. This, in turn, allows code written for the metabase to work correctly when accessing it via ABO, or higher-level WMI or ADSI scripts. Be sure to install the compatibility setup components to get this functionality, though.

While IIS 7.0 provides a new extensibility model for developing IIS components, ISAPI components are still supported. If you install the ISAPI Extensions and ISAPI Filters setup components, you will be able to run your extensions and filters as before. However, if you are developing new components, you should make sure to use the new extensibility model for a much more powerful and improved development experience.

A small percentage of ASP.NET applications that have runtime incompatibilities with the Integrated mode may have to be moved to an application pool running in Classic mode. In this case, you can run multiple applications in both modes side-by-side on the same server by placing them in separate application pools. For a complete list of ASP.NET breaking changes and general ASP.NET compatibility information on IIS 7.0, be sure to check out the ASP.NET compatibility whitepaper at iis.net/default.aspx?tabid=2&subtabid=25&i=1223.

Conclusion

The IIS 7.0 release in Windows Vista aims to provide the best architectural foundation for the next-generation Web application platform, focusing on the right core architecture, extensibility, and management platform for the Web server. Windows Vista gives you the ability to develop and test your applications on the same server platform as will be used to deploy it when the server version of Windows Vista becomes available.

As IIS 7.0 is released in Windows Vista, the Web Platform and Tools team's focus is shifting to getting the Web server ready for production environments and improving stability and performance for production scenarios. However, the core development and management features that ship in Windows Vista will remain the same-and when the server version of IIS 7.0 is complete, it's improvements are expected to become available for Windows Vista via a service pack. At that point, your client and server machines will once again be running the same exact version of IIS so you can continue to develop and test Web applications on your desktop running Window Vista.

To get started with IIS 7.0, be sure to check out the large number of exceedingly useful resources available on the Web, starting with the iis.net Web site, which is the new home of the IIS team. Our new site contains a portal for all things IIS 7.0, including detailed articles and walkthroughs for all IIS 7.0 features. Be sure to use the forums to ask questions and discuss problems with the IIS team and the IIS community.

You can also find in-depth coverage of IIS 7.0 and inside information on my blog, www.mvolo.com. Be sure to stop by. And do let me know what your favorite IIS 7.0 topics are and I will do my best to cover them in the blog.

Mike Volodarsky is a technical Program Manager on the Web Platform and Tools Team at Microsoft. He owns the core server infrastructure for ASP.NET and IIS. Michael is now focusing on improving the Web application platform in the next-generation Web server, IIS 7.0.