Rick Strahl says: Get Excited About IIS 7.0.  Having seen it myself I wholeheartedly agree. 

One feature of ASP.NET configuration files and the new configuration files for IIS 7.0 is an attribute known as configSource.  For the elements that support this you will have a few different options for dealing with configuration.  This value in this attribute can point to any file path that is lower in hierarchy, but may not be higher or on a different disk.

With this feature you can manage configuration sections in separate files.  Also, in IIS 7.0 you can include another attribute to flag the configuration not to cause an application restart when the configSource file changes.  Perhaps that will be in ASP.NET 2.0, but I have not discovered it yet.  By default it will cause a restart of the application just as web.config changes do.

22.April.2005 Update: I have changed my feature request concerning delegated administration.  I would like to be able to delegate that site and application owners both be able to create new applications within their physical folder hierarchy.  The creation of virtual directories can remain a server administrator function.

Today the focus of the IIS 7.0 DevLabs centered around new monitoring and diagnostics features as well as security.

Monitoring and Diagnostics apparently is an expansion of some new things that have been released with Windows 2003 Service Pack 1.  I was not aware of any new monitoring features in this service pack so I now have some new things to explore that I can use today!  I am told the best place to start to get a handle on the new features is the webcast: IIS 6.0 Service Pack 1 Tracing: Inside and Out.  In addition to this I imagine that some of the new performance and health monitoring features in ASP.NET 2.0 will also be merged in.  This area of IIS and ASP.NET development is something I have not spent much time, but it is certainly needed.  It has been far too difficult to troubleshoot IIS hosted applications.

IIS 7.0 is going to allow us to get information on the state of all running sites, application pools, worker processes, and application domains.  Additionally it looks like we will get programmatic control of starting and stopping some of these services at levels that are lower than the site.  The ability to drill into the currently executing requests through the Admin Tool and WMI is going to finally enable us to easily see which applications are hogging the CPU and memory.

The ASP.NET tracing model has made its way into IIS and both can actually be combined into a single log.  Essentially IIS becomes and ASP.NET trace listener if you want to configure it that way.  By merging the tracing we get a complete picture into the request/response cycle with all trace details in order and in context.  A fantastic feature that will be included with IIS is the ability to automatically log tracing details for failed requests.  For example, if the application does not respond, is too slow to respond, or responds with an error, the auto-tracing feature can take care of guranteeing that the trace details get recorded. There is an admin service that runs outside of the IIS server itself, so even if the application fails completely, trace data still gets written, which apparently is not the case with ASP.NET alone.  Modules participating in the IIS pipeline can be both providers and consumers of tracing output.  Administrators will appreciate the ease with which they can enable or disable tracing through the admin tool.

Security has been greatly enhanced as I have previously alluded to.  Today we dove deeper into some of the scenarios and looked at how to start with totally locked down server and slowly add functionality to it as needed.  This differs greatly for current defaults where most IIS functionality is enabled out of the box.  IIS 6 certainly improved on this over IIS 5, but the modular architecture of IIS 7 takes this idea to the extreme.  Limiting the installed modules reduces the attack surface and patch requirements to only those features that are installed.  For example, if you plan to only server static content you would not need to worry about attacks and patches for ASP or ASP.NET.

Wearing my site and server administrator hat I get very excited about the new security delegation features as I mentioned yesterday.  An additional and very helpful aspect of this includes the ability to delegate administration to non-Windows users.  That will be fantastic for hosting scenarios.  Delegation follows the standard hierarchy of site and application. Hmm, I wonder if non-Windows uses can be configured as server admins?  Comments IIS team?  Currently only server admins are able to create virtual directories and applications.  Personally I see this as a huge mistake.  As a consumer of hosting services I have to have the ability to create IIS applications within my hosting space so that I can run applications like dasBlog and others in a sub folder of my site.  If you agree then join me in asking for delegated administration of virtual directories and applications.  At the moment this is my 2nd biggest request for the IIS team.

Putting my ASP.NET developer hat (favorite) back on I'd like to buy Scott Guthrie at least a case of beer (or whatever his favorite beverage is) for merging the authentication an authorization of IIS and ASP.NET.  (Share it with the team doing the work!)  Finally the authentication options are all configured in only 1 place.  In addition I can just interact with the reuesting User in the context and not be concerned about how that user was authenticated.  Further we finally have a solution the problem of applications that want to first check for a Windows user and then fail over to forms authentication.  Today that scenario requires configuring a page to use Windows authentication in IIS and then handling a security exception and and it gets messier from there.

Good stuff abounds in the IIS 7.0 security picture:

