iirf working or not?

Topics: Developer Forum
May 17, 2010 at 4:28 AM


I am trying to run IIRF on a Windows 2003 R2 server (x86). This server is fully patched, etc.

I have installed the latest (at this time) beta release using the MSI provided. After installation the IIS administrative tool shows the ISAPI filter is installed and up for the default web site -exactly what I wanted.

If I ask for a bogus *.iirf file I get 

IIRF Version Ionic ISAPI Rewriting Filter (IIRF) RELEASE
Built May 7 2010 08:21:15

Nothing else seems to be working.

Asking for /iirfstatus results in a 404 error.

Tweaking various versions of iirfglobal.ini and local iirf.ini files seems to have no effect whatsoever, and the log destination specified remains empty.

Looking at the application log for the server I see that "testdriver" has crashed several times -though this corresponds to my attempts to parse various ini files (including the examples provided).


the global ini file contains the following:

RewriteFilterPriority HIGH
NotifyLog OFF
RewriteLog c:\temp\iirf\global
RewriteLogLevel 2
IterationLimit 10
MaxMatchCount 10
StatusInquiry ON
RewriteEngine ON


I have placed an example ini into the root of the default web site which contains something borrowed from one of your examples:

# act as a proxy the www.php.net site
ProxyPass ^/phpnet/(.*)$   http://www.php.net/$1 [I]
ProxyPassReverse   /phpnet/         http://www.php.net/


I am wondering if I have done something odd to damage the installation somehow. I compared the files on the server to the "zipped" installation set, and the only difference I noted was the lack of all the example stuff.

One thing I did notice while installing IIRF is that it did not like me attempting to put dll folder on a partition other than c:

I am specifically looking for reverse proxy stuff. This server runs a java based system which I would like to push out through the public IIS stuff.




May 17, 2010 at 6:37 AM

You've done something odd, yes.

You are specifying directives in the global file that are don't belong there;  they belong in the local ini file.

Re-check the documentation. It will tell you which directives are supported, and in which files. There are only 4 directives supported for the global file, as you can see in the front page of the documentation.

Once you get the log directives in the right place, you'll get a log file, and, I guess, other things will begin to work properly. Good luck.

May 18, 2010 at 5:14 AM

OK -have redistributed the directives... and still have the same problem. No logs. No apparent activity, nothing from /iirfstatus, but a "successful" response from a bogus *.iirf reference.

With respect to ^/phpnet/(.*)$ -where should iirf.ini go? I have placed it in the directory corresponding to the '/', but should it go into a virtual directory corresponding to /phpnet?




RewriteFilterPriority HIGH
NotifyLog OFF
StatusInquiry ON
RewriteEngine ON


RewriteLog c:\temp\iirf\global
RewriteLogLevel 2
IterationLimit 10
MaxMatchCount 10
StatusInquiry ON  

# act as a proxy the www.php.net site
ProxyPass          ^/phpnet/(.*)$   http://www.php.net/$1 [I]
ProxyPassReverse   /phpnet/         http://www.php.net/


May 18, 2010 at 10:12 PM

The iirf.ini file should go in the document root, the physical directory for the corresponding IIS vdir or application.

You say you are getting no log files. Have you created the \temp\iirf\global directory and granted proper permission to the IIS user identity?

I believe that IIRF will log a Windows Event if it cannot open the log file.


May 20, 2010 at 2:17 AM

I think something is definitely broken -I might try an earlier version of 2.1 if I can find one.

I set logging to x:\iirf using the iirf.ini file located in the web root of the default web site

checking ownership, etc

X:\>cacls iirf


IIS runs the default site as IUSR_MYHOST, and U have used another application (phpical) to test whether I can read or write as the web user.

The iirf.dll  file itself is readable/executable by the IUSR_MYHOST user, and the filter seems to be "snug" within the IIS configuration.

I try a couple of things:

2010-05-20 00:39:10 W3SVC1 -server- GET /phpnet/ - 80 - -client- -user agent- 403 14 5
2010-05-20 00:40:37 W3SVC1 -server- GET /iirfStatus - 80 - -client- -client- 404 0 2

Get errors (forbidden/not found -coming from IIS).

Nothing in the security, system or application logs to indicate anything happened at all.

