Just Another IIS Blog : IIS News Item

Now Available: URL Rewriter Tech Preview 1

thomad — Sat, 31 May 2008 00:31:00 GMT

Today we are releasing Technical Preview 1 of the URL Rewrite Module for IIS 7.0.

The URL Rewrite Module provides a rule-based rewriting mechanism for changing request URL’s before they get processed by IIS. The module supports regular expression based URL rewriting logic or a simpler wildcard-based URL rewriting logic. Rewriting decisions can be based on the URL, HTTP headers and server variables. While the primary purpose of the module is to rewrite URLs, it also has functionality to perform redirects, send custom responses and abort requests based on the logic expressed in the rewrite rules.

Install the URL Rewrite Module today!

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x86)

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x64)

Feature Set

Here is a quick feature overview:

Rules-based URL rewriting engine. Rules are used to compare/match the request URL with and what to do if comparison was successful.

Regular expression pattern matching. Rewrite rules can use ECMA-262 compatible regular expression syntax for pattern matching.
Wildcard pattern matching. Rewrite rules can use Wildcard syntax for pattern matching

Back-references to patterns and conditions. Back-references are used to capture parts of a matched URL so that it can be re-used later in a rule when constructing a substitution URL string. Back-references are available with regular expression and wildcards patterns.
Global and distributed rewrite rules. Global rules are used to define server-wide URL rewriting logic. Global rules cannot be overridden or disabled by lower configuration levels. Distributed rules are used to define URL rewriting logic specific to a particular configuration scope, e.g. an web application.
Access to server variables and http headers. Server variables and HTTP headers provide additional information about current HTTP request. This information can be used to make rewriting decisions or to compose the output URL.
Various rule actions. Instead of rewriting a URL, a rule may perform other actions, such as issue an HTTP redirect, abort the request, or send a custom status code to HTTP client.
Rewrite maps. Rewrite map is an arbitrary collection of name-value pairs that can be used within rewrite rules to generate the substitution URL during rewriting. Rewrite maps are particularly useful when you have a large set of rewrite rules, all of which use static strings (i.e. there is no pattern matching used). In those cases, instead of defining a large set of simple rewrite rules, you can put all the mappings between input URL and substitution URL as keys and values into the rewrite map, and then have one rewrite rule which references this rewrite map to look up substitution URL based on the input URL.
UI for managing rewrite rules. Rewrite rules can be added, removed and edited by using "URL Rewrite Module" feature in IIS Manager.
GUI tool for importing of mod_rewrite rules. URL rewrite module includes a GUI tool for converting rewrite rules from mod_rewrite format into IIS format.

More information

URL Rewrite Module Walkthroughs - http://learn.iis.net/page.aspx/460/using-url-rewrite-module/

URL Rewrite Module Configuration Reference - http://learn.iis.net/page.aspx/465/url-rewrite-module-configuration-reference/

Questions and feedback

URL Rewrite Forum - http://forums.iis.net/1152.aspx

The IIS Process Model Features

thomad — Thu, 08 May 2008 06:08:48 GMT

A process model is needed to run more than one web-site, web application or web-service securely and reliably on a single machine. In Shared Hosting scenarios hundreds or even thousands of web-sites run on an individual machine. The code running on these web-sites is usually not well tested, if at all. Without a powerful process model the result would be extremely poor reliability. But a process model not only guarantees availability; it also needs to isolate them so that individual web applications don't interfere with each other.

The Windows Process Activation Service (WAS) is the system component providing the Process Model in IIS 7.0. This article discusses the WAS features and functions.

1. Application Pools

Processes are the containers that provide isolation and security boundaries in the Windows Operating System. Consequently web applications or web-sites have to run in separate processes in order to achieve isolation between them. In the IIS terminology the management unit for these separate IIS processes is called 'Application Pool'.

An Application Pool can be configured to run a group of URLs, i.e. web-sites, web applications or web-services. When a client requests one of these Application Pool URLs an IIS worker process (w3wp.exe) is spawned by WAS to execute the code necessary to send a response. WAS's main task is to manage Application Pools - WAS spawns worker processes, monitors their health, recycles them if necessary and makes sure none of them consume more resources than specified in the corresponding AppPool configuration. WAS is also the arbiter and collector for run-time and state data, e.g. performance counters, site and Application Pool state.

2. Architectural Diagram

The diagram below shows the core pieces of the IIS7 architecture.

Configuration is stored in the applicationhost.config file (left).
HTTP.SYS is a kernel-mode component that listens to the network, accepts connections, assigns requests into Application Pool queues and queues these requests if no IIS worker process is running. HTTP.SYS also caches responses and does SSL in IIS 7.0
The worker process on the right hosts all custom code (e.g. ASP and ASP.Net pages, modules, ISAPI filter and extensions etc.). There can be hundreds of these worker processes depending on how the IIS Administrator decides to isolate his web-sites and applications. IIS worker processes pick up waiting requests from the corresponding HTTP.SYS request queue.
The Windows Activation Service is a system service that runs in SVCHOST.EXE. WAS reads configuration from applicationhost.config, reacts to configuration changes, manages worker processes, controls their live time and health, recycles them if necessary and prevents resource exhaustion. W3SVC is another service living in the same SVCHOST.EXE as WAS. W3SVC hosts the HTTP specific part of the IIS process model; W3SVC configures HTTP.SYS with the URLs to listen on and is called by HTTP.SYS if requests arrive and worker processes are needed.

3. Process Model Features

Web-Sites and applications get the following benefits by running in the WAS provided infrastructure:

Efficient Resource Management

On-Demand Activation

Resources like RAM and CPU are scarce in multi-tenant scenarios. WAS will start an IIS worker process only once requests for a particular web site or web application arrive.

Idle-timeout

Because resources are usually scarce WAS can shutdown web applications based on a configurable idle-timeout.

Health Monitoring

To ensure their health WAS monitors the worker processes it spawned. Health messages are periodically sent to each running worker process. If the worker process doesn't respond in a configurable time interval the worker process will be recycled or killed. This way undetected deadlocks in worker processes get automatically fixed by restarting the worker process.

Startup Limit

Part of the Rapid-Fail Protection feature is the Startup limit. If a worker process doesn't report back to WAS within the configurable startup-limit it will be killed and the Rapid-Fail-Protection counter is incremented. Application Pools are stopped, i.e. restarting the worker process will not be tried anymore, if the Rapid-Fail-Protection counter reaches a configurable limit within a configurable time limit. This prevents scenarios where worker processes hang or crash during startup.

Shutdown Limit

A worker process also has to shutdown in a configurable limit. If the shutdown doesn't happen in this time the worker process gets killed by WAS. This prevents resource overuse due to processes hanging in their shut-down phase. Additional shutdown settings allow an executable to be started (e.g. a debugger) when the shutdown doesn't complete within the allotted time.

CPU affinity

Configuration settings allow WAS to start worker processes that are affinitized to one or more CPUs. This prevents tenants from interfering with each other if they share the same physical machine.

User Profile

WAS can start worker processes with or without loading the user profile.

Security

Customizable User Account

IIS worker processes can run as a preconfigured process identity or built-in accounts (LocalService, LocalSystem, NetworkService). Built-in accounts are advantages because they don't require password management. If a custom user identity is used the password is automatically encrypted. Configuration settings can be replicated to multiple machines by sharing the configuration encryption keys across machines.

Job Object Features

Job objects allow administrators to restrict worker processes to a particular CPU limit. A configurable action is taken if this CPU limit is exceeded. Job objects will also make sure that processes spawned by the worker process get terminated.

Configuration Isolation and Security

Before WAS starts an Application Pool and its worker process it generates a unique configuration file for this Application Pool. WAS also creates a unique SID for each Application Pool (similar to Service SIDs introduced in Windows Server 2008). The Application Pool configuration file is then secured with this unique SID. This ensures that Application Pool configuration files can only be read by Administrators and the Application Pool itself.

Diagnostics and Monitoring

Event Logging

Events regarding invalid configuration, recycling, startup or shutdown of worker processes are reported to the System Eventlog.

Currently Executing Requests

WAS exposes a run-time and state control interface that allows scripts and tools to query for the currently executing requests of a particular worker process. This is useful to find requests that hang or requests that take a very long time to complete.

Performance Counters

All IIS performance counters get funneled through WAS. WAS gathers these performance counters because IIS counters are site-based and web applications can live in different Application Pools.

Recycling

Recycling allows the refresh of worker processes without losing a single request due to down-time. This is done via a feature called "overlapping recycling".

Overlapping Recycling

WAS does this by spawning up a new worker process parallel to the old one that is still handling requests. Once the new worker process is up it starts picking up requests from the request queue while the old worker process is instructed by WAS to stop picking up requests. Once the old worker process finishes all executing requests it shuts down. This feature is called "overlapping recycling". It ensures that no requests are lost during a recycle.

Recycling Configuration

Recycling parameters are configurable in the IIS configuration system.

Scheduled Recycling

