I'll never forget the moment I finally gained a true understanding of IIS 7.0. It was when Bill Staples, Microsoft's product-unit manager for IIS, explained to me, "We took the capability of IIS 6.0 and broke it up into modules, then integrated ASP.NET into the pipeline." Abruptly, I realized what he meant, and I knew that nothing in IIS would ever be the same.
If you've used IIS in the past, you're going to be fascinated by what Microsoft has done with IIS 7.0, which will let you do far more than any previous IIS version permitted. Many of the intriguing details of the new version cluster around the modular core and .NET integration—without a doubt, huge new features that you need to understand. My first instinct is to walk you through the new features, one by one, but on second thought, I'd like to approach IIS 7.0 from a more practical perspective.
If you're like me, when you obtain a major upgrade of software you know and use, the first thing you do is start the UI and see what the new version looks like. Doing so helps drive discovery in a task-oriented way that's well suited to administrators. So, for this IIS 7.0 overview, let's start at the beginning—with a look at the new Internet Information Services Manager tool. (As we take this tour through IIS 7.0, please bear in mind that some of the details you're about to see might change before the official product release.)
The IIS Manager Interface
My experience with the IIS 6.0 interface was that it was obviously just a modified IIS 4.0 console. In contrast, I had no problem recognizing the IIS 7.0 IIS Manager interface, which Figure 1 shows, as an entirely new application. IIS Manager is a rich client experience written as a Winform application. Because it isn't a Microsoft Management Console (MMC) snap-in, typical Microsoft networking isn't necessary to connect to and manage remote IIS 7.0 servers. Communication from the IIS Manager tool occurs over HTTP or HTTP Secure (HTTPS) to a Web service listening on the IIS 7.0 server. You can, of course, configure the service to secure, limit, or reject remote connections.
IIS Manager's left column, Connection Manager, displays any IIS 7.0 servers that IIS Manager is connected to. For ease of use, connections can be named, and the default name is the server name. In this case, the connection name is ITProMagazine. The server name is LH-63X2OGRFBG2F, as you can see at the top of the center column.
The icons and descriptions in IIS Manager's center column represent the new grouping of properties and settings. Gone are IIS 6.0's familiar but somewhat oddly organized tabs. Because IIS 7.0 is a more complex solution, you'll find many more settings, and, unlike previous IIS versions, every setting is exposed. You can toggle the display mode for the Name and Description columns to show the Detail view (as you see in Figure 1), Icons, Tiles, or List view.
IIS Manager lets you nimbly filter the display to show only the choices you want to see. You can click one or more entries in the Areas and Categories boxes to instantly filter the list to just the indicated options.
Task Oriented
If you click the server name, then click Sites, IIS Manager presents a display that should make you feel right at home: a tree view of sites in the Connection Manager pane and the Web sites listed in the center. On the right, you now see Tasks, listing the most common activities. The All Properties entry under the Edit Site task is one of my favorites, letting me quickly and directly edit any setting rather than needing to wade through a bunch of screens.
In the All Properties window, which Figure 2 shows, you can edit all the property settings for any item you select. In this example, I'm setting the Log File to Daily. To modify this setting, all I needed to do was select Sites, click All Properties, and find the entry I wanted in the All Properties window.
A New Metabase
So far, I've talked about some ways that IIS 7.0 improves on existing features. Now, I want to talk about something very impressive that's new to IIS 7.0. In the Sites pane, when I right-click the Web site and select Connect to Site Configuration (web.config), a new Default Web Site entry appears (as Figure 3 shows). This entry lets me edit settings and contents for the Default Web Site. You might ask, What's going on here? Why can I now edit settings in two places?
When you're creating and configuring sites at the Sites level, IIS now records the changes you make in a new data store called ApplicationHost.config. This XML text file completely replaces the old IIS metabase. ApplicationHost.config is human-readable, well formed, and fully configurable through a set of exposed APIs that lets developers more easily write code that manages and creates Web sites. As with the metabase, administrators shouldn't need to directly edit ApplicationHost.config very often, particularly because all IIS properties and many ASP.NET properties are configurable in the IIS Manager.
In addition to using ApplicationHost.config, you can store IIS configuration settings in a web.config file that resides in the Web root folder. You can, for example, set up a unique default document for a Web site in the web.config file. Then, if you copy the content to a new server, the default document setting moves (via the web.config file) with the content. IIS 7.0 sees this setting and reads in the changes (providing the administrator permits it). Extend this delegation concept to nearly any setting on the Web site, and you get an idea of the power of this functionality. You no longer have to be an administrator to manage a Web site's configuration. Of course, you can prevent the use of any web.config settings, and delegation is disallowed by default.
Now you understand why Figure 3 shows two Default Web Sites. When you're editing at the Sites level, you're editing ApplicationHost.config. When you "connect" to the Default Web Site and edit the resulting node, you're editing the web.config file. Very cool.
New Security Features
There's big news regarding IIS 7.0's new security capabilities. For the first time, you can create user accounts in the IIS UI! Here's some even bigger news: IIS 7.0 is integrated with .NET Role Providers in Windows Vista and the next Windows Server version, code-named Longhorn. Therefore, the data store for your users can be something other than the local SAM or Active Directory (AD). IIS can authenticate users stored in a Microsoft SQL Server database or any other store for which you have a .NET provider.
IIS 7.0 and .NET integration also means that IIS 7.0 can now offer .NET Forms Authentication as one of its built-in capabilities. Previously available only to .NET applications, Forms Authentication can now be enabled for any programming language that runs on IIS, as well as static content.
Combining the Role Providers with Forms Authentication gives rise to some amazing possibilities. For example, suppose you want to use ASP.NET Forms Authentication to authenticate users of your PHP Hypertext Preprocessor (PHP) application to a DB2 database. No problem. The application requires no special coding to accomplish such a task.
I don't have enough space to mention all the security-related improvements in IIS 7.0, but one of my favorites is request filtering. URLScanstyle filtering capabilities are now built in to the IIS UI.
Troubleshooting and Diagnostics
Server administrators are keenly interested in anything that helps them identify and clarify problems. Wouldn't it be nice to click an application pool and see all executing requests and observe how long they've been running? Your wish is granted.
At any time, you can view the Worker Processes screen (which Figure 4 shows) from within the IIS Manager tool to see a worker process's current memory utilization, CPU use, process ID, and application pool assignment. In the figure, you can see that a pool is consuming too many CPU resources. To see all requests currently running in the worker process assigned to this pool, you can right-click the pool and select View Current Requests. In the example that Figure 5 shows, test.asp is running in Site 1, and it has taken 28,111 milliseconds to process.
If you're familiar with the tracing capabilities that IIS 6.0 Service Pack 1 (SP1) offers, you'll be glad to know that those features are included and extended in IIS 7.0. Tracing in IIS 7.0 (and IIS 6.0 SP1) isn't the same as auditing or tracing in ASP.NET applications. The IIS team has built in hundreds of "events" that you can have recorded in the trace logs.
Enabling and configuring tracing is simple. Simply specify the kind of URL event you want to trigger tracing, as well as the providers you want to report, by writing events to the Failed Event Request logs. For example, you can trace all authentication events related to http://servername/problemapp.aspx, all HTTP 500 errors for any content, or .php events that take more than 10 seconds to execute.
After you configure tracing, IIS will automatically generate trace logs and place them in the \inetpub\faildreqlogfiles\site id number folder. Trace logs are well presented and come preformatted for readability. Event tracing in IIS 7.0 is fully extensible.
Module Magic
Now for the big finish. Typically, to enable and disable features in IIS, you set or clear check boxes or otherwise set properties. In IIS 7.0, you implement features in more than 40 modules. You can load, remove, or replace any of these modules. If you aren't using a feature (e.g., Digest Authentication), you can simply remove it from IIS 7.0 completely, as Figure 6 shows.
Similarly, you can add modules to IIS 7.0 to extend its capabilities. With this functionality, you're able to configure servers that are optimized to do exactly the tasks you require. Also, you can deploy additions to IIS 7.0 that provide entirely new capabilities. For example, you might load a module that would add headers and footers to every page on the Web site. Every page on every site would instantly be affected—without having to modify the original code. Perhaps you would like IIS 7.0 to authenticate to an antique back-end system that has a "unique" authentication protocol. To enable this capability, your developers could write such a module in managed (.NET) or native (C++) code. You could add custom compression, logging, security, monitoring, or any functionality you choose.
You can load modules at the Web server level or per Web site via the web.config file. You can store configuration elements for modules in the web.config file and copy them with the Web content. In this way, a Web site can be fully self-contained with completely portable application code, security principles, Web site structure, and content.
>When and Where
Unlike Windows XP Professional's IIS implementation, the Windows Vista version of IIS 7.0 won't be limited to one Web site. Therefore, developers can much more easily create applications that are intended for deployment in multiple Web sites. There's still a limitation on the number of connections, which is 10 or fewer depending the Windows Vista version.
IIS 7.0 will be available with Windows Vista and Longhorn. Microsoft is planning to release Windows Vista this year and Longhorn in 2007. The company currently has no plans to release IIS 7.0 on any other version of the OS. These dates might seem a long way off, but it won't be long until developers can start working with IIS 7.0 on Windows Vista.
If you're an IIS geek like me, it's time to rejoice. IIS 7.0's modularity promises deeper integration into heterogeneous environments through precise customization not easily attainable in previous versions. The capabilities of the IIS Manager tool are unparalleled. Delegation, troubleshooting, and security management are all significantly improved, as is IIS Manager itself, which is no longer bound by the MMC framework.
