IIS5.0 & PHP4.05 Pages now scripts

Anon

OK Long Story Short.. to many hands on keyboards - some know not with what they play.

@ 2:30am Aust EST I had a fully function PHP site with no error

@ 1:30pm I ended up with an IIS script error and PHP that loads as a script in the frame rather than a page..
I have reregistered the DLL's I have re-applied the path to php.exe I have included the following the home directory app's register of the Inet "server root" .php = (path)php.exe %s %s

I have not enabled the ISAPI filter as we are using php in CGI mode.
restarted & have reboot Webserver
No joy.. (Not a PHP programmer myself and in-need of the good oil on the best way to fix this problem (please dont tell me to go and get a php expert as I have made several calls and NO One wanted to touch the problem))
Thanking you in advance for your advice
Paul.

Anon

Try these solutions:

Check the web site or virtual directory of the web application. Verify in the IIS that the web application must "Execute" scripts. Be warned that you might introduce potential security breaches though.
The directory where the web pages, script, and modules must have the approapriate access rights to browse. Identify the default internet user account (or guest account or whatever) and set the proper rights. You may check the "Modify" rights, but you are strongly recommended NOT to check the "Full Control" rights.
Check your Transaction Coordinator for any settings that adversely affect your application. I'm not yet used using this, but I have a feeling that a setting or two would solve the dilemma you're facing.

Anon

Thanks Alvin..I'll double check the user rights and access privialges..
As for the transaction co-ordinator I am not 100% as to what you are refering to.;-P

Anon

it seems that the FrontPage server extensions had applied additional
security to the iwam_user account (anonymous user account) even though the
lowest possible security settings were applied at the IIS MMC Snap-in level
the registry Sam account had to be edited a simple security level glitch was
caused by a totally different/devoid application configuration setting.
After the above was corrected the mime settings and application mapping..
all had to be removed (I am still scratching head about this and will
investigate further as to why)
as everything I have read in the passed 12 hours this webserver should
not parse .php files under any circumstances as it isn't configured to do so, nor is
the application mapped,directed or otherwise to do so.
Thanks for you thoughts earlier, it's appreciated ; -)
Paul