Customers might want to recycle their applications based on a regular schedule. Via configuration settings recycling can be scheduled periodically, e.g. every 4 hours, every day at 1am etc.

Recycling Based on Memory Consumption

Applications might leak memory over time. WAS can monitor the memory consumption of each worker processes to ensure that no worker process uses more than its preconfigured limit. Reaching a configured virtual or private memory threshold will trigger the recycling of a worker process.

Recycling Based on Number of Requests

Recycling can also be configured based on the number of requests a particular worker process handled.

Custom Recycling

Custom code can custom health statistics and trigger a recycling via an API call to the WAS run-time and state API's.

Process Orphaning

Some errors only happen in a production environment. Killing worker processes ensures up-time but troubleshooting of these errors becomes difficult, e.g. if the failing worker process needs to be debugged. The process orphaning feature in WAS allows worker processes to be recycled without killing the failed worker process. Now a debugger can be attached to it. Additional process orphaning settings allow the execution of a process (e.g. a debugger) if orphaning happens.

Application Pool State Management

Application Pools can be stopped, recycled or started via publicly available API's, e.g. if an application has to be taken offline or if recycling has to be done based on parameters different from what's configurable in the applicationhost.config file.

Additional WAS Features

Load-Balancer Features

HTTP.SYS still listens on the network and will return a 500 HTTP error message if requests are not picked up by an Application Pool. This is a problem because for a Level 5 Load Balancers (TCP/IP) a 500 HTTP error looks like a valid TCP/IP connection. A WAS configuration setting can enable HTTP.SYS to reject connections instead of sending HTTP responses.

WAS can be configured to start worker processes with the following settings:

WoW64 Support

WAS can start 32-Bit or 64-Bit worker processes.

.NET Framework Preload

WAS can be configured to preload a particular version of the .NET Framework. This can make the troubleshooting of version conflicts much easier.

Web Gardens

A Web Garden is the term for an Application Pool that runs with multiple worker processes. Requests get distributed among these worker process instances using a round-robin mechanism.

WAS Multi Protocol Support

WAS not only host the HTTP stack. It can also host other protocols via its Listen Adapter and Worker Process Framework. WCF services take advantage of the WAS Multi-Protocol support. WCF protocols come with their own Listeners (e.g. the NET.TCP, NET.MSMQ or NET.PIPE Listener). These Listeners connect to WAS using the Listener Adapter Interfaces WAS provides.

Application protocols that take advantage of this infrastructure can host custom application code in the same .NET Application Domain as regular ASP.NET applications. They can also take advantage of the protocol-independent services the ASP.NET Hosting Environment provides, for example on-demand compilation, configuration support etc.

4. Summary

IIS7 and WAS offer a powerful process model for web-sites, web applications and web-services. It not only ensures availability but also ensures isolation and offers great troubleshooting and monitoring support.

IIS7 PowerShell Provider Podcast

thomad — Tue, 29 Apr 2008 22:43:53 GMT

Saw a post on forums.iis.net last week about a Podcast on our new IIS7 PowerShell Provider. Being the Program Manager for this thing I thought maybe these guys want me to participate in the Podcast. And sure enough - Jonathan and Hal were interested. And here it is the podcast link and the interview topics:

http://powerscripting.wordpress.com/2008/04/26/powerscripting-podcast-episode-23-iis7-special/

Interview Topics

Who are you
What’s your background at MS and elsewhere
Talk about the IIS7 management cmdlets
- Get/Set-WebConfiguration
- Start-WebItem
- Remove-WebConfigurationProperty
- Ability to use XPath filters
Talk about the IIS7 PSprovider
- Provider timeline - 2nd beta in June, final in October
- Features
  - ability to configure IIS and ASP.net, sites, vdirs, apps, all that
  - ability to delegate
  - root of namespace: sites, app pools
What does the future hold (that you can discuss)
- We talk about Server Core

IIS 7.0 PowerShell Provider Tech Preview 1

thomad — Mon, 14 Apr 2008 20:10:00 GMT

Finally, IIS 7.0 has a PowerShell Provider!

The IIS7 PowerShell Provider allows you to

Create Web-Sites, Web Applications, Virtual Directories and Application Pools
Change Simple Configuration Properties on Web-Sites, Application Pools, Web Applications and Virtual Directories
Add and Change Complex Configuration Settings
Query Run-time Data (Web-Site State, Application Pool State, Currently Executing Requests)
Execute Advanced Configuration Tasks, Scripting, Integration with other PowerShell Snap-Ins and features
Search and Discover Configuration Settings

