First of all ISAPI_Rewrite installer ensures that ISAPI Filters and ISAPI Extensions components are installed in IIS.

This done installation starts (proper installation package may be downloaded here; it’s called ISAPI_Rewrite3_00xx_x64.msi).
Then proxy handlers are registered in Handler Mappings snap-in.

Two records must be added: Helicon Proxy_32 and Helicon Proxy_x64:

After that ISAPI_Rewrite filters are registered in ISAPI Filters snap-in:

You must see these two filters in the list: ISAPI_Rewrite_32 and ISAPI_Rewrite_x64:

Installer also adds ISAPI_Rewrite proxy dlls (both x86 and x64) into the list of ISAPI and CGI restrictions

and marks them as Allowed.

That’s all that is done by installer or (in a rare case when it fails) by you:) Now you may test ISAPI_Rewrite operation using this simple rule:

RewriteRule .? – [G]

Save the config and make request to any page on your site. “Gone” result will evidence successful installation:

Now let’s turn on 32-bit applications compatibility mode (if you need to).
Click on the Application Pools node in IIS Manager:

And go to Advanced Settings of DefaultAppPool:

Set “Enable 32-Bit Applications” parameter to True:

And test if ISAPI_Rewrite still works with the same rule and URL you used above. The result should be just the same:

We find it quite helpful to know what’s happening behind the scenes. And hope you also do.
Take care.

Regards,
HeliconTech Team

This story may be used for two purposes:
1) to learn what’s happening to your system when ISAPI_Rewrite is being installed;
2) to follow the steps outlined in the article to make sure ISAPI_Rewrite was installed correctly (in case you have any concerns or something is not working as expected).

If you already have strong desire to install ISAPI_Rewrite, firstly, please check if your IIS Server contains all required components, especially those stressed on the picture:

If it’s OK, it’s high time to download and install the latest build of ISAPI_Rewrite x64 available on our site.
After that make sure ISAPI_Rewrite is registered in IIS. To accomplish this:

• open IIS Manager
• open Handler Mappings snap-in
  
• Check if required handlers are there
  
• open ISAPI Filters snap-in
  
• Check if required filters were added (see the pic)
  
• Open ISAPI and CGI restrictions snap-in
  
• Check if required restrictions were added and set as Allowed
  

Now launch ISAPI_Rewrite Manager and write the following test rule in httpd.conf:

RewriteRule .? – [G]

Make request to any resource you can think of to check if ISAPI_Rewrite works fine.

If the result resembles the one above (410 Gone page), ISAPI_Rewrite operates correctly.

Now we will turn on 32-bit applications compatibility and check if everything is still working great:

• open IIS Manager
• go to Application Pools
• choose DefaultAppPool and Advanced Settings


• Set “Enable 32-Bit Applications” parameter to True
  
• Now check ISAPI_Rewrite operation once again by making some request in the browser
  

The result should be the same as before (410 Gone). This means that ISAPI_Rewrite works just fine in 32-bit compatibility mode.

We’ve tried to be as explicit and clear as possible and hope this tour around your server’s settings will help you some day.

Regards,
HeliconTech Team

Upon the first request IIS loads modules and if the module has a digital signature (according to certification requirements for Windows Server 2008 all dll and exe files must have one!), Windows addresses the trusted center (in our case it’s Verisign). This happens only once, after that certificate is marked as valid.

If Windows fails to receive response from Verisign, it retries a couple of times (up to 10) and after that continues to load the application.

Side-effects:
Upon the first request (and after each App pool(s) recycling!) the delay up to 10 seconds may occur.

Workarounds:

• Change the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State from 0x00023c00 to 0x00023e00 for the user(s) whose account is used in the app pool(s) to say Windows not to check certificates
• create the file “c:\windows\system32\inetsrv\w3wp.exe.config” with the following content:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <runtime>
      <generatePublisherEvidence enabled="false"/>
    </runtime>
  </configuration>

• allow access to Verisign for a little while.

Microsoft addresses this issue in its article http://support.microsoft.com/kb/936707.

You may never notice such behavior, but if you do, you are already aware of its cause and solutions:)