IIRF 2.0 Installation

Nov 5, 2009 at 8:42 AM

Greetings and can I just start by saying thank you for developing the IIRF. We have been using the previous version with no problems and I just have a few queries in the new version 2.0.

I am trying to read the installation documention on 2.0 and like a previous user pointed out, there may have been some old information on there that may need modifying. For example in the "Installing IIRF on IIS 5 or IIS 6" section, the first point was

"Copy the IIRF DLL (IsapiRewrite4.dll) to an appropriate folder"

should it just be the "IIRF.dll" now since that was what I got from the downloaded zip file.

And second point is:

"Place the settings file (IsapiRewrite4.ini), in the same directory as the DLL file. The filter will look for its settings in that file."

Should that be "IirfGlobal.ini" now?

I am running IIS6 on Windows Server 2003 and I added the filter in step 8, but when I get to step 9, under "Web Service Extensions", the "Ionic Rewriter" is not listed. Do I have to manually add it here too?

Anyway after following the instructions as best I could, I have "IIRF.dll" and "IirfGlobal.ini" in the same folder outside the web root (same place where I used to put the old version so the permissions should be right?), and an "IIRF.ini" on the document root of the website. In the IIRF.ini the first line I have put

StatusUrl /iirfStatus

In IIS it says the filter status is "Loaded", but when I try to go to www.site.com/iirfStatus it comes up with the standard IIS 404 error of File Not Found so it does not seem to be running? I wonder if I had done anything wrong and if you could spare some time to help on this matter. Thank you very much in advance if you can!

P.S. After trying a few things and not getting it to work with version 2.0, I put back the old version IsapiRewrite4.dll and IsapiRewrite4.ini into the same folder and the site is back working. But we would like to use the ability of just one DLL with multiple configuration file in this new version.

 

Coordinator
Nov 5, 2009 at 9:58 AM

Yes, good catch on the documentation.  Those things you noticed are, in fact, out of date.

Unfortunately I don't have a WS2003 machine available to me right now so I cannot walk through it with you.  I think you *may* have to manually add the DLL in that panel.  I'm sorry I just don't have a server here to try it.

Your ini files and DLL configuration sound correct.  If I were you I would insert some directives to configure the IIRF logfile in there:

RewriteLogLevel 3 
RewriteLog c:\temp\iirf2

You may find the lines in the logfile to clarify things.  But before you do this, see if you can add the DLL manually to the allowed web service extensions list.

 

Nov 5, 2009 at 12:22 PM

Thanks Cheeso for your reply!

I have manually added the DLL into the “Web Service Extensions” and also added the logging directives into IIRF.ini, and then restarted the IIS. When I try to access the site again, e.g. to www.site.com/iirfStatus, still nothing happens and I looked into the server and saw that even that log file wasn’t created. Even though the IIS Admin still say the DLL is “Loaded” it looks like it is not doing anything at all… It is definitely in use though because if I ever try to delete the DLL file itself it will not let me do so, citing "file is in use" unless I stop the web service.

Can I ask a few more questions in order to try a few more things..

1) Is the file "IirfGlobal.ini" required? If there are no global settings can I leave the file out completely?

2) Are the file names case sensitive? e.g. IIRF.ini

3) My website has its own Application Pool in IIS, would that make any difference? (I'm guessing it doesn't because your old version seems to work fine on it without having me changing any application pool settings)

4) Just to confirm the filenames and path that I have are ok:

C:\Inetpub\URLRewriter\IIRF.dll

C:\Inetpub\URLRewriter\IirfGlobal.ini

C:\inetpub\website_name\wwwroot\IIRF.ini  (Home Directory of this website being "C:\inetpub\website_name\wwwroot")

Although they do not work, as soon as I put back the old version

C:\Inetpub\URLRewriter\IsapiRewrite4.dll

C:\Inetpub\URLRewriter\IsapiRewrite4.ini

and repoint the DLL to this IsapiRewrite4.dll the site will start working again. For the old version I don't even need this DLL to be in the "Web Service Extensions" and it would work.

Coordinator
Nov 5, 2009 at 12:54 PM
Edited Nov 5, 2009 at 1:29 PM

Some answers

  1. IirfGlobal.ini is not required.  IT's not an error if it cannot be found.  If you omit it, a warning will be emitted into the log file.
  2. The names of the ini files are not case sensitive.
  3. no problem with the application pools.  That shouldn't affect the filter.
  4. the file paths look good to me.

Important - the v2.0 filter does not immediately start up and read the ini file, in the same way that the v1.2 filter did.  The v2.0 filter reads the ini file on the first request through the filter.  If you configure the filter, and start w3svc, then send no requests through the filter, there will be no log file.  IIRF v2.0 will not read the ini file, until a URL request comes through.  In v1.2, the IIRF logfile would just appear, as soon as w3svc was started. ,This is a difference in the way the v2.0 filter does its startup. 

In the absence of  *any* ini file, IIRF v2.0 will start up and will serve the status request.  I just tried this here, and when I make a request to http://server/iirfStatus , I get this:

 

Notice the warning messages that say the ini files could not bbe opened.

Can you tell me:

  • use Windows Explorer and right click on IIRF.dll, view the Properties.  Tell me the version number of the DLL file.   It should be v2.0.1.1003 or v2.0.1.1004
  • have you looked in the Windows Event Log (Application log)?  There will be an event emitted if IIRF tries to open a logfile, and cannot.  This would only happen if you specified an incorrect path for the logfile.  IF you have no ini file at all, then you won't get an event log message.
Nov 5, 2009 at 1:16 PM

OK understood about the ini file. I will always try to do an URL request after starting the service.

The file version number of the DLL file is actually 2.0.1.1 dated 15 Oct 2009, that is different from what you mentioned. It was downloaded today from your Download section under inside the zip file "IonicIsapiRewriter-2.0-Release-bin.zip"

I have been looking inside the Windows Event Log (Application Log), there isn't any entries that is to do with your DLL at all though. Even if I have both ini file in place "IirfGlobal.ini" and "IIRF.ini" there are still no events in the log and no log file was generated.

 

Coordinator
Nov 5, 2009 at 1:28 PM
Edited Nov 5, 2009 at 1:28 PM

Wow, this is a puzzle.

The only change since that version of the filter is that now IIRF includes a stack trace if it should crash.  You *may* be seeing that, but normally you would see an event log message if an ISAPI filter crashes.  Also you mentioned that the IIRF.dll is locked while w3svc is running.  So it seems unlikely that IIRF is crashing.

The website *is* running, correct?   Sometimes if multiple failures occur successively, IIS will stop the app pool .  At that point you need to administratively start it up again.   But as I say, if that happens you should see an event log message indicating as much.  In any case it won't hurt to check.

What is the content of your IIRF.ini ?

 

Nov 5, 2009 at 1:48 PM

Yes the website is running. It is just running as if there is no ISAPI Rewrite filter present, e.g. if I just go www.site.com it will display the home page. But if I go www.site.com/xxx/yyy where it would normally go via the rewriter to the correct URL it will say the standard IIS "Page not Found" error.

In the IIRF.ini I have stripped down to just the following:

 

# Log the Activity

RewriteLogLevel 3 
RewriteLog c:\windows\temp\iirf2.log

StatusUrl /iirfStatus

 