Here is a screen shot of how to create a new IIS app:

DOWNLOAD:
Tech Preview 1 of the IIS 7.0 PowerShell Provider can be found here:
x86: http://www.iis.net/downloads/1664/ItemPermaLink.ashx
x64: http://www.iis.net/downloads/1665/ItemPermaLink.ashx

FORUMS:
Go to our PowerShell forum if you need support or if you are looking for 'Tips and Tricks'
http://forums.iis.net/1151.aspx

WALKTHROUGHS:
We have 9 walkthroughs for you to get familiar with the IIS 7.0 PowerShell Provider:
http://learn.iis.net/page.aspx/447/managing-iis-with-the-iis-70-powershell-provider/

Have fun!

How to speed up your most popular web page

thomad — Wed, 17 Jan 2007 21:05:00 GMT

What's your most popular web page?

I assume it is the default document of your web site, for example if a client requests www.mysite.com IIS would execute www.mysite.com/default.htm. Your default document list is easy to query:

C:\>%systemdrive%\inetpub\adminscripts\adsutil get w3svc\defaultdoc
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

defaultdoc : (STRING) "Default.asp,index.htm,index.html,iisstart.htm,default.aspx,Default.htm"

What happens for a request to www.mysite.com is actually pretty simple:

IIS will read the default document list and check file for file if the document exists in the physical directory of your site or vdir. IIS executes the document as soon as it finds the first match. You can imagine that this is pretty expensive. In the above case, supposing default.htm is the only default document that exists in your sites root directory, IIS would check five times until it finds default.htm. And this happens for every request!

The fixes for this problem are obvious:
1) trim down your default document list
2) put default documents that exist at the beginning of the list

Fix 2 has another huge benefit. IIS can put the first default document into the HTTP.SYS kernel-mode cache. It can stay there until IIS invalidates the cache, for example if the default document configuration changes. Kernel-mode caching is now possible because if an existing document is at the top of the list the existence of other default documents doesn't have to be checked anymore.

Stay tuned for my DefaultDocOptimizer script. I'm writing it tonight :)

Quo Vadis AccessFlags?

thomad — Sun, 05 Nov 2006 22:46:00 GMT

Introduction

When IIS is configured as an Application Server it executes scripts like ASP and ASP.NET, CGI programs and other dynamic content. But in other scenarios IIS is supposed to only allow the download of html files and other static content like html pages, music or video files. With the accessFlags setting in IIS 6.0 administrators were able to lock down the IIS execution permissions to prevent dynamic content from executing.

accessFlags in IIS 6.0

The configuration property that allows or prevents execution of dynamic content is called accessFlags in IIS 6.0. Here a link to the IIS 6.0 metabase reference documentation: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/e9b6d626-9583-4d59-b7f7-a079ec47461c.mspx?mfr=true

Here is a brief overview of the three most important settings. These are also the only one’s show in the User Interface shown above.

“Read”

Setting a site, virtual directory or web application to “Read” has the effect that no dynamic content gets executed. If you have any kind of script content, for example ASP pages, ASP.NET pages, PHP or Perl scripts in this location they will generate a 403 Forbidden error.

“Script Execution”

If you set your site, virtual directory or web application to “Script Execution” only URLs that are mapped to script engines get executed. The most popular script engines on IIS are ASP, ASP.NET, Cold Fusion, PHP or Perl. To find out what script engines you have installed you have to look into the scriptmaps. The scriptmaps is another configuration property in IIS 6.0. It is there to register the script engine but also contains a mapping between a file extension and a DLL or executable.

“Script and Executable Content”

If you want to allow the execution of an ISAPI extension or CGI program you have to enable “Script and Executable content”. If you don't do this you get a HTTP Error 403.1 - Forbidden error.

Note: all executable programs also have to be registered in the Web Service Extension Restriction List before they can be executed otherwise you will see a 404.2 error in you log files!

Changes in IIS7

There are several changes that got introduced in IIS 7. Scriptmaps are not called scriptmaps anymore. The configuration section is called “handlers” now. And accessflags is not called accessflags anymore. It’s name is now accessPolicy and it lives in the handlers configuration section. Let’s have a look at the handlers section in %windir%\system32\inetsrv\config\applicationhost.config:

</handlers>

There are two interesting settings in this section from an execution policy point of view.

1) accessPolicy and

2) requiredAccess

