This week I was given the opportunity to learn first hand about IIS 7.0 from the product team. I plan to share a few details here to let everyone know what I have seen and what sounds exciting to me. I currently admin 3 web farms totalling about 15 servers running both IIS 5.0 and IIS 6.0. Between those servers there are about 20 sites and 50 applications. By no means do I consider this a huge installation, but it will definitely benefit from many of the new IIS 7.0 features. As the number of sites and applications continue to grow I am very much looking forward to IIS 7.0.

Today we were introduced to 2 aspects of IIS 7.0 know as Configuration and Core Server.

Configuration has changed significantly for the better. With IIS 6.0 the metabase was moved into an XML file. IIS 7.0 enhances this by using a new applicationHost.config file that incorporates a full hierarchy of settings just like .NET uses in its config files. ASP.NET is further enhanced by IIS 7.0 as the configuration of the web server, sites, and applications are fully merged with ASP.NET application configuration and follow a similar hierarchy of application. This will allows application developers to deploy the necessary settings for their application along with the application itself. That feature alone should save a lot of configuration management headaches as applications move from development and testing into production. The best part about the merging of configuration is that it is coupled with a merger of the processing pipeline. Gone will be the need to configure both IIS and ASP.NET for duplicate settings like Windows authentication. The ASP.NET 2.0 configuration API will also fully support the entire IIS 7.0 configuration files and settings.

Some other things I picked up today that I am looking forward to in terms of configuration.

• Configuration sections support a new attribute called configSource. This attribute allows you to put specific configuration sections into external files. This works much like the external appSettings files work today.
• There is a new attribute that allows external config file changes to trigger an application reset.
• Configuration elements and attributes can be locked from inheritance at a very granular level.
• Encrypting configuration is very simple to prevent it from being human readable.
• ASP.NET developers will now have as much access to the pipeline as ISAPI developers have always had. This means that all IIS extensions can now be written in managed code!
• One item I found a nice little ISAPI filter for allows you to set a specific cookie with a string that could be inserted into the IIS logs. This was useful for logging the userID with the request for example. (Windows auth automatically did it) In IIS 7.0 this now happens no matter which authentication mechanism you choose because the value comes from the User in the httpContext. The big thing is that now we have the ability to do things like this easily from managed code.
• For compatibility with existing IIS tools and scripts the metabase can be installed in addition to the new IIS 7.0 configuration. Those items in IIS 7.0 that also existed in IIS 5/6 are kept in sync between the metabase and the config files. This should allow full backwards compatibility with existing scripts and tools. Of course new features in IIS 7.0 are now synced with the metabase as they would not be understood by the metabase consumers anyhow.

Core Server has gone fully modular. What this means is that instead of IIS installations supporting everything out of the box they can instead support nothing. Each feature you want to add can be added as needed. New features can be added to the entire server or just to an individual site or application following configuration hierarchy. This creates a totally modular approach to IIS hosting. The big take away here is that ASP.NET httpModules and httpHanders are both things that you will want to get an understanding of if you plan to do any IIS extensibility. Of course Microsoft will be providing all the current IIS functionality through the 44+ modules and handlers that will come out of the box.

More benefits from the IIS core server:

• Patch management can now be done at the module level instead of the server level.
• Improved performance by scaling back the services and processing of requests to only what is needed.
• Improved security by reducing the attack surface.
• Ability to easilly extend through managed code. (Native code still an option for you ISAPI lovers)
• Full processing pipeline available to ASP.NET for all requested file types.

SMTP and FTP both are getting little or no attention in IIS 7.0 and at present are not being re-written. I have notcied that STMP settings can be configured in APS.NET 2.0 so at least you can set things up for sending Email from applications inside your ASP.NET apps without messing any SMTP server defaults in the IIS admin tool.

My biggest wish that currently is not answered by IIS 7.0 is that it be decoupled from the operating system. Apache doesn't force you to run on a server SKU and each new version does not have to wait for the next server release. As an ASP.NET developer I want to be able to run the same hosting environment on my development machine that I will have on the production server. XP Home and Pro should both support IIS 7.0 as should Windows 2003 Server. Please, Microsoft, do not force us to upgrade to Longhorn for a product that has nothing to do with the operating system. Also, please only include operating system specific features in http Modules so that they can be added for customers who chose to run on Longhorn. I love IIS, but it's tight coupling to Server OS's is not necessary or appreciated!

Well, that about does it for the features I was exposed to today. I hope to complete this series on IIS 7.0 over the next few days.