IIS7 Support for ISAPI Filters

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

RE: IIS7 Support for ISAPI Filters

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

Re: 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_Di agnose_and_Fix_C=
ommon_ISAPI_Filter_Installation_Failures.aspx

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=A0pm, -kinetic
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. =A0It'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 hav=
e
> > backward compatibility with ISAPI Filters.
>
> > Where can I find more information?
>
> > Thanks- Hide quoted text -
>
> - Show quoted text -

Re: 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_Di agnose_and_Fix_Common_ISAPI_Filter_Installation_Failures.asp x
>
> 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
> 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 -
>
>

Re: 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_Di agnose_and_Fix_Common_ISAPI_Filter_Installation_Failures.asp x
>
> 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
> 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 -
>
>

Re: 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=3Dtrue

http://blogs.msdn.com/david.wang/archive/2006/03/18/IIS7-Pre Conditions-and-t=
he-Integrated-Pipeline.aspx

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=A0pm, -kinetic
wrote:
> Hi David,
>
> Thanks for the reply! =A0I am currently the provider of the filter. =A0My =
team
> has it working for IIS6 on 32-bit and 64-bit Windows operating systems, bu=
t
> we are looking forward to supporting IIS7 and Server 2008. =A0We 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 considerabl=
y
> 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. =A0How
> exactly should I setup the failed request tracing to help show me if the D=
LL
> is being loaded?
>
> I'm currently trying a simple 404 error logger, which basically filters th=
e
> 404 errors and logs them somewhere else. =A0So in the Failed Request Traci=
ng,
> I've added 404. =A0I get a warning when I try the request, but nothing abo=
ut
> the loading.
>
> I do see ISAPIFilterModule in the modules list, so I figure it's installed=

> and configured, but perhaps I'm missing something? =A0What 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_D iagnose_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
> > 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 Long=
horn
> > > > (Server 2008) with Exchange 2007 server. =A0It's currently not worki=
ng, 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 -

Re: 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-Pre Conditions-and-the-Integrated-Pipeline.aspx
>
> 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
> 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_D iagnose_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
> > > 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 -
>
>

Re: 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 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=A0am, -kinetic
wrote:
> Hi David,
>
> I figured out the problem. =A0I was loading the filter at the global level=
,
> but I also had Exchange 2007 server installed. =A0I believe something happ=
ened
> at the "Default Web Site" level that removed inheritance of the filters, t=
hus
> 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 inheritan=
ce
> properties and such during our installation process? =A0It seems like ther=
e's a
> new level of complexity with inheritance, and without being able to predic=
t
> the situation on IIS7 in terms of inheritance, we'll need a solution for t=
hat.
>
> Do you have any suggestions on how this inheritance can be figured out, an=
d
> 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=3Dtrue
>
> >http://blogs.msdn.com/david.wang/archive/2006/03/18/IIS7-Pr eCondition...
>
> > 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
> > wrote:
> > > Hi David,
>
> > > Thanks for the reply! =A0I am currently the provider of the filter. =
=A0My 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. =A0We are a=
ware 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 conside=
rably
> > > 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 pro=
cess
> > > 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 b=
ut
> > > it's also not showing me information about the loading of the dll. =A0=
How
> > > exactly should I setup the failed request tracing to help show me if t=
he DLL
> > > is being loaded?
>
> > > I'm currently trying a simple 404 error logger, which basically filter=
s the
> > > 404 errors and logs them somewhere else. =A0So in the Failed Request T=
racing,
> > > I've added 404. =A0I 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 insta=
lled
> > > and configured, but perhaps I'm missing something? =A0What else is nee=
ded to
> > > enable isapi filters on IIS7?
>
> > > Thanks!
>
> > > "David Wang" wrote:
> > > > I think you should look for more information from the provider of th=
e
> > > > 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" featur=
e
> > > > 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_D iagnose_an=
....
>
> > > > Now, I am not aware of any Microsoft documentation on how to get ISA=
PI
> > > > 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 t=
he
> > > > 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
> > > > 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. =A0It's currently not w=
orking, and
> > > > > > logging doesn't even show it being initialized/loaded.
>
> > > > > > I have searched far and wide for any documentation about the sup=
port, or
> > > > > > more importantly what is needed for the IsapiFilterModule in IIS=
7 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 -

Re: 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 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
> 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-Pr eCondition...
> >
> > > 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
> > > 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_D iagnose_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
> > > > > 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 -
>
>

