This article describes a fix to IIS7 configuration that will allow PHP 5.x to run on a Windows domain controller. The problem was first described in this article here.
The fix also affects the operation of Windows Server Update Services, if you have it in operation on the same server. The issue for PHP is that as a 32 bit application you have to tell IIS7 to allow 32 bit apps to run, and then you run into a problem with the DynamicCompressionModule when the 500.19 error is flagged.
Because WSUS relies on the self-update tree of the default web site on port 80 to deploy self updates to clients, even if you are using port 8530 for your WSUS site, the 500.19 error will stop the self update feature of WSUS working for your clients. You will see many requests logged by IIS looking for the self-update tree that all return 500.19 (“500 19” in the log itself).
The resolution is to disable the Dynamic Compression handler as described in this article. Now, I found by reading here, apparently this module handler is installed by WSUS. So I suspect that an ordinary DC would not have a problem running PHP. And a DC running WSUS by itself would not have a problem. It is because we want to run a 32 bit application like PHP on the web server that it conflicts with WSUS and causes this situation to happen when we switch the setting to enable PHP to run.
UPDATE: If you install WSUS 3.0 Service Pack 2, it will rebuild your database, and change the settings on your server to re-enable Dynamic Compression handling, if this was disabled as described above. I have just installed this update, and lo, the same issue is occurring. This time around, I just turned off 32 bit application support in DefaultAppPool to resolve the issue, as I’m not now expecting to use PHP on this web server for the time being. See the first referenced link at the top of this article for details on that setting.