(Am using "C:\windows\temp" since there doesn't seem to be a C:\temp on the server)

I have tried without the IirfGlobal.ini and also tried with one. If the IirfGlobal.ini is present it only has one line in it:

 

RewriteEngine ON

Coordinator
Nov 5, 2009 at 2:00 PM

Ok, I'm not clear on something.  You say "But if I go www.site.com/xxx/yyy where it would normally go via the rewriter to the correct URL it will say the standard IIS "Page not Found" error."

But then In your IIRF.ini file, you have NO RULES.   You said, it's as if the filter is not running at all.  And in fact, there are no rules. So, it's almost like it isn't running at all.  I'm not sure why you think rewrites would occur, when you have no rules.  Maybe I am misunderstanding something.

Now, this website - the one rooted at c:\inetpub\website\wwwroot - is it configured with a URL path prefix?  In other words, what is the base URL path to get to that Website/IIS application?  Do all requests go there?  Is it the root, the main site?    or....something else?  maybe you could explain that to me.

Suppose your website has a doc root of c:\inetpub\website\wwwroot and a URL path root of /website.  This means if you surf to http://server/website, you will get to the site with the given document root.  Now in that document root, you have a IIRF.ini file, and it lists StatusUrl /iirfStatus.  Well that StatusUrl will never ever be satisfied, you see, because the URL path root for the website is /website.  The only URLs that arrive at that website have /website as the beginning of the URL path.  Does that make sense?  In which case, you need to have StatusUrl /website/iirfStatus in the ini file, if you ever want to see the status.  Do you understand that? 

It could be that IIRF is doing exactly what you told it to do, which is: nothing.

Nov 5, 2009 at 2:12 PM

Sorry, I mean www.site.com/iirfStatus it says "Page not Found". Before when I had some rules that rewrite /xxx/yyy to some other paths it also says "Page Not Found" but I've gradually stripped down all the rules. Those rules should be ok though since they worked fine on the old version.

 

This website is actually one of a few we are running on our server. They are all in the form of:

www.site1.domain.com

www.site2.domain.com

www.site3.domain.com

etc. , all set up as separate websites on IIS. They will then have the home directory of

c:\inetpub\site1\wwwroot

c:\inetpub\site2\wwwroot

c:\inetpub\site3\wwwroot

So when I go to the URL it will simply be www.site1.domain.com/iirfStatus and I would be hoping to see the status screen like the one you put up but I'm getting a page not found error. If I strip the IIRF.ini to just include the line

StatusUrl /iirfStatus

and then go www.site1.domain.com/iirfStatus it should give me that status page?

 

 

Coordinator
Nov 5, 2009 at 2:22 PM

Ok, I see...

So when I go to the URL it will simply be www.site1.domain.com/iirfStatus and I would be hoping to see the status screen like the one you put up but I'm getting a page not found error. If I strip the IIRF.ini to just include the line

StatusUrl /iirfStatus

and then go www.site1.domain.com/iirfStatus it should give me that status page?

That's right. Even more, if you have no IIRF.ini file at all on a website or application, you will still by default get /iirfstatus as a live endpoint; requesting it will give you report as above.   That is IF IIRF is configured properly.   It sounds to me like IIRF isn't really configured on the servers or sites that you think it is configured on.  It's hard to know because there is no logfile, we're getting no feedback whatsoever from the filter.  

Do you have a "home server", just www.domain.com ?   Does /iirfstatus work on that? 

 

 

Nov 5, 2009 at 3:03 PM

I just tried removing both IirfGlobal.ini and IIRF.ini (so no ini file present) and go to www.site1.domain.com/iirfStatus, it still gives me 404 error. So yes the DLL really seems it is not running. As soon as I repoint back to the old IsapiRewrite4.dll the status page will work immediately again, even if I put both DLL in the same directory with no ini file present, the old one will work and the new one doesn't. I noticed your new IIRF.dll is only 235kb compared to the old IsapiRewrite4.dll which is 682kB. That is ok I guess?

Unfortunately we don't have a "home server" because www.domain.com is not actually on that server machine. That machine only host all the subsites...

Do you have any older versions of the IIRF, e.g. 2.0.1.1003 that you mentioned, that I can try? Or any beta versions still available for download?

Coordinator
Nov 5, 2009 at 3:20 PM
Edited Nov 5, 2009 at 3:22 PM

you have the correct version.  It is the correct and operational. The size is smaller in the RELEASE build because it no longer includes debug information.

If you like you can download the IIRF zip again - it is now v2.0.1.1004 - that is the version that is running properly on my machine right now.

But I don't think it is a problem with the DLL.  Otherwise you would be getting crashes and event log messages.   It sure seems like a configuration issue to me.

Next thing I would do is look in the IIS logs -  for example in  c:\inetpub\logs\LogFiles\W3SVC1\u_ex091105.log

on my machine, I also have an HTTPErr log, at c:\windows\system32\LogFiles\HTTPERR\httperr1.log

You may find something there.

Also there's a tool lots of people run called URLSCAN.  If you are running that on your IIS server, then it may be swallowing the requests that you think are going to IIRF.  There's a logfile for that, too.   I don;t have a good explanation for why IIRF v1.2 works but IIRF v2.0 does not.

I know this is frustrating. I don't think it is a problem with the DLL. It's a configuration sisue.

Nov 5, 2009 at 3:51 PM

I've managed to find something!

If I access the site www.site1.domain.com/iirfstatus by using IE on the server machine, it displays the status page ok, but if I access the same page from another machine, then it says 404 error. And this is what I've got in the error log (the real IPs are modified  to be 111.222.333.xxx for security purposes):

2009-11-05 16:40:32 W3SVC918536531 111.222.333.162 GET /iirfStatus - 80 - 111.222.333.162 Mozilla/4.0+(compatible;+MSIE+8.0;+Windows+NT+5.2;+Trident/4.0;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 200 0 0
2009-11-05 16:40:37 W3SVC918536531 111.222.333.162 GET /iirfStatus - 80 - 111.222.333.51 Mozilla/5.0+(Windows;+U;+Windows+NT+5.1;+en-US;+rv:1.9.1.4)+Gecko/20091016+Firefox/3.5.4+(.NET+CLR+3.5.30729) 404 0 0

It looks like if I access from local machine then it is OK with state 200, but if I access it from another machine it is 404. It happens for both version 2.0.1.1 and 2.0.1.1004. The security settings for these files are the same as that of IsapiRewrite4.dll though.

Coordinator
Nov 5, 2009 at 3:58 PM

ok!  The /iirfstatus is working. That's good news.

 I don't know why I didn't point this out earlier, but /iirfstatus is always restricted to local query only.  Unless you specificaly allow it with a REMOTEOK modifer on the StatusUrl directive (check the doc), it will always return 404 when it is sent in remotely. That's in the docs but I forgot to point it out here.  I was assuming you were on the local server doing the query, I guess.

If you got at least one /iirfstatus response, then you should also be able to get a logfile out of IIRF (assuming you havve a RewriteLog directive in IIRF.ini).  This will now give you an opportunity to check out the status of IIRF as you add rules and so on, and submit requests.   

 

Nov 5, 2009 at 4:16 PM

I guess I should pay more attention to the documentation! (as always!) Anyway here is what the iirfstatus says:

 

IIRF Global Status
IIRF Version Ionic ISAPI Rewriting Filter (IIRF) v2.0n preview RELEASE 
Built on Oct 15 2009 21:10:42 
Filter DLL D:\Inetpub\URLRewriter\IIRF.dll\IIRF.dll  
Started 2009/11/06 01:06:33 (local time) 
Server Ini file D:\Inetpub\URLRewriter\IirfGlobal.ini  
Last Update of Ini 2009/11/05 17:11:37 (local time)  
  #lines 2 
  #warnings 0 
Rewrite Engine (all sites) ON 

IIRF Site Status
APPL_MD_PATH /LM/W3SVC/918536531/Root 
Ini file D:\Inetpub\www.sgs\wwwroot\Iirf.ini 
Ini file timestamp (file not found) 
  Last read 2009/11/06 01:06:33 (local time) 
  #Lines 0 
  #Rules 0 
  #Warnings 0 
  #Errors 0 
Log file (none) 
Log level 1 
Rewrite Engine ON 
Remote Status Inquiry disabled 
URL Decoding ON 
#Requests Processed 1 

 

A few thing I noticed is. The path to the DLL is actually

D:\Inetpub\URLRewriter\IIRF.dll

but the status page displays it as

D:\Inetpub\URLRewriter\IIRF.dll\IIRF.dll

which is probably nothing since the DLL is running OK.

 

But the more important thing is it says the path to IIRF.ini is:

D:\Inetpub\www.sgs\wwwroot\Iirf.ini

which is correct because the document root is D:\Inetpub\www.sgs\wwwroot

but it says "Ini file not found" even though it is definitely there?

Because it says it could not find the ini file it is not processing anything I put inside that Iirf.ini

 

 

Coordinator
Nov 5, 2009 at 4:38 PM
Edited Nov 5, 2009 at 4:47 PM

ok, we're getting somewhere.  It could be a permissions issue - the file IIRF.ini needs to be readable by... let's see, I think NetworkService ?   So you can go into Explorer and verify that the IIRF.ini file is readable by that identity.  Right click, properties... Security.  (something like that)

I just tried it here on IIS7 and if I don't give proper read permissions to the IIS worker process identity, I get a "file not found" error, even though the file IIRF.ini exists in the expected location.

That bug with the display of the DLL - I think it is benign.  Embarassing, but benign.   Thanks for reporting it, I will get that changed.

 

Nov 5, 2009 at 4:56 PM

Thank you very much! The site is now working!

I tried adding read permission to IIS_WPG to the iirf.ini file, but there was no difference. Then I removed that and added read permissions to "NETWORK SERVICE" to that ini file and it then works. So I think out of all the conversation we had it just come down to that one permission setting.

Thanks very much again for all your wonderful help on a wonderful product. It is very very much appreciated. Now I can have a good night's sleep and continue to work on applying the filter to multiple sites tomorrow!

PS. Yes I didn't think that path to DLL display was anything since the DLL file is obviously working. But I guess I got to the stage of being so close to the solution that I'd thought I'd point out any minor items in case it affected anything.

 

Coordinator
Nov 5, 2009 at 5:03 PM

Thanks for your patience and all the good feedback.

I'll have to double-check the docs and the steps I describe. I don't wanna force everyone to go through the trouble you went through!

 

Nov 6, 2009 at 12:35 AM

Would just like to let you know that in the end I did not have to add the Rewriter DLL under the "Web Service Extension" list in IIS. (I didn't have to in version 1.2 either) So I did not have to do step 9 of the "Installing IIRF on IIS 5 or 6" installation guide even though we are indeed using Windows Server 2003 running IIS 6.

Coordinator
Nov 6, 2009 at 4:46 AM

ok, thank you.