BetaBox
First Look at IIS 7.0
Brett Hill
When I saw my first demo of IIS 7.0, I thought "this changes everything." The new version changes the application’s architecture and introduces some exciting changes that greatly improve the capabilities of IIS. These changes will affect IT administrators and developers alike. So rather than discuss the "how-tos" of IIS, I’ll introduce some of the exciting changes in IIS 7.0 and discuss their significances.
Modular is Flexible
In IIS 5.0 and IIS 6.0, most of the code that provides basic features—such as delivering static content, authenticating users, displaying a virtual directory, and so on—resides in a single DLL. While there are some benefits to having all functionality in a single executable, there are also some drawbacks. For example, if the IIS developers at Microsoft want to add a new feature, they essentially have to issue a new release of the application. This makes it challenging to provide fixes and new functionality. And when all the features and functionality are contained in the same DLL, the user can disable a feature to prevent execution of that code, but the code remains loaded and resident in memory.
To address these problems, as well as provide additional benefits, IIS 7.0 has been modularized. In other words, the monolithic DLL has been broken up into its component parts.
While you, the user, can still enable and disable functionality like you could in IIS 6.0, you can go even further with IIS 7.0 and completely remove from memory any modules you do not require. If you don’t use Digest authentication, remove the module! Don’t use Directory Listings? Just remove it from the list of modules and never worry about it again. This improves security since features you don’t need cannot be enabled by mistake or by malicious intent.
In addition, the memory footprint of IIS is reduced since code that you don’t require isn’t loaded. While it is still too early in the development of IIS 7.0 to speak of performance enhancements, the IIS team anticipates some performance benefits from reduced code overhead.
From the IIS team’s viewpoint, updates can be handled more efficiently. Updates and new features can be issued without releasing an entirely new version of the app.
To this point, however, I have yet to mention one of the biggest benefits. With IIS 7.0, you can add any functionality you like directly to the server by writing your own managed (.NET) or unmanaged modules and adding them to the core of IIS. For the first time, developers can easily extend the capabilities of IIS to do things that have only been accessible to those willing to tackle the complexity of ISAPI filter programming. Do you want your IIS 7.0 server to authenticate to a legacy server using a protocol long forgotten and unsupported? No problem. Want to design your own IIS log file format? Go for it. How about a module that tracks bandwidth used per user, site, or application? Absolutely. The possibilities are endless, and we’re just getting started.
.NET Integration
IIS 7.0 is designed to work seamlessly with .NET-based applications. This means it can take advantage of all the capabilities of the .NET Framework and all the deep integration into the Microsoft platform that .NET allows.
For example, in IIS 6.0, if you deploy .NET applications and enable Forms authentication, your static content is not protected by the security settings in your .NET app. If you aren’t familiar with Forms-based authentication in ASP.NET, imagine that you could put all your users and passwords in a store, such as a file or database instead of the local Security Account Manager (SAM) or Active Directory®. You can do that with ASP.NET and it works great. The big advantage is that since your users, groups, and passwords live in a database or file, your entire site is much more portable. In some cases, performing an xcopy can move your entire application and security configuration.
The problem with Forms authentication in IIS 5.0 and IIS 6.0 is that the security only applies to files mapped to the .NET Framework. For example, if you deny Sally access using Forms authentication via your web.config, she won’t be able to access .aspx pages. However, she can access .htm, .asp, .gif, .jpg, and any other files that are not mapped to the .NET Framework.
This, however, isn’t the case with IIS 7.0. Since IIS is integrated with .NET, Forms authentication is built in and can be used for all kinds of content, not just .NET applications. If you want to enable Forms authentication, you can store your users in a SQL Server™ database (XML or Access will also do). This will work no matter what kind of content you have.
.NET Framework integration also means changes to the IIS settings store known as the metabase. In IIS 4.0 and IIS 5.0, the metabase was a proprietary binary file. This evolved into an XML file structure in IIS 6.0. In IIS 7.0 the transformation goes another step further by merging it into the .NET config file hierarchy.
In other words, IIS settings are now managed in an XML-formatted text file that can be configured directly from .NET-based applications. This allows developers to write code that can configure its own Web site and directories, assign security principals, and enable or disable IIS features from within your code. Administrators can more easily administer servers via .config files as they are easy to read, modify, back up, and deploy. In addition, Windows Management Instrumentation (WMI) has been greatly enhanced to facilitate the management of IIS servers using scripts.
.Config Constructs
The applicationhost.config and Web.config files replace the metabase as the primary store for the IIS server configuration and settings. Applicationhost.config lists the core modules to load, as well as defining Web sites, virtual directories, and other values as required. For example, the snippet from applicationhost.config that is shown in Figure 1 defines a Web site.
Figure 1Applicationhost.config Excerpt
<sites>
<siteDefaults>
<logFile directory="C:\WINDOWS\System32\LogFiles" />
</siteDefaults>
<applicationDefaults applicationPool="DefaultAppPool" />
<site name="Default Web Site" id="1">
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
</bindings>
<application path="/" applicationPool="DefaultAppPool" >
<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot" />
</application>
<logFile directory="C:\WINDOWS\System32\LogFiles" />
</site>
</sites>
Individual Web sites and applications can be customized to add or remove capabilities as required via a web.config file, which resides in the Web root or application root folder. For example, the settings shown in Figure 2 configure a Web site to turn off Anonymous and Windows Authentication, and enable Basic Authentication.
Keep in mind that these settings are completely manageable from the new Web Manager, .NET APIs, WMI, or your favorite XML or text editor.
Figure 2Enabling Basic Authentication
<configuration>
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="false" />
<anonymousAuthentication enabled="false" />
<basicAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</configuration>
Management and Configuration
You are no longer bound by the Microsoft® Management Console (MMC). Instead, IIS 7.0 sports a completely redesigned user interface called the Web Manager. Since it’s a Windows Forms application, the Web Manager is completely integrated with the .NET Framework and can be extended to include custom features and configured to expose only the capabilities that you require.
In addition, you can extend the Web Manager to expose settings that are part of custom applications. This allows Web developers to use the Web Manager to configure their own applications. Application settings can be stored as part of the IIS configuration store so when you copy the .config file to another server, the application configuration is also replicated.
Of course, you may not want someone who manages a Web site running such an application to be able to make changes to the entire IIS server’s configuration. For this reason, IIS 7.0 provides the ability to delegate administration. You can specify which users have access to particular features in the Web Manager, and even completely hide features from certain users. In this way, you can restrict a Web site operator to managing the functions that affect just their site, rather than giving them elevated privileges on the server.
When you open the Web Manager, you specify which IIS 7.0 installation you want to manage. If you specify a remote server, Web Manager connects to it using HTTP or HTTPS via a Web service. This allows you to manage IIS 7.0 in a secured environment where RPC (remote procedure call) network communications are prohibited through a firewall.
Tracing and Diagnostics
While some of the new features are designed for administrators, and others apply more to developers, there are some new features that are important to both communities. For instance, Tracing and Diagnostics has been greatly enhanced. In the Web Manager, you can see which requests are currently executing in an Application Pool. Tracing allows you to automatically cause a trace of internal events to be recorded when a specific error code is returned for a certain URL. This is similar to Windows Server™ 2003 SP1 tracing for IIS 6.0, as discussed in this
webcast, but this feature has been greatly enhanced for IIS 7.0.
Meanwhile, URLScan functionality is built in and extended. You can create rules for request filtering that reject sequences based on action, length of URL, contents of the URL, and so forth. This is very powerful protection against future, as-yet unknown attacks. Considering the capabilities offered by URLScan, delegated administration, the ability to remove unnecessary code from memory, and various other features , security is clearly a big part of IIS 7.0.
Getting Ready
With all these changes, it’s natural to wonder how much you have to adapt your existing applications and management tools to be able to use IIS 7.0. The good news is that while a lot of features were added, the process model for IIS has not changed much and the same applications you run now should run even better in IIS 7.0. Also, most of the scripts and management tools you use to adjust settings for IIS 6.0 can be used on IIS 7.0 as well.
Since IIS configuration and ASP.NET configuration are merging, you can get a head start on IIS 7.0 management by studying
ASP.NET configuration on IIS 6.0. Look at how settings in web.config can adjust ASP.NET app events, including the type of authentication used, authorization, and locking down settings by use of the
Location tag. You can also benefit immensely from understanding how to use tracing in Windows Server 2003 SP1, as previously mentioned.
Once IIS 7.0 is released, you will see new applications that integrate deeply with IIS in ways never before possible. Applications will extend the capabilities of IIS 7.0, integrate with the configuration store, and interact with the administrative subsystem. Forms authentication will be used with non-Windows principles against any content. And delegated administration will allow secure management of Web sites by non-administrators. The list is long and impressive.
But more than just a list of new capabilities, IIS 7.0 represents a new era of Web servers from Microsoft, where an application does not just deliver content from IIS but becomes part of it, and where administration and development are integrated with the same tools, scripting languages, and services that the IIS team uses.
Prerelease info in this article is subject to change.
Brett Hill is a Microsoft IIS Evangelist. Prior to working for Microsoft he spent three years as an IIS MVP and ran his own IIS training business. He still operates IIS discussion groups at http://IISlists.com. You can reach Brett at brett@iisanswers.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.