IIS7.5

3 articles in category IIS7.5 / Subscribe

I recently stumbled upon a PHP page that keeps timing out, even after increasing the activityTimeout value in IIS7.5. The error message was “The FastCGI process exceeded configured activity timeout”. This leads me to writing this how to. If you are not interested in installing PHP, you can jump right to bullet point 7.3 and on.

If you are using IIS7 or 7.5, the best practice recommended by Microsoft is to use the Web Platform Installer(WPI). While this makes installation quick and easy, it really lack an option I desperately need. It never asked me where to store the PHP installation. It assume I want to install it under <%system%>\Program Files\PHP. What if I can NOT or do NOT want to store it in that folder??

NOTE: <%system%> is the drive letter where you install your Windows Operating System to.

The easiest way is to let WPI install it, and we’ll just worry about modifying the installation.

  1. Install PHP using WPI
  2. Stop your web server(IIS)
  3. Move the PHP folder from <%System%>/Program Files to any Location you wish. For this example, I’m moving it to E:\, so that my PHP installation is in E:\PHP
  4. Change your environment(system) variable(Right click on computer, Properties, Advanced system settings, Advanced tab, Environment variables). If you can’t find any entry that points to the default PHP install location, you can skip this step.
    • Double Click on Path, and change every reference to <%System%>/Program Files/PHP to E:\PHP
    • Double click on PHPRC, and do the same thing
    • If you see anything else that refers to <%System%>/Program Files/PHP, change them all to E:\PHP.
    • Environment Variables

      Environment Variables

  5. Change your php.ini settings. Locate your php.ini file and look for <%System%>/Program Files/PHP entry. Change them all to E:\PHP.
  6. Now you need to tell IIS to use the PHP executable from a different location(as opposed to from <%System%>/Program Files/PHP) to process PHP file request.
    • Launch your IIS manager, and click on the ROOT entry just right under Start Page.
    • Double click on Handler Mappings, and locate *.php entry under Path. If you are using WPI, there should be an entry called PHP_via_FastCGI
    • Handler Mappings

      Handler Mappings

    • Double click on it, and change the executable path to use the PHP-CGI.exe file in E:\PHP\
    • If you have sites defined, make sure you check the module settings for each site. Changing the root should take care all the Sites, but it never hurts to double check
  7. Change your IIS configuration. You can either use the IIS admin pack(built in in IIS7.5), or you can edit the configuration file directly.
    1. Open C:\Windows\System32\inetsrv\config\applicationHost.config file with a notepad
    2. Look for <%system%>/Program Files/PHP entry, and change them all to E:\PHP
    3. locate <fastCgi> tag. Make sure you only have one <application> tag defined for your PHP installation. If you are seeing two <application> tag entry for PHP, remove the one that contains less text, and make sure the one that stays has a fullPath attribute of E:\PHP\php-cgi.exe(or whatever your path is).

What happened to me prior to this post was, I did all the steps through steps 6, but i didn’t do step 7. A web developer was complaining that his debugger keep timing out after 70 or so seconds. I set the timeout period to a lot more than 72 seconds, but it didn’t seem to take it. I found out that the application path is still pointing to the default installation of PHP in <%system%>/Program Files, and there are 2 <application> tag entries for PHP installation. The first one was the default installation entry, the second was the custom path entry(in E:\PHP). I changed the activityTimeout property of the first <application> tag entry. No wonder it didn’t work the first time I tried it. After deleting the second entry, and modifying the first one, the debugger session stays longer than 72 seconds, and my web developer is back to happy zone again :)

I recently migrated 2 of our Windows 2000 Box to WIndows 2008 R2, running IIS7.5. One day one of our web developers was reporting that changes that he made on his PHP files will not display right away on a web browser. There is about 15-30 seconds delay between right after he hit CTRL-S(to save) the php file and when the changes appear on a web page. This can be very annoying when you are debugging codes.

I need to make sure that this is not a browser problem. So, I:

  • had 2 browsers(IE and chrome) opened up with cleared private data(cache, cookies, and all the good stuff).
  • ran the php page on chrome
  • edit the php page and save
  • refreshed chrome….. changes are not displayed
  • immediately run the same php page on IE, which still has cleared private data and still hasn’t been used for browsing anything. Changes are still not appearing.

I then waited for about 25 seconds, and refresh both browsers, and immediately see the changes. I know this has got to be server settings.

First thing that comes in mind is WinCache extension for PHP. Which is recommended by Microsoft to speed PHP execution. After looking at the documentation for this extension, it sounds like the wincache.chkinterval setting is the culprit. The documentation mentioned that this can be changed in PHP.INI. The default settings is 30 seconds, which makes me more suspicious of this entry.

So I added the following entry under Module Settings in my php.ini file, which change the check interval settings to 1 second, instead of 30:

;;;;;;;;;;;;;;;;;;;
; Module Settings ;
;;;;;;;;;;;;;;;;;;;
[WINCACHE]
wincache.chkinterval = 1

After IIS apply the settings, that seems to have fix it. My colleague is back to happy zone again :)

I’ve been scouring the web(and pulling out my hair) for two days, and finally solve my problem, and finally get it to work. I thought I’ll share it with people out there who is still pulling their hair.

Ok. so I have some classic ASP pages that i want to migrate from IIS5 running windows 2000 to the coolest dandiest server OS from Microsoft. Here is the catch…. I’ve got some ASP pages that are still pulling out data from access database written in access 2000, and 2003. All of which are 32 bit version.