As you can see the accessPolicy setting is set for the whole handlers collection. In our case it is set to “Read” and “Script”. This means that only handlers that require “Read” or “Script” access will execute. Every handler that requires “Execute” access will not run with this setting. A ??? error will be generated. For example: Only if you extend the accessPolicy to “Read”, “Script” and “Execute” you will be able to execute an unmapped ISAPI extension (ISAPI-dll). The requireAccess property in for ISAPI extensions requires “Execute” access, see below:

The accessPolicy entry to enable unmapped ISAPI extensions would look like this:

If you don’t want to allow any dynamic content you would set the accessPolicy to

Only the following handlers would remain in the list.

</handlers>

Note: Every handler without the requiredAccess property set will use the default. The default for requiredAccess is “Script”.

Controlling accessPolicy via the User Interface

Access policy can still be controlled on a granular level . To change the access policy: navigate to your site, virtual directory or web application and click the “Handler Mappings” icon.

You will see an entry called “Edit Handler Permissions…” in the Actions menueon the right hand side.

<I will add pictures how the UI looks soon - promise!>

If you click this entry you will get a dialog that allows you to control the access policy for the location you selected.

Summary

IIS7 introduced several changes to the way IIS7 controls execution permissions to web content. The new handlers configuration section now contains all settings necessary to set the policy for web content. These permissions can be controlled on a granular level and let Administrators determine what can be executed on their servers and what’s forbidden.

Achtung! IIS7 Preconditions

thomad — Sat, 04 Nov 2006 19:25:00 GMT

If you ever looked into the IIS configuration file applicationhost.config you might have encountered a setting called “precondition”. Here is the handler entry for aspnet_isapi.dll for example:

The Need for Preconditions

IIS is an application platform that supports extensibility in multiple different ways: ISAPI filters, ISAPI extensions and new with IIS7: managed modules and handlers and native module and handlers.

All these extensibility modules are all packaged into DLLs and these DLLs are then loaded into IIS worker processes.

The Bitness precondition

64-Bit processors become more and more prevalent. Soon OEMs will stop shipping 32-Bit processors. Switching over to a 64-Bit Operation System, for example Longhorn Server 64-Bit, is hard though, because a lot of software is still written for Windows 32-Bit operating systems. Longhorn Server provides a 32-Bit execution environment on top of the 64-bit Operating System called WoW64. IIS takes advantage of this and you can run 32-Bit worker processes side by side with 64-Bit worker processes. IIS7 introduces the bitness32 and bitness64 precondition to make sure you load DLLs with the right bitness in your worker processes. Without this precondition you would have to have 32-Bit and 64-Bit handler and module maps.

The RuntimeVersion preconditon

This precondition was introduced for the different versions of the .NET Framework. Currently only one version of the .NET Framework can be loaded in a process. Trying to load another version of the .NET Framework into the same process results into ugly errors. With the RuntimeVersion precondition components that need a particular version of the .NET Framework can be marked to be loaded only in worker processes that loaded this version of the .NET Framework already. Setting the version of the .NET Framework is now an Application Pool property and IIS worker processes use this property to preload the right version of the .NET Framework on startup.

The ManagedHandler precondition

IIS 7.0 introduces a new managed extensibility model. Handlers and Modules can now be written in managed code and directly integrated into the IIS request pipeline. But switching between managed and native code is an expensive operation. The managedHandler precondition was introduced to allow optimizing the performance of requests where no managed code needs to be involved, for example when static files (.html, .jpg etc.) are served. No managed code is called if the request is served by a native handler and every managed module is configured with the managedHandler precondition. A practical scenario is Forms authentication. The managed Forms authentication module has a managedHandler precondition and is therefore only called when ASP.NET content (e.g. *.aspx) pages are requested. If a .html page is requested the forms authentication is not called. If you want to protect all your content with forms authentication you can simply remove the managedHandler precondition from the Forms authentication module entry.

The Mode Precondition

The new managed module and managed handler extensibility allows you to add managed code, i.e. ASP.NET pages, modules and handlers, directly into the IIS7 pipeline. IIS7 needs to run the worker process in a particular way for this to work. It needs to load the .NET Framework 2.0 and it also needs to run a module called webengine.dll. Webengine.dll does all the work of hooking up managed modules with the IIS7 pipeline because IIS7 itself doesn’t know about managed code. The new way to integrate ASP.NET pages, modules and handlers is called “Integrated Mode”.

But there is still the good old way to hook up managed code in IIS7, i.e. via the ISAPI interface. ASPNET_ISAPI.DLL used to do this in IIS 5, 5.1 and 6.0. IIS7 continues to support the ISAPI hookup if you run the worker process in “classic Mode”.