• Impersonation has been improved so that is not so confusing about which account the application is running under.
• All authentication mechanisms can be applied to all content, including ASP.NET 2.0 membership authentication solutions.

Note to self: Research ADFS (Active Directory Federated Services) and how it may tie into a custom SSO solution.

URLScan and some of the other tools currently available to tighten security and assist with URL authorization have been replaced by, as one would imagine by now, powerful new configuration elements and of course corresponding modules.

• The features of URL Scan have been built in and enhanced.
• System policy can enforce authorization and serving rules.
• There are 12 new 404 error sub status codes to help determine the rules blocking access.
• Authorization is granular all the way down to the URL level.
• Rules can be deployed with the application as expected when using config files.
• File extensions can be restricted.
• Verbs can be restricted. (POST, GET, etc)
• Specific files and folders can be protected from being served. This can be accomplished with "hidden namespaces" or sequences.  Sequences are string patterns that allow you to block say all URI's that contain "bin" or something like that.  This enables easy blocking of specific patterns that may exploit vulnerabilities as they come up.

Tomorrow the DevLab will wrap up and I will head home.  Stay tuned for the final post in the series.

20.April.2005 Update:  IIS PM Shai Kariv informed me that the managed configuration API will allow for interaction against remote machines on the network.  Previously I had stated that only WMI made this possible programmatically.  Of course this is disabled by default.  To enable it run aspnet_regiis -config+ on the remote machine to enable remote access to configuration.

Today the fact that IIS 7 centers around configuration files was driven home.  We had opportunity to learn about and experiment with the new IIS Admin tool and the WMI scripting interfaces.  By the end of the day I was asking questions about the different features each of the administrative tools provides.  I still have much to learn, but I do have a bit to begin thinking over.  Here are the highlights.

IIS Admin Tool has been completely redesigned and architected.  At this point the classic tree view we are used to does not even exist.  I and others are asking that it be brought back for rapid navigation of servers, sites and applications.  There is a strong move in the tool toward specific administration roles.  For those that focus on a specific area in the configuration hierarchy you will find that the tool nicely limits your interaction with the server to appropriate areas.  To further enhance this limited administration there is a new delegated security model.  This is probably my favorite new feature of the tool.  My second favorite feature is the ability to administer sites remotely over the Internet.  Of course it can use SSL to keep the data secure and also requires credentials to administer a remote machine.  I think the combination of delegated security and remote administration will make this tool popular for hosters and very helpful for application developers as well.  Developers are simply going to love IIS 7 because they finally will have the ability to configure the setting they need without having to request them from an administrator.  Admins, don't worry, developers will not have more access than they should not.

A few more take aways on the IIS Admin Tool:

• It is fully extensible.  Microsoft uses the public extensibility scheme themselves for the tools they have built in.
• New or updated modules are synced up with the admin tool when it connects to the server.
• Creating new modules for your custom configuration sections is relatively painless.  I imagine it will get even better be the time we see the first beta.

WMI and Scripting have been enhanced.  The WMI programming model has been cleaned up to make it easier to use and consistent between the different objects that are exposed for IIS.  Having never worked with WMI I discovered a whole world of automation that I have been missing out on.  I look forward to working more with WMI now and into the future with IIS 7.0.  WMI turns out to be the only programmable interface that works against remote servers on a network.  The .NET managed APIs for configuration are great against a local machine, but only WMI will let you hit a remote machine from code.  I asked around and learned that WMI uses traditional COM and DCOM to remote the calls to the remote machines.  Apparently both WMI and the GUI Admin Tool ultimately use the .NET configuration API to get their work done.

Some additional new features offered up through WMI include:

• Enumeration of Application Domains and Worker Processes
• Access to custom configuration sections (using new tools to automatically update the required MOF)

At the end of the day I had opportunity to continue on my soap box with the request to de-couple IIS from the operating system.  This time I made the request to Scott Guthrie.  I told him that I am going to keep requesting it right on up to Steve Balmer.  I suppose I could take it Bill Gates, but I probably should reserve any requests to Bill for things of slightly more importance.  Not that I will ever have an audience with Steve or Bill (notice the first name basis I ave with people I don't know), but it is fun to talk about.  Please join in this request if you also would like to see IIS removed from the Operating System beginning with IIS 7.0.  Perhaps if we make enough noise about we can get the right people to respond.  Anyone want to start a new site for the De-coupling campaign?  Perhaps something like decoupleiis.com (it's available at the moment).

Speaking of new domains, I registered IISSeven.com last night.  I plan to dump information about IIS 7.0 there.  To begin with I will aggregate my IIS 7.0 blog category and start linking to IIS team member blogs as well.  I guess I had better do some work tomorrow getting those team blog URL's.