IIS7 Support for ISAPI Filters
-kinetic
(Server 2008) with Exchange 2007 server. It's currently not working, and
logging doesn't even show it being initialized/loaded.
I have searched far and wide for any documentation about the support, or
more importantly what is needed for the IsapiFilterModule in IIS7 to have
backward compatibility with ISAPI Filters.
Where can I find more information?
Thanks
-kinetic
David Wang
ISAPI Filter as to whether it is supported on IIS7.
If the provider is yourself, then you have some work to do.
IIS7 has ISAPI Filter support but it is not installed by default.
What "logging" are you talking about. IIS7 definitely logs to the
Event Log when it fails to load an ISAPI Filter just like IIS6, and
you can also install and turn on the "Failed Request Tracing" feature
of IIS7 to see the exact details. Those two observations, event log
and failed request tracing, is enough for me to resolve most filter
issues.
Now, I am not aware of any Microsoft documentation on how to get ISAPI
Filter to work on IIS7. I suspect it would never materialize and if it
exists, it would lack details and insight -- because I am probably the
only person who can do that, and I am not working on IIS anymore...
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Jan 18, 5:33 pm, -kinetic <kine...@discussions.microsoft.com>
wrote:
> > Thanks- Hide quoted text -
>
> - Show quoted text -
-kinetic
Thanks for the prompt response! I'm glad I can finally get some
information, I've been struggling for some kind of information concerning
these issues by just doing web searches and newsgroup searches.
The filter is basically written by my team, and it has been working on IIS
6, but now that server 2008 and IIS 7 will be coming out, we need to make
sure we can support that combination as well.
I know that filters have been replaced by modules, but it would be
preferable to have our filter work on both IIS 6 and on 7 if possible.
I've tried looking in the event log as you've suggested, but I get no errors.
I've also used the failed request tracing, but that's also not giving me
anything about the filter being loaded.
I've also tried to put a very easy sample filter I found together that I
have gotten to work on 32bit IIS6 + 2003 server as well as 64-bit IIS6 with
2003 server, but no luck with the IIS 7 and 64bit Server 2008.
Currently, I add the filter to the Isapi Filters, and then I run iisreset
/noforce computername to restart IIS. I get no errors in the event viewer.
I think try to hit a webpage which the filter should catch, but again,
nothing.
You did mention something about IIS7 not working by default with filters.
Perhaps this is my problem? How do I check if it's actually installed /
configured to run filters?
Any other ideas of what might be going on?
Thanks
-kinetic
Thanks for the reply! I am currently the provider of the filter. My team
has it working for IIS6 on 32-bit and 64-bit Windows operating systems, but
we are looking forward to supporting IIS7 and Server 2008. We are aware of
the possibility of it being compatible with filters still, even though it is
moving forward with the modules.
I have added the filter to the ISAPIFilters in IIS7, but it is considerably
a different looking UI such that I'm not sure if it's loading or not.
I used sysinternals' tool, Process Explorer, to check the w3wp.exe process
for the dll, but it's not showing up as a loaded dll.
Event Viewer gives no errors, and I tried the Failed Request Tracing but
it's also not showing me information about the loading of the dll. How
exactly should I setup the failed request tracing to help show me if the DLL
is being loaded?
I'm currently trying a simple 404 error logger, which basically filters the
404 errors and logs them somewhere else. So in the Failed Request Tracing,
I've added 404. I get a warning when I try the request, but nothing about
the loading.
I do see ISAPIFilterModule in the modules list, so I figure it's installed
and configured, but perhaps I'm missing something? What else is needed to
enable isapi filters on IIS7?
Thanks!
David Wang
unlock the UI to allow you to configure filters.
I suspect this is your problem -- you have a 32bit ISAPI Filter that
you are trying to run on 64bit IIS7. The isapiFilter definition will
need the bitness32 preCondition as well as an application pool with
Enable32bitAppOnWin64=true
On 64bit Windows/IIS it used to be very easy to get 503 service
unavailable if you mismatch the process and DLL bitness. That mistake
can be mitigated with IIS7 and preConditions.
On Jan 22, 5:57 pm, -kinetic <kine...@discussions.microsoft.com>
wrote:
> >http://blogs.msdn.com/david.wang/archive/2005/06/21/HOWTO_Diagnose_an...
>
> > Now, I am not aware of any Microsoft documentation on how to get ISAPI
> > Filter to work on IIS7. I suspect it would never materialize and if it
> > exists, it would lack details and insight -- because I am probably the
> > only person who can do that, and I am not working on IIS anymore...
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Jan 18, 5:33 pm, -kinetic <kine...@discussions.microsoft.com>
> > wrote:
> > > I mean Longhorn with IIS7 not exchange 2007!
>
> > > "-kinetic" wrote:
> > > > I have an ISAPI Filter from IIS6 and would like it to work with Longhorn
> > > > (Server 2008) with Exchange 2007 server. It's currently not working, and
> > > > logging doesn't even show it being initialized/loaded.
>
> > > > I have searched far and wide for any documentation about the support, or
> > > > more importantly what is needed for the IsapiFilterModule in IIS7 to have
> > > > backward compatibility with ISAPI Filters.
>
> > > > Where can I find more information?
>
> > > > Thanks- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
-kinetic
I figured out the problem. I was loading the filter at the global level,
but I also had Exchange 2007 server installed. I believe something happened
at the "Default Web Site" level that removed inheritance of the filters, thus
not applying my global filter.
Since we wrote the filter for IIS6, we never encountered inheritance
problems and just installed the filter at the "global level".
Is there a metabase sort of emulator for IIS7 where we can check inheritance
properties and such during our installation process? It seems like there's a
new level of complexity with inheritance, and without being able to predict
the situation on IIS7 in terms of inheritance, we'll need a solution for that.
Do you have any suggestions on how this inheritance can be figured out, and
if we can easily access each "site" level to install the filter if the
configuration is not inheriting?
Thanks so much for your help!
David Wang
There is already a metabase emulator in IIS7 that accepts your ABO
configuration and maps it to IIS7's native configuration -- IIS6
Metabase Compatibility Feature.
Filters do not inherit the way you say. And you should not be trying
to second guess the inheritance within your setup code.
There are exactly two lists for filters -- one in the
applicationhost.config that is representative of "global" filters that
inherits everywhere by default, as it did in prior versions of IIS6,
and another one via location tags to represent the "site" filters
which do not override the global list. The IIS6 Metabase Compatibility
Feature will remap your existing ABO calls to put the filter in the
right list. It is critical that you do not add <clear /> elements in
the isapiFilter list for the site since that is allowed in the new
config sysstem but behaves in an incompatible way to prior IIS
versions -- perhaps the UI or Metabase Compatibility does this, and if
so, that's a bug in IIS7.
As I said, if you think it's a bug in this inheritance, then the best
solution is to use the new configuration API to put the filter where
you want (and to call in a bug with Microsoft PSS). It is wasted
effort to try to "check inheritance properties and such" because that
IIS7-specific code is only applicable in a legacy sort of way while
using the new configuration API of IIS7 is forward-looking and will
work no matter the configuration item.
On Jan 23, 10:26 am, -kinetic <kine...@discussions.microsoft.com>
wrote:
> Hi David,
>
> I figured out the problem. I was loading the filter at the global level,
> but I also had Exchange 2007 server installed. I believe something happened
> at the "Default Web Site" level that removed inheritance of the filters, thus
> not applying my global filter.
>
> Since we wrote the filter for IIS6, we never encountered inheritance
> problems and just installed the filter at the "global level".
>
> Is there a metabase sort of emulator for IIS7 where we can check inheritance
> properties and such during our installation process? It seems like there's a
> new level of complexity with inheritance, and without being able to predict
> the situation on IIS7 in terms of inheritance, we'll need a solution for that.
>
> Do you have any suggestions on how this inheritance can be figured out, and
> if we can easily access each "site" level to install the filter if the
> configuration is not inheriting?
>
> Thanks so much for your help!
>
>
>
> "David Wang" wrote:
> > All you need to do is add the ISAPI Filter Feature in IIS7. This will
> > unlock the UI to allow you to configure filters.
>
> > I suspect this is your problem -- you have a 32bit ISAPI Filter that
> > you are trying to run on 64bit IIS7. The isapiFilter definition will
> > need the bitness32 preCondition as well as an application pool with
> > Enable32bitAppOnWin64=true
>
> >http://blogs.msdn.com/david.wang/archive/2006/03/18/IIS7-PreCondition...
-kinetic
So what you're saying is, by installing a filter in the global level, it
should be inherited regardless of what filters are listed in the "site" level?
I tried this just now:
1. I put the filter in the global level, and then went to the site level
and hit "Revert to Inherited". Sure enough the filter now shows up at the
site level.
2. I restart the IIS service with /iisreset /noforce computername
3. I tested the filter by making a request with my web browser, works fine.
4. Removed the filter explicitly from the site level, making sure the
global level still has the filter and restart the IIS service.
5. I make the same request with the browser, and the filter is no longer
loading and doesn't work.
You're saying that it should still work at this point? If that's the case
then I'll go report the bug.
In the meantime, is there any security risks that I'm overlooking by working
around this problem by installing the filter at the site level for every
site, assuming we're not worried about new sites being added after the
filters have been installed?
Thanks!
"David Wang" wrote:
> > > > >http://blogs.msdn.com/david.wang/archive/2005/06/21/HOWTO_Diagnose_an....
David Wang
steps, what you observe is by-design.
When you removed the filter from the site level, you introduced a
<clear /> into the site filter list, so IIS behaves exactly as
configured.
The ability to "delete" global filters from the site filter list is
something introduced with IIS7 due to how its configuration worked. I
had tried to change this behavior with the UI designer because I knew
it was not consistent with previous IIS versions, but the best
compromise was adding the "Revert to Inherited" button.
I think the easier thing is to set the isapiFilter at the global level
in applicationHost.config and then "lock" that item to prevent it from
being removed in the child site definition. This would directly give
you the behavior you want -- global filter that cannot be overridden
in the child nodes and thus always run. This would be far easier and
more correct than what you are trying to do, which would fail for
newly added websites.
On Jan 24, 11:23 am, -kinetic <kine...@discussions.microsoft.com>
-kinetic
Thanks for the reply again. I understand what you mean by <clear>, but I
guess I may need to try to reproduce my intial problem.
My initial problem was installing IIS7 on 2008 Server, then Exchange 2007
Server. I'm writing a filter for using my own authentication, so we
installed the filter in the global level. It apparently wasn't propagating
down to the site level. We never had it "cleared" but perhaps the Exchange
2007 Server had it "locked"? When I hit "Revert to Inherited" it did show
the filter from the global level and everything started to work.
So along with <clear> is there also a lock that could be applied at the site
level that prevented anything from being inherited, perhaps by exchange?
Also, how is the global filter able to be locked? Is this a configuration
option? Using the IIS Manager I wasn't able to find any IDE options for it.
Thanks!
"David Wang" wrote:
> > > > >http://blogs.msdn.com/david.wang/archive/2006/03/18/IIS7-PreCondition....
> >
> > > > > On 64bit Windows/IIS it used to be very easy to get 503 service
> > > > > unavailable if you mismatch the process and DLL bitness. That mistake
> > > > > can be mitigated with IIS7 and preConditions.
> >
> > > > > //David
> > > > >http://w3-4u.blogspot.com
> > > > >http://blogs.msdn.com/David.Wang
> > > > > //
> >
> > > > > On Jan 22, 5:57 pm, -kinetic <kine...@discussions.microsoft.com>
> > > > > wrote:
> > > > > > Hi David,
> >
> > > > > > Thanks for the reply! I am currently the provider of the filter.. My team
> > > > > > has it working for IIS6 on 32-bit and 64-bit Windows operating systems, but
> > > > > > we are looking forward to supporting IIS7 and Server 2008. We are aware of
> > > > > > the possibility of it being compatible with filters still, even though it is
> > > > > > moving forward with the modules.
> >
> > > > > > I have added the filter to the ISAPIFilters in IIS7, but it is considerably
> > > > > > a different looking UI such that I'm not sure if it's loading or not.
> >
> > > > > > I used sysinternals' tool, Process Explorer, to check the w3wp.exe process
> > > > > > for the dll, but it's not showing up as a loaded dll.
> >
> > > > > > Event Viewer gives no errors, and I tried the Failed Request Tracing but
> > > > > > it's also not showing me information about the loading of the dll. How
> > > > > > exactly should I setup the failed request tracing to help show me if the DLL
> > > > > > is being loaded?
> >
> > > > > > I'm currently trying a simple 404 error logger, which basically filters the
> > > > > > 404 errors and logs them somewhere else. So in the Failed Request Tracing,
> > > > > > I've added 404. I get a warning when I try the request, but nothing about
> > > > > > the loading.
> >
> > > > > > I do see ISAPIFilterModule in the modules list, so I figure it's installed
> > > > > > and configured, but perhaps I'm missing something? What else is needed to
> > > > > > enable isapi filters on IIS7?
> >
> > > > > > Thanks!
> >
> > > > > > "David Wang" wrote:
> > > > > > > I think you should look for more information from the provider of the
> > > > > > > ISAPI Filter as to whether it is supported on IIS7.
> >
> > > > > > > If the provider is yourself, then you have some work to do.
> >
> > > > > > > IIS7 has ISAPI Filter support but it is not installed by default..
> >
> > > > > > > What "logging" are you talking about. IIS7 definitely logs to the
> > > > > > > Event Log when it fails to load an ISAPI Filter just like IIS6, and
> > > > > > > you can also install and turn on the "Failed Request Tracing" feature
> > > > > > > of IIS7 to see the exact details. Those two observations, event log
> > > > > > > and failed request tracing, is enough for me to resolve most filter
> > > > > > > issues.
> >
> > > > > > >http://blogs.msdn.com/david.wang/archive/2005/06/21/HOWTO_Diagnose_an....
> >
> > > > > > > Now, I am not aware of any Microsoft documentation on how to get ISAPI
> > > > > > > Filter to work on IIS7. I suspect it would never materialize and if it
> > > > > > > exists, it would lack details and insight -- because I am probably the
> > > > > > > only person who can do that, and I am not working on IIS anymore....
David Wang
can look at the <modules> collection to see how items are locked.
You can view the IIS7 Manager UI as an application implementing IIS-
related workflows on top of this configuration system, abstracting it
away.Thus, it focuses on the workflows of IIS, and not the details of
how to do that in the IIS7 configuration system. Thus, concepts like
locking are a means to achieve a behavior and not worth exposing in
the UI. There is no glorified UI editor for the .config configuration
system.
Of course, I have already made clear that there are many prior IIS6
behaviors that are emulated in IIS7 config, but you can easily do more
things in IIS7 (like insert <clear />) to get behavior that was never
possible in IIS6. That is just the price one pays for legacy support
in the new, delegated way of doing things in IIS7.
Here is how to think about things.
- IIS7 configuration system has a natural inheritance hierarchy which
flows from machine.config to applicationHost.config to web.config
[nesting]
- Collections are just a grouping of multiple elements
- Thus, if you define something in a collection defined high up in the
hierarchy (like applicationHost.config), it is naturally inherited by
child web.config or event location-tags (location tags are a
complication to things - ignore it for now). This is great for the
Configuration-Reading scenario. But what about the Configuration-
Writing scenario?
- Enter "overrideMode", which controls whether that section can be
"changed" at the child level
- overrideMode is great for things like defaultDocument because it
means that you can define a default "DefaultDocument" list in
applicationHost.config that applies everywhere by default, and if you
allow overrideMode, it allows children websites/applications to also
alter this inherited value. This is delegation at the core.
- Everything looks good until you look at handlers and modules
collections. It is a design goal to allow people to add their own
handlers/modules for their websites so that they get custom behavior,
so overrideMode should be allowed in those scenarios so that the child
web.config can edit the collection. However, since those collection
literally define how IIS processes requests and hence its behavior, we
want to always ENSURE that certain modules/handlers are always present
in the collection.
- Enter "Locking" for the item, which controls whether that element
can be removed or not at the child level
- Thus, with both overrideMode=allow and LockItem for specific
collection elements, an administrator can delegate configuration for
child web.config to edit as well as constrain which collection
elements must always be present.
- Of course, this flexibility can be further tweaked with <location>
tags, but that's a separate complication that I'm not going to get
into at this point.
So, to clarify your questions:
- There is not such thing as "lock to prevent inheritance"
- Inheritance direction and scope is defined within the section
definition of applicationHost.config and usually proceeds logically,
from parent to child
- Inheritance automatically happens. Child can ignore inheritance with
<clear />. Parent can force certain items to not be cleared with
lockItem
Thus, if you want the behavior that global ISAPI Filters are always
present and cannot be cleared/ignored by the child, then you should
lockItem it at its definition in applicationHost.config
On Jan 24, 5:31 pm, -kinetic <kine...@discussions.microsoft.com>
> ...
>
> read more »- Hide quoted text -
-kinetic
I understand what you are saying, thanks for the help on that.
But I think the lockitem may not be the solution I need. I think I may have
tried to reproduce the actual problem incorrectly.
Here is the current scenario that I am faced with:
- Install 2008 Server w/ IIS 7 and exchange server 2007
- Install my filter in the global level
After the initial install of exchange server 2007, it seems like it has
"un-inherited" the global ASP.NET filters already. I checked in the
applicationHost.config file and there are no clears / removes explicitly.
Soon after I install my own filter which shows in the global, but not in the
Default Web Site level. And naturally it does not work there.
Here's a few snippits of interest from the applicationHost.config file that
might help:
----------------------------------------------------------
<system.webServer>
...
<isapiFilters>
<clear />
<filter name="ASP.Net_2.0.50727.0"
path="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_filter.dll"
enabled="true" enableCache="true" preCondition="bitness32" />
<filter name="ASP.Net_2.0.50727-64"
path="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_filter.dll"
enabled="true" enableCache="true" preCondition="bitness64" />
<filter name="MyOWAFilter.dll" path="C:\temp\MyOWAFilter.dll"
enabled="true" />
</isapiFilters>
...
</system.webServer>
...
<location path="Default Web Site">
<system.webServer>
<isapiFilters>
<clear />
<filter name="Exchange OWA Cookie Authentication ISAPI
Filter" path="C:\Program Files\Microsoft\Exchange
Server\ClientAccess\owa\auth\owaauth.dll" enabled="true" />
<filter name="Exchange ActiveSync ISAPI Filter"
path="C:\Program Files\Microsoft\Exchange
Server\ClientAccess\sync\bin\AirFilter.dll" enabled="true" />
</isapiFilters>
<security>
<access sslFlags="Ssl, Ssl128" />
<authentication>
<clientCertificateMappingAuthentication enabled="false" />
<iisClientCertificateMappingAuthentication
enabled="false" />
</authentication>
</security>
</system.webServer>
</location>
----------------------------------------------------------
You can see my filter, but the in the site level you see those exchange
filters.
There isn't any removes and such.
I think perhaps the Exchange Server is blocking any inheritance. is that
<clear/> tag actually clearing any inherited filters?
Thanks
"David Wang" wrote:
> > > > > > > > I used sysinternals' tool, Process Explorer, to check the w3wp..exe process
-kinetic
1. Removed the <clear/> tag from the filters at the Default Web Site level,
and it effectively started to inherit, and the filter began to work.
2. Before installing my filter at the global level, I removed the <clear/>
tag from the Default Website Level, and that worked too.
There are all manual steps. I'm guessing the best thing to do at this point
is to:
1. Install the filter by forcing it to lockItem (how and where is this done
in the config file? I'm guessing the Configuration API probably has this?
do I add it to the <filter ... /> tag?
2. Remove the <clear/> tag manually by xml parse from any / all locations?
or perhaps there's a Configuration API as well for this. I'm not using .NET
right now so I'm not exactly sure how I would do this without writing a .NET
app to handle this part of the installation.
I think the better thing would be to install the filter with a lockitem
parameter so that existing children will not be able to <clear> that item.
I'm not sure exactly where this attribute should be inserted into which tag.
You did mention the definition, but I added it with the <filter ...
lockItem="true".../> and it didn't have any effects, so I must be missing
that part.
Thanks!
"David Wang" wrote:
> > > > > > > > I used sysinternals' tool, Process Explorer, to check the w3wp..exe process
David Wang
not introduce that <clear /> item.
I know the UI allows that situation to happen (which is by-design),
but ABO Compatibility (which is what Exchange 2007 goes through in its
configuration) should not do that to Filters.
And thus we have to work around the issue with lockItem or an even
worse hack of searching and removing <clear /> (which I absolutely do
not recommend). IIS7 has a COM-accessible native-code Configuration
API (as well as Managed code version) to tweak configuration, and you
can certainly enumerate all sites for the isapiFilter collection to
perform the operation - but once again, it is barely better than the
hack of searching and removing <clear />.
And this is the real question -- who should have more rights -- the
system administrator which insists "all sites must have this filter"
or an application which insists "only allow this combination that I
know works" and require the person who installs the application to
arbitrate the correct behavior.
On Jan 25, 4:07 pm, -kinetic <kine...@discussions.microsoft.com>
wrote: