David
Tue Feb 20 20:39:28 CST 2007
FYI: your question is really about the configured and supported
behavior of the 3rd party ISAPI used by the Library Database server.
This means that it really has nothing to do with IIS.
You really should pose this question to the support personel for that
ISAPI because that's the party responsible to support your questions.
If I was responsible for a deadline, I would make sure that everything
involved in the deadline is either directly handled by me, or consists
of software/services that someone ELSE is directly responsible for.
One simply cannot depend on unsupported software because it will
eventually force you to ask for sympathy and educated guesses to
resolve issues, which may not be a good approach against a deadline.
I'm not saying that I do not believe in compassion or that people are
impassionate. I'm saying that when it comes to a sharp line like being
responsible to meet a deadline, having the correct skills engaged is
the right answer.
Because otherwise, I wouldn't be writing this response...
Now, I do know IIS and ISAPI well enough to guess based on your
observations what is going on and offer a suggestion on resolution.
However, you need to be aware that the responsible party for answering
your question is the support personel for that ISAPI.
Inconsistencies in your observations:
1. It sounds like your ISAPI DLL is an ISAPI Extension, not ISAPI
Filter, since you are making requests to it inside a Virtual Folder.
You cannot make direct requests to an ISAPI Filter; it fires
throughout request processing and is not a target of the request.
2. "Script" permissions is insufficient to invoke ISAPI Extension. To
execute ISAPI Extension on IIS6 you need to enable a Web Service
Extension for it, then either "Scripts and Executables" permission for
direct DLL or just "Scripts" if you create an Application Mapping.
ISAPI Filter just works as soon as loaded.
Other questions:
- Are Site A and Site B using the same or different INI file. I
presume different
- When you say "stop site A" you mean that you just right click on the
site and stop it
- When you say "setup ISAPI on site A" you mean to setup a vdir
pointing to a physical directory containing the ISAPI DLL and INI
file. And it is two different physical directories and files used by
site A and site B.
This is what I think is going on:
- I suspect that the ISAPI only loads its INI file on initial startup
when IIS loads the ISAPI DLL. By default, this happens once per worker
process and lasts through the lifetime of the worker process. When you
start/stop the website, that does not shut down the worker process, so
the ISAPI does not re-load its INI file.
- I also suspect the ISAPI stores the INI file configuration in some
process-wide scope.
So here's an explanation for what you observed:
- When you first load it from site A, 192.168.99.202 port 81 is read
from INI file and placed in process-wide scope.
- When you stop site A and first load it from site B, 192.168.99.202
port 80 is read from the other INI file and placed in process-wide
scope, overwriting the previous settings
- When you restart site A, since no INI file is read (no process
restarted), the ISAPI continues to use the process-wide settings of
192.168.99.202 port 80
- When you stop site B and try A again, since no INI file is read, the
ISAPI continues to use the process-wide settings of 192.168.99.202
port 80
Thus, if the ISAPI DLL works the way I suspect, there is no way to
configure what you want within one process and Application Pool. You
can use IIS6 to create multiple Application Pools and assign site A to
one and site B to another. However, I cannot guarantee that the ISAPI
DLL works multi-instance, nor that the scope of its shared data is per-
process (maybe it is global? don't know without seeing source code or
documentation). You can also claim that this is a feature-request for
the ISAPI to respond to FileChangeNotification or to store
configuration in a per-module fashion, but those are code-changes
unlikely to meet your deadline.
In other words, the best source for your answers is someone who knows
and supports the ISAPI DLL you are using.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Feb 20, 2:26 pm, "revert" <fatf...@hotmail.com> wrote:
> Hi,
>
> Thanks for your help ahead of time, I'm very new to IIS, and I need
> help.
>
> My situation is this:
>
> I have a working library database server with a built-in web server
> using Polaris. I have two different sites, same IP address, but on
> different ports, one 80 other 81. I need to use the IIS box on the
> DMZ to forward requests to both websites on the library server. I'm
> testing this all on virtual machines, so the networking right now is
> very simple (same subnet no firewalls)
>
> The software came with an ISAPI filter, for use with IIS, which
> redirects requests to the library server when you use specific URLs.
> I set up a test with no problem using the default website by using a
> virtual folder with script permissions for the dll and an ini file. I
> change the ini file which tells the filter what IP and port to use. I
> could change the port back and forth, to go to both websites on the
> other server one at a time after restarting IIS.
>
> So then after some reading, I decided that I need to use host headers
> to do what I want to do. I set up two different websites, identical
> to each other than name, home directory, and where the ISAPI filter
> should be forwarding requests. I did a lot of reading on host
> headers, and I'm pretty sure that I set them up correctly, I even
> added DNS so that I could be sure that the headers were being passed.
> As far as the stuff I know from what I read so far, it "should" work.
>
> However, I'm having weird issues with the different websites after I
> set them up. The scripts have a built in page that tells you if the
> filter is setup correctly, and what port is being forwarded to. After
> much frustration, I think I at least have a solid symptom:
>
> 1. I setup ISAPI on site A, and test the filter, shows that requests
> are being forwarded to 192.168.99.202 on port 81.
>
> 2. I stop site A, setup site B with a different scripts directory and
> ISAPI filter, test the filter and it shows that requests are being
> forwarded to 99.202 port 80
>
> 3. Then I start site A again and test the filter. It's using 80, the
> port that site B is supposed to use. The dll and the ini files
> haven't changed, so what am I missing?\
>
> 4. I then stop B and try A again. It's still using port 80. . .
>
> I think at step 4 I've eliminated the possibility that it's host
> headers causing the problem, right? Is there something else that I
> need to setup when I use IIS this way?
>
> I'm using IIS in server 2003. Sorry for writing a book, but I guess
> I'm too new to know what is relevant and what isn't. Thanks for your
> time, I'm coming up on the deadline for me to roll this out, and I'm
> thoroughly stuck.
>
> -Rob Evert