As a result IIS7 introduced two preconditions called “integratedMode” and “classicMode”. A handler that has an “integratedMode” precondition associated with it will only be loaded into an Application Pool that has the “integratedMode” property set on the ApplicationPool. Handlers with the “classicMode” precondition will only be loaded into Application Pools that have the integratedMode property set to false.

Configuration Sections that Use Preconditions

There are four IIS7 configuration sections that use preconditions:

· ISAPI filters

· globalModules

· handlers

· modules

ISAPIFilters

ISAPI filter preconditions are the easiest to explain.

When the ISAPI filter module intiailizes it reads the <isapiFilters> configuration section and goes through the list of ISAPI filters. Every filter in the list gets loaded into memory and its initialization function is called. Now what if the filter is a 32-Bit binary but you are running on a 64-Bit Longhorn system? Initialization would fail and the IIS worker process wouldn’t come up. That’s not an unlikely scenario because running 32-Bit and 64-Bit worker processes on IIS7 is a supported scenario. Just think about your legacy web application that isn’t available on 64-Bit yet? Don’t you want to run it in a 32-Bit AppPool side-by-side with your new 64-Bit apps and take advantage of the humongous 64-Bit address space?

Preconditions come handy in this case. If you have a 64-Bit ISAPI filter you can mark your ISAPI filter with the bitness64 precondition. This makes sure that it only gets loaded in 64-Bit worker processes because when the ISAPI filter module initializes it ignores ISAPI filters if the bitness precondition differs from the bitness of the process. Here an example:

</isapiFilters>

MyIsapiFilter is never loaded into a 32-Bit worker process.

globalModules

Another configuration section that works with preconditions is globalModules. The globalModules section determines which IIS modules get loaded into worker processes. With preconditions you can make sure that worker process only load modules that work in a particular Application Pool. This was especially done to make the ASP.NET side-by-side story more manageable. You might remember that the module webengine.dll is responsible to hook up the managed request pipeline with the native IIS7 pipeline. When an AppPool is configured to run this way the AppPool runs in so-called “Integrated Mode”. “Integrated Mode” is only possible with the .NET Framework 2.0 binaries. This already explains the preconditions you see on webengine.dll in the globalModules section:

Webengine.dll precondtions

The “integratedMode” precondition ensures that webengine.dll gets only loaded in Application Pools that are configured to run “Integrated Mode”, i.e. the Application Pool property managedPipelineMode is set to “Integrated”.

runtimeVersionv2.0 is a precondition that ensures that webengine.dll is only loaded by the IIS core if the Application Pool has the .NET Framework 2.0 version preloaded. Without ensuring this IIS or an application within IIS might have loaded a different .NET Framework version (at the time of this writing the only other supported .NET Framework version is 1.1). Loading webengine.dll would fail if a different .NET Framework version would already be loaded in the process. Only one version of the .NET Framework can be loaded into a particular process space however.

The final precondition is bitness32. I already talked about this quickly in the isapiFilter paragraph. You might ask why there are no bitness preconditions on the other modules. The nice thing with system DLL’s living underneath the \windows directory is that they get automatically redirected based on their bitness. If running a 64-Bit worker process IIS will load global modules from the 64-Bit Windows directory whereas when running a 32-Bit worker process the modules get loaded from the 32-Bit Windows directory.

handlers

The handlers section in applicationhost.config determines how particular requests get routed. Usually this is based on the file extension. Requests that end in .asp for example get routed to the ISAPI Extension module which in turn routes it on to ASP.DLL. Here is the beginning of a handler section in applicationhost.config. I didn’t include the whole section because it is pretty big.

…

</handlers>

The preconditions on the handlers section are usually the same as on globalModules and side-by-side of ASP.NET applications is also the major reason to have preconditions. If you worked with ASP.NET 1.1 and 2.0 on IIS6 you might have noticed that ASP.NET 2.0 has to be configured on a per application basis. Before you can run a particular ASP.NET application you have make sure the application is configured for the ASP.NET version you want to use. ASP.NET is coming with a property page that can be plugged into IIS6 to do this:

<ASP.NET UI in IIS 6.0>

What this property page does is to copy the full handlers list to applications metabase. This becomes a problem over time because a) the metabase becomes pretty big and b) handlers that get installed globally are not inherited anymore. It also doesn’t prevent you from having two applications with differing versions of ASP.NET running in the same process. The result is pretty random. Whatever application loads its version of ASP.NET first will work. The other application will fail to load. The next time the worker process recycles the second application might work but not the first one anymore.

