Special Coverage: Windows Server 2008

Getting Started with IIS 7.0

Isaac Roybal

At a Glance:

• IIS 7.0 Architecture changes
• Managing IIS 7.0
• Backward compatibility
• IIS 7.0 troubleshooting

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, see blogs.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.

Isaac Roybal is a Product Manager in Windows Server at Microsoft. His responsibilities cover all things Web-related with Windows Server. Isaac has worked with Windows Server since Windows NT 3.51 and IIS 4.0. Before that he was an Operations Program Manager for the Office Internet Platoform & Ops group. He has an MCSE certification in Windows NT 4.0, Windows 2000, and Windows Server 2003.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.