After looking into this in more detail I’m starting to think the reason for the problems is trying to install onto a domain controller. There are so many instances where people have had no trouble at all with just basic steps, all the steps I did, getting PHP (even just the 32 bit release) working on x64 WS2008 IIS7.
One of the issues with a DC is joining a WS2003 domain which we have because the other DC, which at the moment holds all the master roles, is a WS2003 DC. This causes problems with the IIS_IUSRS accounts / groups that IIS makes use of. In any case, I want to provide access to Moodle from offsite, and so it makes sense to look at running it on the gateway server for our site, which will be accessible externally by default, rather than providing a connection through this server to another server on our site. Another possible hiccup is that this server is a WSUS server. That means WSUS makes use of the default website on port 8530 to serve some of its update files (specifically selfupdate). This shouldn’t affect the default web site, but it could nevertheless produce unintended consequences.
The next step I plan is to try PHP by itself on a test WS2008 server I have around here that is just a member server and not a DC (and has not ever been a DC either). If that works, I’ll change my deployment plan and put Moodle onto the gateway server instead. I’m still planning to use Postgresql on this box, but as a standalone database server for some specific applications using ODBC (hopefully).
WELL: I was surprised at how simple and quick this was. Literally within half an hour of posting this message, I have PHP running on a WS2008 x64 IIS7 server. The key steps being (refer to the original posts for details):
-
Run the installer and select the IIS ISAPI module option in the installation
-
Configure IIS7 with the HandlerMapping. Also, make sure you view the list of HandlerMappings as an ordered list, and that the entry for PHP files appears higher than any handler which uses * as the filetype. When I put in the PHP ISAPI mapping, it automatically appeared at the top of the list so no problem there.
-
Configure the ISAPI / CGI restriction entry.
-
Change the settings for the Application Pool for your website. In my case, using the default website, I am using the DefaultAppPool, allowing 32 bit applications to run.
And that’s it. Without any PHP configuration whatsoever, a phpinfo call comes up as expected. Voila.
However, I’m not 100% convinced there are not going to be more problems on the gateway server. This x86/x64 compatibility is a real bugbear. I think that I have to stick with x86 for compatibility with Postgresql, which is not yet available as a x64 Windows build. But the server has to be x64, and it’s going to have all of this other stuff running on it in native x64 mode, like Exchange, ISA and TSGS. We are just going to have to see what that will do when it’s all set up. I’m also still trying to debug the problem in the DC, which should be easy to do if I can get failed request tracing working and having a bit more playing with the permissions. At the moment I am not going to do any more Moodle installation until I have got the new server and set up stuff on it. The real question here is whether setting the AppPool to enable 32 bit will stop 64 bit apps working. Hopefully IIS will allow this to be set on a per-pool basis and then I can set up a custom app pool for PHP.