With preconditions these problems are gone because the version of the .NET Framework to load is an Application Pool property. Together with preconditions it enables IIS to have a single global handler list that doesn’t have to be replicated to every application that runs a different version of the .NET Framework. All that an Administrator has to do is to configure an Application Pool with the right .NET Framework version and put the applications in there. One could say that ASP.NET side-by-side is solved by Application Pools.

ASP.NET 1.1 Application Pool configuration

In the above example you see three .aspx mappings all in the same list. It depends on how the Application Pool is configured on which handler is loaded. Here is the setting for ASP.NET 1.1 applications:

To get these settings loaded in your Application Pool you have to

· set the managedPipelineMode property to “classicMode”

· set the managedRuntimeVersion property to “v1.1”

· run the worker process on a Vista/Longhorn 32-Bit Operating System or set the Application Pool property Enable32bitAppOnWin64 to true on 64-Bit Vista or Longhorn versions

ASP.NET 2.0 Application Pool configuration for classic Mode

The second .aspx mapping is needed for Application Pools that run in classic Mode:

Is only effective if

· the managedPipelineMode property on the Application Pool is set to “classicMode”

· the managedRuntimeVersion property on the Application Pool is set to “v2.0”

· the worker process is running on a Vista/Longhorn 32-Bit Operating System or if the Application Pool property Enable32bitAppOnWin64 is set to true on 64-Bit Vista or Longhorn

ASP.NET 2.0 Application Pool configuration for Integrated Mode

The third mapping will be loaded for Integrated Mode.

You see that ISAPI is not involved in this mapping. A managed type is used instead which tells us that Integrated Mode is enabled. To enable Integrated Mode the AppPool has to have the following settings

· the managedPipelineMode property on the Application Pool is set to “integratedMode”

· the managedRuntimeVersion property on the Application Pool is set to “v2.0” because otherwise webengine.dll wouldn’t load (see globalModules above).

Managed code is also bitness independent. The right version of webengine.dll has to be loaded though. On a 64-Bit operating system both versions are installed by IIS setup.

Modules

Modules are to IIS7 what ISAPI filters where to IIS6. Where handlers get executed only for a particular file extension, modules can register for and participate in particular events that get fired by the IIS core during each request, for example at BeginRequest, Authenticate, SendResponse or EndRequest.

The loading of modules is already done via the globalModules list which is global. But enabling a particular module can be done per application and that’s why IIS7 has the <modules> section. It is pretty much an enablement list for modules.

Here is a typical IIS7 modules section:

</modules>

The only precondition you see in the <modules> collection is called “managedHandler” and you can see that it is only applied to modules that have a managed type.

For performance reasons IIS7 doesn’t want to run managed code on every request because managed code still has some performance drawbacks. The managedHandler precondition is used to only enable a particular module if the request is going to a managed handler anyway. Every request that goes to a native handler will run through the IIS7 pipeline without managed code being executed. Here is an example: Forms Authentication is a managed module with the managedHandler precondition:

When a request to /default.aspx comes in IIS7 determines that a managed handler (System.Web.UI.PageHandlerFactory – see handler paragraph above) will execute the request. The managedHandler precondition becomes true and every module that has the managedHandler precondition can participate in the request. Browser clients would be challenged with the authentication page if Forms authentication is enabled for /foo.aspx.

If a request to /default.htm is made IIS7 will find out at the beginning of the request that it will be handled by the StaticFile handler which is a native handler. The managedHandler precondition is false and the modules which have this precondition wouldn’t be loaded for /default.htm.

But what if you want to protect /default.htm with forms authentication? Simple, just remove the managedHandler precondition and every request will have to go through the Forms Authentication module.

Note: FormsAuthentication needs some other modules to work, for example Roles, UrlAuthorization etc. It is recommended to remove all managedHandler preconditions if non-managed content is supposed to be protected with Forms Authentication.

Handler issues

There is one issue to be aware of with preconditions. What happens if a handler for a particular request is configured, for example .foo is mapped like this

But the worker process is a 64-Bit process?

In this case the precondition doesn’t match and IIS continues to search for another handler. The last handler on the list is usually the StaticFile handler:

It catches pretty much all requests that weren’t handled by a handler higher up. The static file handler doesn’t serve out the request as static file though. This would be a security problem, just imagine serving out ASP or ASP.NET files as static text. The static file handler is intelligent enough to not send out any file extensions that are on the handler list. A 404.3 error is generated in this case.

Summary

Preconditions are a powerful way to introduce conditional logic into IIS configuration sections. This enables IIS7 to provide a solid side-by-side platform for .NET Framework 1.1 and 2.0 applications but also for 32-Bit and 64-Bit applications.

