Re: (WMI) IIsFilterSetting.FilterState doesn't appear to change
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 02/01/05
- Next message: David Wang [Msft]: "Re: Compatibility question between IIS5 and IIS6"
- Previous message: Ken Schaefer: "Re: how to determine if SSL or not (help please)"
- In reply to: Robest: "(WMI) IIsFilterSetting.FilterState doesn't appear to change"
- Next in thread: Robest: "Re: (WMI) IIsFilterSetting.FilterState doesn't appear to change"
- Reply: Robest: "Re: (WMI) IIsFilterSetting.FilterState doesn't appear to change"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 31 Jan 2005 23:34:47 -0800
Actually, the FilterState property is not a very accurate means of
determining ISAPI filter status on IIS. The property was reasonable prior
to IIS6 because it had a 1:1 tie with inetinfo.exe, but with IIS6 worker
process isolation mode, the property is all but meaningless to indicate
correct status. It remains for compatibility reasons, but only if you know
how to interpret it.
1. The FilterState property simply indicates the status when IIS last
attempted to load the particular filter into *any* process. In other words,
if you have two application pools, one global filter, and the filter failed
to load for the second application pool -- depending on the order of
application pool startup, FilterState would either indicate success or
failure -- and you have no idea which.
2. Furthermore, FilterState never accurately portrays filter load status --
if IIS successfully load the filter and then recycle'd the application pool,
FilterState would remain "1" even though the filter DLL is not loaded in
memory
3. FilterState never indicated whether the filter is actually loaded by
IIS -- FilterLoadOrder property determines which filter is actually loaded.
So, your observation from the UI is that it simply deletes the filter name
from the FilterLoadOrder property *without* removing the filter object
itself -- hence you still see FilterState property in the filter object even
though the filter is not even loaded.
In short, FilterState is quite a misnomer. It does not accurately describe
the state of the filter on IIS6 -- it only describes the state when IIS last
tried to load it -- it does not describe when the filter is unloaded,
recycled, nor multi-instance status. It happened to work a bit better on
prior IIS versions because only inetinfo.exe would load filters (single
instance) and all site/global filters loaded as W3SVC started and were only
unloaded when W3SVC stopped. In other words, when IIS is running, filter
state guaranteed the last filter load status, and since filters do not
unload unless IIS stops, it is guaranteed to be consistent. On IIS6, since
filters can be in multiple instances of w3wp.exe, can demand load/unload as
added/removed, and can load/unload as w3wp.exe recycles, FilterState simply
does not work and still retain any resemblance of backwards compatibility.
The current behavior works "ok" if you don't look too hard at it.
However, IIS6 does improve on filter status in one regard -- if a configured
Filter DLL fails to load, IIS will not start that site. If a global filter
fails to start, it results in the webserver going down with 503. In other
words, if you configure a filter to load, if it fails, the server fails.
Prior IIS versions will silently fail a filter load, so you literally had to
figure out filter status.
Thus, I suggest this strategy with IIS6:
1. Determine which website(s) (or global) are configured to load the ISAPI
Filter
2. Use WMI to locate your Filter DLL in memory of the w3wp.exe process named
by #1. You can work backwards by first figure out which Application Pools
serve which Websites, and then which w3wp.exe belongs to which Application
Pool, and finally, which Filter DLL is in which w3wp.exe
3. From the associations of #2, make sure that the Filter DLLs are in the
correct w3wp.exe processes. You are assured that if the Filter DLL failed
to load in a w3wp.exe that IIS will fail that website(s), so you just need
to assure that w3wp.exe are actually configured to run and show up in the
right process.
-- //David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "Robest" <robest@community.nospam> wrote in message news:4BC04000-99A5-49CA-B7AD-1D7E65A1343A@microsoft.com... Hi, I'm trying to use WMI to monitor the state of a webserver (IIS6 / W2K3). In particular I wish to check that an ISAPI filter is (remains) correctly loaded. On my test server I have a clean build of W2K3 with IIS6, and my filter installed on the default web site. I've been using WMI CIM Studio to determine which classes I need to inspect. I had thought that I had found what I needed: IIsFilterSetting.FilterState. When my filter was correctly loaded and operating this property was shown as 1, which I took to mean 'loaded' as documented here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/3823cd97-b243-47ee-bff1-9cfaba632806.asp However, when I removed the filter (completely uninstalled it using the IIS management console), the FilterState property remained at 1, and the relevant IIsFilter object was still associated with the default website. I have stoppped / started the site and the web service to no effect (either in CIM studio, or in my script which looks up the property). What am I missing? How do I monitor the status of my filter using WMI? Cheers Rob
- Next message: David Wang [Msft]: "Re: Compatibility question between IIS5 and IIS6"
- Previous message: Ken Schaefer: "Re: how to determine if SSL or not (help please)"
- In reply to: Robest: "(WMI) IIsFilterSetting.FilterState doesn't appear to change"
- Next in thread: Robest: "Re: (WMI) IIsFilterSetting.FilterState doesn't appear to change"
- Reply: Robest: "Re: (WMI) IIsFilterSetting.FilterState doesn't appear to change"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