However, if I run testdriver over one of the tests you provide in the "zipped" distribution I get the following in the system log.

Faulting application TestDriver.exe, version, faulting module IIRF.dll, version, fault address 0x0000abf4.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Category (100), event 1000


May 20, 2010 at 3:23 AM

The test driver doesn't get a lot of use these days.  It certainly shouldn't crash, and it's a bug that it did crash.   But a testdriver crash does not mean the IIRF DLL is bad.

Start by telling me exactly what's in the two IIRF INI files.  Previously you gave me that, but there's no mention of c:\iirf in the prior Ini files.  So I think something has changed.

Also - When you say "I set logging to c:\iirf" - is c:\iirf a directory?  a file?    The LogFile directive specifies the stub name of a log file. The actual name of the log file will include the process id of the W3WP.exe. 

also - When you request /iirfstatus, are you doing it from the local machine?  By default /iirfstatus returns 404 when requested for a remote machine. You need to append RemoteOk to the statusInquiry directive in the ini file, in order to allow remote /iirfstatus.  This is all documented in the help file.


May 20, 2010 at 4:10 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
May 20, 2010 at 10:53 PM


I moved the log file  target to a simpler path to mitigate any issues around passing permission through deep tree structures. The web root is on the x: drive of this system (x is the actual drive letter, not an obfuscation, and is a logical partition on the system drive).


iirf.ini is placed in this folder and contains the following:

RewriteLog x:iirf\root
RewriteLogLevel 2
IterationLimit 10
MaxMatchCount 10
StatusInquiry ON RemoteOK

# act as a proxy the www.php.net site
ProxyPass          ^/phpnet/(.*)$   http://www.php.net/$1 [I]
ProxyPassReverse   /phpnet/         http://www.php.net/


The iirf files are where the MSI put them

C:\Program Files\Ionic Shade\IIRF 2.1

iirf.dll and iirfGlobal.ini are in this folder. The global ini file contains

RewriteFilterPriority HIGH
NotifyLog OFF
StatusInquiry ON
RewriteEngine ON


I actually want to use this to proxy a java based tool (openfire xmpp services), but have not got as far as that yet.

This machine is a virtual machine running in our VMware ESX farm -I am not sure whether this should have any effect.



May 21, 2010 at 1:40 AM
Edited May 21, 2010 at 1:41 AM

yeah, it's sometimes good to keep it simple in the beginning, in order to figure out all the permissions and so on.

I'd feel better if your logfile path were not relative (x:iirf\root), but fully qualified (x:\iirf\root).  If you use the latter, then you need a directory called "iirf" in the root of drive X:, and iirf logfiles will be produced in that directory.  The base name of the IIRF logfile will be "root", with actual logfile names also containing the process ID and the suffix ".log" , with the result looking something like:  x:\iirf\root.2827.log , where 2827 is the process id of the w3wp.exe instance.  this is all as described in the documentation.

The IIS identity - whatever your IIS worker process uses - must have file create and write authority in that directory.   Normally this is NETWORK SERVICE on Windows Vista.   

And it won't matter if you run IIS and IIRF within a Virtual Machine.  It's just Windows.

The logfile will get created when IIRF first loads and reads its vdir-specific ini file; this happens when the first request flows through the IIS vdir in question.  If you submit http://hostname/iirfstatus, then that should cause IIRF to load, look for an IIRF.ini file in the web root (which you said was at x:\shared\web).  If IIRF finds the ini file, it will load it, and if there is a RewriteLog directive as well as a RewriteLogLevel directive in the ini file, IIRF will create a log file according to the logic I described above.