IIS7 Logparser Gadget

thomad — Mon, 30 Oct 2006 19:41:00 GMT

Bill sent me e-mail on Saturday announcing that he wrote his first Windows Sidebar Gadget. It allows him to start PerfMon or other arbitrary programs from the Windows Sidebar.

I wanted to write a gadget for a long time and use it for one or the other IIS7 demo in the three talks I give on TechEd Barcelona. Bill's mail made me finally do it. So I spent the whole day Saturday to come up with my own gadget and right before dinner time the "IIS7 Logparser Gadget" was born (click the link to download it).

It runs a user-definable Logparser query, reads the first result and shows it on the gadget. Here is how it works:

1) gadget.xml is a global configuration file containing descriptions, etc. Not too interesting. The only important entry is the html file that gets invoked to show the gadget. In our case it is Logparser.html.

<?xml version="1.0" encoding="utf-8" ?>
<gadget>
<name>Logparser Gadget</name>
<namespace>Logparser.Gadget</namespace>
<version>1.0</version>
<author name="Thomas Deml">
    <info url="www.iis.net" />
</author>
<icons>
   <icon src="icon.png" />
</icons>
<copyright>2006</copyright>
<description>Logparser Gadget that runs custom query</description>
<hosts>
    <host name="sidebar">
      <base type="HTML" apiVersion="1.0.0" src="Logparser.html" />
      <permissions>full</permissions>
      <platform minPlatformVersion="0.3" />
    </host>
</hosts>
</gadget>

2) logparser.htm is the html file that contains the code that shows the gadget and runs the query. In logparser.html you find the meat of the gadget. The Javascript code defines the default logparser query (it looks a bit cryptic, but the query returns the sum of http requests that ran in the last hour) and sets up a timer to run the query every 30 seconds. If an error occurs I write it to the logparser_gadget_error.log file.

<html>
<head>
<title>Logparser Gadget</title>
<style>
    body {
    width:130;
    height:74;
    background: url('Image.png');
    padding-top: 0px;
    }
  </style>
</head>
<body onload="countdown()" >
<span id="gadgetContent" style='font-family: Calibri; font-size: 10pt; color: Black'>init</span>
<script>

    </script>

</body>
</html>

3) settings.htm is pretty straightfoward, too. It allows you to change the Logparser query, the query description and the query interval (defaults to run every 30 seconds right now). It gets called when you right click on the gadget and click "Options".

<html>
<head>
   <style>
    body{
      width:600;
      height:200;
    }
   </style>
   <script>

    System.Gadget.onSettingsClosing = SettingsClosing;
    function init() {
      query.value = System.Gadget.Settings.read("query");
      queryDescription.value = System.Gadget.Settings.read("queryDescription");
      queryInterval.value = System.Gadget.Settings.read("queryInterval");
    }

    function SettingsClosing(event)
    {
      if (event.closeAction == event.Action.commit) {
        System.Gadget.Settings.write("query", query.value);
      System.Gadget.Settings.write("queryDescription", queryDescription.value);
        System.Gadget.Settings.write("queryInterval", queryInterval.value);
      }
      event.cancel = false;
    }
   </script>
</head>
<body onload="init()">
   <div id="mySpan" style='font-family: Tahoma; font-size: 8pt; ' >
    Logparser Query:<br />
     <input style='font-family: Tahoma; font-size: 8pt; width: 250; ' type='text' id='query' ><br />
     Query Description:<br />
     <input style='font-family: Tahoma; font-size: 8pt; width: 250; ' type='text' id='queryDescription' length='600'><br />
     Refresh Interval (msec):<br />
     <input style='font-family: Tahoma; font-size: 8pt; ' type='text' id='queryInterval' length='10'>
</div>
</body>
</html>

4) image.png and icon.png are the backgrounds for the gadget referenced in gadget.xml and logparser.html.

How to install it?

Download and install Logparser 2.2. Create a gadget directory and copy the extracted files into it: md "%userprofile%\AppData\local\microsoft\Windows Sidebar\gadgets\logparser.gadget". Now right click on the Sidebar and select the Logparser Gadget:

Issues:

UAC bites again. If you run with User Account Protection on you don't have access to the IIS logfiles because they are ACLed to only allow Administrators. The only way around it right now is to ACL the logfiles to access for the identity Sidebar is running under. I usually do it like this:

ICACLS %systemdrive%\inetpub\logs\logfiles /grant %USERDOMAIN%\%USERNAME%:(CI)(OI)F /T

I hope this gives you an idea how to write your own gadgets. Have fun!