Re: 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
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=A0am, -kinetic
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" le=
vel?
>
> I tried this just now:
>
> 1. =A0I put the filter in the global level, and then went to the site leve=
l
> and hit "Revert to Inherited". =A0Sure enough the filter now shows up at t=
he
> site level.
>
> 2. =A0I restart the IIS service with /iisreset /noforce computername
>
> 3. =A0I tested the filter by making a request with my web browser, works f=
ine.
>
> 4. =A0Removed the filter explicitly from the site level, making sure the
> global level still has the filter and restart the IIS service.
>
> 5. =A0I make the same request with the browser, and the filter is no longe=
r
> loading and doesn't work.
>
> You're saying that it should still work at this point? =A0If that's the ca=
se
> then I'll go report the bug.
>
> In the meantime, is there any security risks that I'm overlooking by worki=
ng
> 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 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
> > wrote:
> > > Hi David,
>
> > > I figured out the problem. =A0I was loading the filter at the global l=
evel,
> > > but I also had Exchange 2007 server installed. =A0I believe something =
happened
> > > at the "Default Web Site" level that removed inheritance of the filter=
s, 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 inher=
itance
> > > properties and such during our installation process? =A0It seems like =
there's a
> > > new level of complexity with inheritance, and without being able to pr=
edict
> > > the situation on IIS7 in terms of inheritance, we'll need a solution f=
or 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 wil=
l
> > > > 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=3Dtrue
>
> > > >http://blogs.msdn.com/david.wang/archive/2006/03/18/IIS7-Pr eCondition=
....
>
> > > > On 64bit Windows/IIS it used to be very easy to get 503 service
> > > > unavailable if you mismatch the process and DLL bitness. That mistak=
e
> > > > 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
> > > > wrote:
> > > > > Hi David,
>
> > > > > Thanks for the reply! =A0I am currently the provider of the filter=
.. =A0My team
> > > > > has it working for IIS6 on 32-bit and 64-bit Windows operating sys=
tems, but
> > > > > we are looking forward to supporting IIS7 and Server 2008. =A0We a=
re aware of
> > > > > the possibility of it being compatible with filters still, even th=
ough it is
> > > > > moving forward with the modules.
>
> > > > > I have added the filter to the ISAPIFilters in IIS7, but it is con=
siderably
> > > > > a different looking UI such that I'm not sure if it's loading or n=
ot.
>
> > > > > 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 Traci=
ng but
> > > > > it's also not showing me information about the loading of the dll.=
=A0How
> > > > > 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 fi=
lters the
> > > > > 404 errors and logs them somewhere else. =A0So in the Failed Reque=
st Tracing,
> > > > > I've added 404. =A0I get a warning when I try the request, but not=
hing about
> > > > > the loading.
>
> > > > > I do see ISAPIFilterModule in the modules list, so I figure it's i=
nstalled
> > > > > and configured, but perhaps I'm missing something? =A0What else is=
needed to
> > > > > enable isapi filters on IIS7?
>
> > > > > Thanks!
>
> > > > > "David Wang" wrote:
> > > > > > I think you should look for more information from the provider o=
f 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 th=
e
> > > > > > 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" fe=
ature
> > > > > > of IIS7 to see the exact details. Those two observations, event =
log
> > > > > > and failed request tracing, is enough for me to resolve most fil=
ter
> > > > > > issues.
>
> > > > > >http://blogs.msdn.com/david.wang/archive/2005/06/21/HOWTO_D iagnos=
e_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 probab=
ly 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 =

> > > > > > wrote:
> > > > > > > I mean Longhorn with IIS7 not exchange 2007!
>
> > > > > > > "-kinetic" wrote:
> > > > > > > > I have an ISAPI Filter from IIS6 and would like it to work w=
ith Longhorn
> > > > > > > > (Server 2008) with Exchange 2007 server. =A0It's currently n=
ot 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 -

Re: IIS7 Support for ISAPI Filters

Hi David,

Thanks for the reply again. I understand what you mean by , 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 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
> 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
> 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 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
> > > 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-Pr eCondition....
> >
> > > > > 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
> > > > > 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_D iagnose_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
> > > > > > > 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 -
>
>

Re: IIS7 Support for ISAPI Filters

Locking is a behavior of the underlying IIS7 configuration system. You
can look at the 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 ) 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=3Dallow 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
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
. 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


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








On Jan 24, 5:31=A0pm, -kinetic
wrote:
> Hi David,
>
> Thanks for the reply again. =A0I understand what you mean by , 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. =A0I'm writing a filter for using my own authentication, so we
> installed the filter in the global level. =A0It apparently wasn't propagat=
ing
> down to the site level. =A0We never had it "cleared" but perhaps the Excha=
nge
> 2007 Server had it "locked"? =A0When I hit "Revert to Inherited" it did sh=
ow
> the filter from the global level and everything started to work.
>
> So along with is there also a lock that could be applied at the si=
te
> level that prevented anything from being inherited, perhaps by exchange?
>
> Also, how is the global filter able to be locked? =A0Is this a configurati=
on
> option? =A0Using 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
> > 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
> > 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. =A0I put the filter in the global level, and then went to the site =
level
> > > and hit "Revert to Inherited". =A0Sure enough the filter now shows up =
at the
> > > site level.
>
> > > 2. =A0I restart the IIS service with /iisreset /noforce computername
>
> > > 3. =A0I tested the filter by making a request with my web browser, wor=
ks fine.
>
> > > 4. =A0Removed the filter explicitly from the site level, making sure t=
he
> > > global level still has the filter and restart the IIS service.
>
> > > 5. =A0I make the same request with the browser, and the filter is no l=
onger
> > > loading and doesn't work.
>
> > > You're saying that it should still work at this point? =A0If that's th=
e case
> > > then I'll go report the bug.
>
> > > In the meantime, is there any security risks that I'm overlooking by w=
orking
> > > around this problem by installing the filter at the site level for eve=
ry
> > > 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 th=
at
> > > > 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 Compatibili=
ty
> > > > Feature will remap your existing ABO calls to put the filter in the
> > > > right list. It is critical that you do not add 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 bes=
t
> > > > 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 tha=
t
> > > > 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
> > > > wrote:
> > > > > Hi David,
>
> > > > > I figured out the problem. =A0I was loading the filter at the glob=
al level,
> > > > > but I also had Exchange 2007 server installed. =A0I believe someth=
ing happened
> > > > > at the "Default Web Site" level that removed inheritance of the fi=
lters, thus
> > > > > not applying my global filter.
>
> > > > > Since we wrote the filter for IIS6, we never encountered inheritan=
ce
> > > > > problems and just installed the filter at the "global level".
>
> > > > > Is there a metabase sort of emulator for IIS7 where we can check i=
nheritance
> > > > > properties and such during our installation process? =A0It seems l=
ike there's a
> > > > > new level of complexity with inheritance, and without being able t=
o predict
> > > > > the situation on IIS7 in terms of inheritance, we'll need a soluti=
on 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 w=
ith
> > > > > > Enable32bitAppOnWin64=3Dtrue
>
> > > > > >http://blogs.msdn.com/david.wang/archive/2006/03/18/IIS7-Pr eCondi=
tion....
>
> > > > > > On 64bit Windows/IIS it used to be very easy to get 503 service
> > > > > > unavailable if you mismatch the process and DLL bitness. That mi=
stake
> > > > > > 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 =

> > > > > > wrote:
> > > > > > > Hi David,
>
> > > > > > > Thanks for the reply! =A0I am currently the provider of the fi=
lter.. =A0My 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. =A0=
We are aware of
> > > > > > > the possibility of it being compatible with filters still, eve=
n 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 T=
racing but
> > > > > > > it's also not showing me information about the loading of the =
dll. =A0How
> > > > > > > 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 basicall=
y filters the
> > > > > > > 404 errors and logs them somewhere else. =A0So in the Failed R=
equest Tracing,
> > > > > > > I've added 404. =A0I 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? =A0What els=
e is needed to
> > > > > > > enable isapi filters on IIS7?
>
> > > > > > > Thanks!
>
> > > > > > > "David Wang" wrote:
> > > > > > > > I think you should look for more information from the provid=
er 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 def=
ault..
>
> > > > > > > > What "logging" are you talking about. IIS7 definitely logs t=
o the
> > > > > > > > Event Log when it fails to load an ISAPI Filter just like II=
S6, and
> > > > > > > > you can also install and turn on the "Failed Request Tracing=
" feature
> > > > > > > > of IIS7 to see the exact details. Those two observations, ev=
ent 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_D ia=
gnose_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 pr=
obably the
> > > > > > > > only person who can do that,
>
> ...
>
> read more =BB- Hide quoted text -
>
> - Show quoted text -

Re: IIS7 Support for ISAPI Filters

Hi David,

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:

----------------------------------------------------------



....



path="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_f ilter.dll"
enabled="true" enableCache="true" preCondition="bitness32" />
path="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet _filter.dll"
enabled="true" enableCache="true" preCondition="bitness64" />
enabled="true" />


....



....






path="C:\Program Files\Microsoft\Exchange
Server\ClientAccess\sync\bin\AirFilter.dll" enabled="true" />





enabled="false" />




----------------------------------------------------------


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
tag actually clearing any inherited filters?

Thanks

"David Wang" wrote:

> Locking is a behavior of the underlying IIS7 configuration system. You
> can look at the 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 ) 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
> 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
> . 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
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
>
>
> On Jan 24, 5:31 pm, -kinetic
> wrote:
> > Hi David,
> >
> > Thanks for the reply again. I understand what you mean by , 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 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
> > > 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
> > > 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 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
> > > > > 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-Pr eCondition....
> >
> > > > > > > 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
> > > > > > > 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_D iagnose_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,
> >
> > ...
> >
> > read more »- Hide quoted text -
> >
> > - Show quoted text -

Re: IIS7 Support for ISAPI Filters

I tried a few different things:

1. Removed the 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
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 tag?

2. Remove the 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 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 lockItem="true".../> and it didn't have any effects, so I must be missing
that part.

Thanks!

"David Wang" wrote:

> Locking is a behavior of the underlying IIS7 configuration system. You
> can look at the 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 ) 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
> 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
> . 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
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
>
>
>
> On Jan 24, 5:31 pm, -kinetic
> wrote:
> > Hi David,
> >
> > Thanks for the reply again. I understand what you mean by , 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 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
> > > 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
> > > 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 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
> > > > > 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-Pr eCondition....
> >
> > > > > > > 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
> > > > > > > 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_D iagnose_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,
> >
> > ...
> >
> > read more »- Hide quoted text -
> >
> > - Show quoted text -