After Installing PHP 5 using the Windows installer on Windows 2003 you may find that IIS displays a “Page Not Found” 404 error for every .php page. This is a perplexing error because is it not actually a real 404 error. The file is really there, but IIS is unable to process it based on how the installer configures the extension mapping. Instead of providing any useful information or even a 500 error; however, IIS throws out a 404.

Steps to Fix the Problem:

Before you troubleshoot further, you may want to read #4 about how the Application Pool effects PHP configuration changes.

1. Replace the old DOS format path to the PHP Executable with a full path w/ quotes
2. Move php.ini to C:\Windows
3. Edit php.ini to set cgi.force_redirect = 0 (possibly not necessary)
4. Recycle the Application Pool

1. Replace the old DOS Path Format

The default path to PHP is C:\Program Files\PHP. When creating the IIS extention mapping, the PHP Installer uses the old DOS format path to the PHP ISAPI or CGI executable such as “C:\PROGRA~1\PHP\PHP5IS~1.DLL”. IIS does not seem to like this format. To fix the problem, go to the IIS Extension Mapping screen and locate the value for “.php” (See screenshot above). Click the browse button, select the executable and put quotes around it the entire path. So the value for this field should look like this “C:\Program Files\PHP\php5isapi.dll” (WITH the quotes around it). If you have installed PHP in CGI mode instead, the file name would be php-cgi.exe instead of php5isapi.dll

While you’re at it you may want to check the box for “Verify that file exists” as well. This allows IIS to handle actual missing pages (ie broken links) and return a 404. Otherwise IIS will just pass the request to PHP without verifying the .php file really exists and PHP throws a CGI error when the file isn’t found. People seem to have inconsistent results with this setting.

If you recycle the app pool at this point (see step #4) you *may* solve the 404 error depending on what extensions you installed or whether you had re-run the installer and changed stuff. However, you may still have issues changing php.ini settings in which case keep reading.

2. Copy php.ini to C:\Windows

The PHP installer creates a php.ini file for you based on your selections in the setup process. However the installer saves the file in C:\Program Files\PHP. The problem is that PHP is looking in C:\Windows for the .ini file. So, you need to move the file php.ini to C:\Windows. This may be confusing because PHP seems to run fine. But if you look closely at the phpinfo() output, you may find that php.ini file is not being loaded and all default settings are being used.

One of the critical things when configuring PHP is to actually edit the .ini file that is being used by PHP. The installer creates a worthless file in a location that PHP won’t read and so you may waste a lot of time editing this file. PHP pretty much universally will check the Windows folder for php.ini on all varieties of Windows, so my advice is to use that location and delete any other php.ini files that are hanging around..

3. Set cgi.force_redirect = 0 (Optional..?)

Some people report that you need to edit php.in, un-comment the cgi.force_redirect parameter and change the value like so:

cgi.force_redirect = 0

I have not found this to make any difference, but your mileage may vary. Obviously make sure #2 is straight first and that you are editing php.ini in the correct location so that your changes take effect.

4. Recycle the Application Pool

In order for any PHP configuration changes to take effect in Windows 2003, you need to recycle the Application Pool. If you have made changes to php.ini and they don’t seem to take effect, this is likely the reason. Among other things, the pool caches PHP settings and you need to clear it before new configuration settings will take effect. You’ll read people telling you to restart IIS (which doesn’t recycle the app pool) or even reboot your machine (which is overkill). You don’t need to do either of those. Just right-click on the DefaultAppPool in the IIS management interface and “Recycle” is one of the options.

If I’m having trouble with the ini file, I like to have a typical phpinfo.php file on the server while I make some arbitrary change to the php.ini file (like the session timeout or the max upload size). I refresh phpinfo.php and verify that my changes are taking effect. You can also check the Windows Event logs under “System” which will sometimes report errors in the php.ini file.

Notes regarding re-running the PHP installer to make changes:

The PHP installer does not really handle changes all that well. For one thing it will overwrite the path to the PHP executable w/ the old DOS format so you need to fix that after you run it.

The 2nd thing is that it will write changes to C:\Program Files\PHP\php.ini - regardless of the fact that PHP is actually looking at C:\Windows\php.ini

If you had previously moved php.ini to the windows folder, when you run the Change installation feature, it will create a fresh php.ini file that only incorporates the most recent changes. (ie, if you had 10 extensions enabled and you make a change to enable 1 more, your new php.ini file will only have the 1 enabled and the previous 10 will no longer be enabled)

One way around this is to temporarily move C:\Windows\php.ini file to C:\Program Files\PHP. Then run in installer to make changes. The installer will write changes to php.ini in that location. Then, move php.ini back to C:\Windows.

Share This

I recently had to rescue a legacy application that was running on an old Compaq Proliant server. This custom application is primarily a web application running on MS SQL Server, however there are various services and automated tasks and the application is fairly well embedded onto this hardware. The application has gone through various changes and development teams since it was originally written in 1997, but has always lived on this particular Windows NT 4.0 Server.

The machine itself is huge, heavy and requires three power cords to run. It’s also extremely loud. Though it was a mighty workhorse in it’s day, now there are cellphones and PDAs that would give it’s CPU a run for it’s money. I thought the hardware was so old that it would make sense to migrate the whole thing to a virtual disk image and run in using Parallels. What I had thought would only take an hour or two wound up being an entire weekend saga. But end the end I was victorious and the virtual server now runs like a champ on my Mac Mini. What follows are the steps and software tools that I used to make the migration.

Note: if you are using an Windows OS more recent than NT, you can use Parallels Transporter to easily convert an older server into a virtual machine. The technique below is much more labor, however will work on older Windows systems and, theoretically, any other OS. Also, I suspect these steps could be followed for use with another emulator such as VMWare or VirtualBox.

The first step of the process was to make a disk image of the drive. This actually can be done using a variety of GUI utilities if you can physically remove the drive and place it into another machine. In my case the two disk volumes were spread across 4 physical disks on an old Compaq RAID array. Not to mention they were old SCSI drives and I didn’t have the hardware to plug them into another machine anyway. What I did find was a nice little app called G4U (Ghost for Linux)

G4U basically did all of the hard work, but it didn’t quite get me all the way home. Following the G4U instructions I created a boot disk CD and booted the old hardward. G4U is a command-line utility with a command uploaddisk. This command basically converts the drive of your choosing to a raw image file and simultaneously uploads it to the FTP server of your choosing. I did this using a local FTP server and the result was a .gz file containing the raw disk image.

Now that I had the disk image the next step is to get the data out of that image and into a Parallels virtual machine. I created a Parallels virtual machine with a blank virtual drive the same size as the old server drive (actually I made it a little bigger to be safe). I then booted up this virtual machine as if I was going to install Windows, only I booted from the G4U boot disk. At the G4U prompt the command slurpdisk connects to an FTP server, decompresses the raw .gz image file to a physical drive. (In my case, I copied it to the new, blank virtual drive.)

Once this step was complete I had what should have been an exact copy of the drive from the hardware duplicated on a parallels .hdd drive file. And indeed I did have this; however, there was a problem - it wouldn’t boot! Apparently something with the old RAID controller or the conversion process had not correctly copied the boot sector. I could mount the disk image and see that all the data was there but Parallels would just not recognize the drive as being a bootable image.

I know there are ways to fix the boot sector using special fdisk options, however they tend to wipe out the data - which obviously wouldn’t work. There’s probably non-destructive ways as well. What I wound up doing, though, was to create a new Parallels machine with a new/blank drive and install on it a fresh copy of Windows NT. In other words, I basically created a regular virtual machine running Windows NT. (In hindsight I probably could have just copied any existing virtual machine that I had)

So at this point I had a) A virtual drive copy of the old hardware drive that was non-bootable and b) A clean NT virtual machine that was bootable. I needed to get the files from A onto B. I figured a straight copy using windows explorer would wipe out critical NTFS system data, but I couldn’t copy the whole partition either and lose the boot sector info. I located another free utility program called XXCOPY which promised to copy NTFS files as-is preserving all system meta-data. (Vista has a new feature called RoboCopy which may also work for this purpose.) I mounted both disk images on my main XP installation so I would work with the filesystems. I deleted all of the NT files from the clean install using Windows Explorer, thus I have a blank, but bootable drive. Then using XXCOPY I copied the old serer’s entire C drive contents to the blank, bootable drive.