I think what you are seeing is, No IIRF log file.    IIRF will NOT create a log file, in the following circumstances:

  • IIRF is not configured properly.  Like maybe there's an incorrect path to the ISAPI filter. In this case IIS cannot load IIRF, and so IIRF can't do anything.
    Usually this is not a problem if you use the MSI to install IIRF.  If you have this problem, you will clearly see Windows Event log messages saying "IIS could not load ISAPI Filter xxxx".  See the "verifying and troubleshooting" section in the IIRF documentation for the exact details on this.
  • No request has flowed through IIS.  In this case IIRF will not load, and so obviously it will not create a log file.
  • No request has flowed through the vdir for which you have an IIRF ini file.  Same as above.
  • There's no IIRF.ini file in the web root for the vdir in question,
  • IIS cannot READ the ini file. 
    I've seen this happen if you, for example, create the ini file in one directory, then MOVE it to the web root directory.  In this case the original ACL on the file will travel with it, and it may lack the access to allow the IIS identity to read the file.  The effect is the same as no ini file at all.
  • The ini file is empty, or there's no RewriteLog directive in the  IIRF.ini file, or there's no RewriteLogLevel directive in the IIRF ini file.
    In this case, IIRF will assume you don't want logging.
  • The IIS identity does not have permissions to create a log file in the designated directory.
    In this case you should see a message in the Windows Event Log .

If I had to guess, I'd bet that you're not getting a logfile, because of access denial - the last possibility in that list.

If you read the documentation, http://cheeso.members.winisp.net/Iirf20Help/html/6b426152-704a-4907-b87e-2e1938a89cad.htm , it describes and discusses the permissions required by IIRF.

The ACL you described for x:\iirf  included IUSR_MYHOST.  I believe this is not the correct identity.  It's my understanding that on WS2003, that identity is used when running ASPNET (ASP etc) when anonymous access is used.  But, This is not the identity IIS uses for ISAPI filters.  You need to provide access on the IIRF log directory to the Worker Process Group, which on IIS6 is IIS_WPG, as described in the doc link I provided just above.

If you're doing something funky with your IIS worker process identities, whatever ID you use should be placed into the IIS_WPG group.  That's why I suggest using the group, rather than a particular identity, for ACLs pertainng to IIRF logfiles and ini files.

One sure way to verify that it is an identity issue is to open the ACL on that directory to ALL users (EVERYONE);  Then stop and restart IIS.  If you then get an IIRF log file in that directory, you have proven that it is an ACL issue.

Let me know how you get on.



May 21, 2010 at 9:16 AM

OOps, the x:iirf\root is a typo I have introduced copying all this stuff around -have fixed the settings file appropriately.

I am fairly certain IIS is loading the dll fine as I get a response from it when I request a ".iirf" file.

Granted "everyone" full control of the log folder, restarted the IIS stack of services and... no change :-(

"Granted "everyone" read/execute access on iirf.ini, restarted the IIS stack and... IT WORKS!

IIRF Version Ionic ISAPI Rewriting Filter (IIRF) RELEASE
Built on May 7 2010 08:21:15
Filter DLL C:\Program Files\Ionic Shade\IIRF 2.1\IIRF.dll 
PCRE Version 8.02 2010-03-19
IIRF Started 2010/05/21 20:01:14 New Zealand Standard Time
Current time 2010/05/21 20:14:55 New Zealand Standard Time
Server Ini file C:\Program Files\Ionic Shade\IIRF 2.1\IirfGlobal.ini 
Last Update of Ini 2010/05/18 15:42:24 New Zealand Standard Time 
  #Lines 7
  #Warnings 0
Rewrite Engine (all vdirs) ON

IIRF Vdir Status

Ini file X:\Shared\web\Iirf.ini
Ini file timestamp 2010/05/21 19:57:57 New Zealand Standard Time
  Last read 2010/05/21 20:06:03 New Zealand Standard Time
  #Ini Modules 1
  #Lines 20
  #Rules 1
  #Warnings 0
  #Errors 0
Log file x:\iirf\root.3172.log
Log level 2
Rewrite Engine ON
Rewrite Base '--'
Remote Status Inquiry enabled
URL Decoding ON
Iteration Limit 10
Proxy Timeouts (sec.) Resolve=30 Connect=30 Send=30 Receive=30
#Requests Processed 17


Ugh. I had assumed the whole thing ran as the local internet user, and anything else (like the svc32 host stuff) was taken care of by SYSTEM. I had just got around to using procmon to dig down through the innards.

Cool, and thanks -I'll now get on with the next part of this experiment!

I'll have a chat with our local Windows gurus to see what finer settings I need to apply -I would normally have used an Apache system for this, but have had to use iis in windows for various reasons.





May 21, 2010 at 3:44 PM

Definitely want to read the documentation, specifically around installation.  The issue of IIS user identity and required permissions is covered there.