IIS7 Support for ISAPI Filters

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_and...x_Commo

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....DeleteThis@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 -
 >> Stay informed about: IIS7 Support for ISAPI Filters 

Hey David,

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

"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_and...x_Commo
>
> 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....DeleteThis@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 -
>
>
 >> Stay informed about: IIS7 Support for ISAPI Filters 

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_and...x_Commo
>
> 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....TakeThisOut@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 -
>
>
 >> Stay informed about: IIS7 Support for ISAPI Filters 

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-PreConditions...d-the-I

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... RemoveThis @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
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Jan 18, 5:33 pm, -kinetic <kine... RemoveThis @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 -
>
> - Show quoted text -
 >> Stay informed about: IIS7 Support for ISAPI Filters 

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-PreConditions...d-the-I
>
> 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....DeleteThis@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
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > > On Jan 18, 5:33 pm, -kinetic <kine....DeleteThis@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 -
> >
> > - Show quoted text -
>
>
 >> Stay informed about: IIS7 Support for ISAPI Filters 

If what you say is true, then that is a bug in IIS7.

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.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//







On Jan 23, 10:26 am, -kinetic <kine....RemoveThis@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...
>
> > 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....RemoveThis@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
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
>
> > > > On Jan 18, 5:33 pm, -kinetic <kine....RemoveThis@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 -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: IIS7 Support for ISAPI Filters 

Hi David,

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:

> If what you say is true, then that is a bug in IIS7.
>
> 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.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
>
> On Jan 23, 10:26 am, -kinetic <kine... RemoveThis @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...
> >
> > > 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... RemoveThis @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
> > > > >http://w3-4u.blogspot.com
> > > > >http://blogs.msdn.com/David.Wang
> > > > > //
> >
> > > > > On Jan 18, 5:33 pm, -kinetic <kine... RemoveThis @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 -
> >
> > > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
>
>
 >> Stay informed about: IIS7 Support for ISAPI Filters 

Ok, thanks for clarifying what you are saying. Based on your repro
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.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//





On Jan 24, 11:23 am, -kinetic <kine... RemoveThis @discussions.microsoft.com>
wrote:
> Hi David,
>
> 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:
> > If what you say is true, then that is a bug in IIS7.
>
> > 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.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Jan 23, 10:26 am, -kinetic <kine... RemoveThis @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....
>
> > > > 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... RemoveThis @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
> > > > > >http://w3-4u.blogspot.com
> > > > > >http://blogs.msdn.com/David.Wang
> > > > > > //
>
> > > > > > On Jan 18, 5:33 pm, -kinetic <kine... RemoveThis @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 -
>
> > > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: IIS7 Support for ISAPI Filters 

Hi David,

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:

> Ok, thanks for clarifying what you are saying. Based on your repro
> 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.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
> On Jan 24, 11:23 am, -kinetic <kine... DeleteThis @discussions.microsoft.com>
> wrote:
> > Hi David,
> >
> > 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:
> > > If what you say is true, then that is a bug in IIS7.
> >
> > > 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.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > > On Jan 23, 10:26 am, -kinetic <kine... DeleteThis @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....
> >
> > > > > 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... DeleteThis @discussions.microsoft.com>