To be honest, I wasn’t expecting this to work. The copy took a while, but after I was done I booted up from that drive and to my amazement it started! It took a lot of trial and error, but in the end the application was liberated from it’s old hardware and now runs happily on any decent computer with Parallels installed.

Share This

Recently an old application server arrived at the office. The server was running NT 4 and MS SQL server. We needed to get the machine running to do some reverse engineering of the code and database, however the administrator password had been lost. The original developer had moved out of state and didn’t have records, nor did the owner. It seemed that the only choice left was to hack into the machine.

I started with various failed attempts to recover the password using boot disks that grab info from the SAM database and crack the passwords. Since this was older hardware with an old drive array configuration, though, several of these recovery disks couldn’t recognize the drive. One program did see the drive and recover the SAM information but was unable to crack the password.

I do think that strategy would have eventually worked. But, I decided it would be easier to re-set the password instead of recovering it. There is an old trick with NT and 2000 machines if you have physical access the the machine where you replace login.scr with cmd.exe.

First you boot from an NTFS boot disk. The NTFS boot disk above gives you a windows DOS prompt with full read/write access to the drives on the server, though you are not technically authenticated as a user on the system.  C:\winnt\system32\login.scr is the screensaver executable that Windows runs automatically at the login prompt. You can use this hack to fool Windows into opening up a DOS shell with system priviledges. At the boot disk command prompt enter the following to backup and replace login.scr with cmd.exe:


copy c:\winnt\system32\login.scr login.bak
copy c:\winnt\system32\cmd.exe login.scr


Now that login.scr was replaced, remove the boot disk and re-boot to the NT login prompt. I waited until Windows launched login.scr (default is 15 minutes) and a DOS command window opened right on top of the login prompt. The following DOS command changes the Administrator password:


net user Administrator mynewpass


The password is now changed. Finally, I gave the old Microsoft 3-finger salute (ctrl+alt+del) and logged on using the username/password I just created. Woot!

WARNING: If this is a domain controller or using active directory, I have read that this trick is not advisable and may cause you some file permission headaches.

Share This