SP and the new native IIS plugin, configuration and upgrade.

[Rod Widdowson]

Mostly for Scott..

I've started looking at the whole issue of moving installation from the old IIS6 ("isapi") plugin to the new IIS7 one I've been
developing ("native"), and particular thinking about the installation process or lack thereof.

The issue which is troubling me right now is our old favorite of the actual IIS configuration.  We might be able to do something
about adding in the native plugin with the appcmd executable but I don't see any easy way to turn off the isapi plugin.  It can be
configured in too many ways in too many places (globally, per site, per virtual folder and indeed in every directory).  Add to that
that it is configured twice (filter and handler).

Unless pressed I'm not going to even think about a scripted solution, not even using the IIS plugin points; that way madness lies as
we well know.  So I think our only hope will be to tell people to manually "deconfigure" the old plugin, giving them a list of
places to look (not just the GUI, also all the various files scattered across the system).

What I'd like to do in addition is to sense that it is still configured, it is going to horribly complicate the debug of a system
with two sets of listeners.

I'm looking for ideas on how to do this.   I suppose that we could add something in shibboleth.xml to say "use 'isapi' or 'isapi'"
and we could teach the two plugins to look at that, but my current best solution is to use the registry and get both plugins to
write to a common value:

     If they find nothing there they could write their signature and carry on.  

     If they find their signature then it is left over from last time.  All is OK, carry on.

     However, if they find the wrong signature they would delete the value (thus resetting the trigger) and exit noisily.

For extra points we could put the value into a volatile key so a reboot would also clear it.   Depending on the precise
configuration this would mean that the native plugin (which is started when IIS starts) would always trump the isapi one (which
appears to be only fired up when the first request happens).  Maybe, but it doesn’t really matter, all that matters is that only one
starts and that the other notices and dies.

Any comments on the need for such a test, whether what I propose makes sense or better suggestions?

/Rod