First thing first.

  1. MAKE SURE you configure your IIS right. You need to install a specific set of rules to enable classic ASP support. Read it Here.
  2. I don’t know about you, but I want my classic ASP to have its own Application Pool, separated from all my .NET stuff. So I created an application pool for all of my classic ASP page(of course you can create more than one if you want). This is what you need when you create an application pool(if you don’t know how to create application pool using IIS7, google it up).

    Name:
    Whatever you want.(I call mine Classic ASP)
    .NET Framework version: No Managed Code
    Managed pipeline mode: Classic.

    After you are done. Go to advanced setting of your Application Pool, and make sure the identity is set to ApplicationPoolIdentity. This is the default behavior for 2008 R2, but from my experience this past several days, I saw screen shot that is set to something else.

    If you’ve been researching, you’ll find out that a lot of people out there ask you to set the Enable 32-Bit Applications to True for you to enable the Jet Engine or the ODBC to interact with Access Database. In my experience, this is NOT necessary. I’m not saying that they are wrong.

  3. If your ASP pages is on a virtual directory(subdirectory within your root, NOT on your root directory), go ahead and convert that virtual directory to application(right click convert), AND select the application pool you just created in step 2 above.
  4. This is the most important thing. CREATE A HANDLER MAPPING for your *.asp page. I’ve read a lot of people complaining about getting 404 or 500 error because they did not set this up right. Double click on the virtual directory you just converted to application on step 3 above, and click handler Mappings. You need to add a SCRIPT MAP.

    This is where it gets tricky, and I do not find this mentioned anywhere but this blog, which I found really helpful. You need to decide first whether you want to run your ASP in 32 BIT or 64 BIT. A lot of posters out there tell you to enable 32 BIT setting in your application pool, but they did not tell you how to change the ASP handler to use the 32BIT version of the handler’s executable. I repeat, you do NOT need to set your application pool to enable 32bit.

    Add a script map using the following setting:

  5. Request Path: *.asp
    Executable: C:\Windows\system32\inetsrv\asp.dll
    Name: whatever you want. I named my Classic ASP

    The executable above is 64 BIT ASP handler for your asp script. If you want your ASP script to be handled in 32 bit environment, you need to use executable from this location: C:\Windows\SysWOW64\inetsrv\asp.dll.

    From my experience. if I use the 64bit version of the executable(as a lot of posters recommend), and set the application pool to enable 32BIT……. YOU WILL GET 404.17 error. Similar thing hapen(maybe different IIS error code) if you are using the 32 bit version, but do not enable the 32bit setting.


    In my opinion, if everything else works in 64 bit environment(which in my case it does), I don’t want to make anything run in 32bit unless i have to.The hardware and the OS is 64 bit. If the software can also run in 64 bit, why bother to change to 32? So, I use the 64bit executable.

  6. Test your configuration. Create a simple test.asp file in the virtual directory you just converted to Application in step 3 above, with just <%Response.Write(“test”)%> in it. See if it runs okay. It should. If it doesn’t, and it’s giving you error that complains about parent path, double click on the virtual directory you just converted to application in step 3 above, and double click on the ASP icon in features view. Set the enable parent path to true. While you are at it, under the debugging properties, set send error to browsers to TRUE, so you don’t have to hang yourself later trying to figure out what’s wrong with this world(or IIS). If you are using IE as your browser, make sure to turn off “Show friendly HTTP error messages” so that you can see the actual error(Internet Options, Advanced).

    At this point your ASP page should work fine. If not, make sure you do all the above steps right. If you are still getting an asp error, make sure you comment out “on error resume next” statement in your code. If the error message doesn’t help you, try to enable failed request tracing to understand what the error is about(google it up to find out how to set this up).

    Your ACCESS database is still crapping out at this point. You can hang yourself(like I almost did). OR…. if that’s not an option, do this….

  7. Install your Access database provider.Older access version uses JET.OLEDB 4.0 provider so that other application(such as ASP) can read and write data to it. This provider is 32BIT, and there is NO 64bit JET Engine. I repeat… NONE. I’ve seen suggestion that ask you to enable the 32bit support in your application pool, so you could get the JET engine to work. However I could never get this to work. HECK, the jet engine is not even registered on my server. I checked the registry entry, and there is no entry for for JET OLEDB provider. I don’t know how in some forum people get it to work, but I definitely can not get mine to work in IIS7.5 and 2008R2 environment.

    You do NOT need a Jet Engine. Even if you can get it to work……… DON’T use it. Microsoft never support Jet running under server 2008. Use Microsoft Access Database Engine 2010 Redistributable. This is a key to the magic kingdom(wherever that is). Download the 64 BIT version, and install it. Restart it after you install(most likely you don’t have to, but if you feel safer that way…. go ahead do it, and pull yourself together, don’t get up on that chair and hang yourself just yet).

  8. Change the connection string in your ASP page to
    “Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=path to mdb/accdb file”
    example:
    connstr = “Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=” & server.mappath(“../..”) & “\databases\list.mdb”

  9. Buy yourself a case of Bud Light. At this point your ASP pages should be talking to your Access database and displaying on a web browser. If it is still not working…….. well, get that chair ready. I’m not sure what else could be the problem.

If I’m missing any step, please post a correction. Hope this helps someone