locked
Strange Behavior with Handler Mappings RRS feed

  • Question

  • User615295471 posted

    I'm running Plesk with IIS 7.5. Plesk doesn't support anything over 5.3 for PHP so I had to add it via the handler mappings which was working perfectly.

    The websites went down this morning literally as I was working on them so I thought it was me. After hours of debugging, I've just noticed that the PHP version in the IIS handler mappings section has reverted back to the default (PHP5). There's only me with access to the server.

    I really haven't got a clue how it happened or what steps I need to take to prevent this happening again.

    As it stands, I've suspended the 2 domains I have running 5.8 while I get this issue sorted. I'm really not sure what to do as I know Plesk won't help as they don't support 5.5.8.

    Monday, March 10, 2014 12:08 PM

All replies

  • User690216013 posted

    It is rather hard to say "only me with access to the server". You might have to enable IIS auditing and then next time you might learn who makes the changes,

    http://blogs.msdn.com/b/webtopics/archive/2010/03/19/iis-7-5-how-to-enable-iis-configuration-auditing.aspx

    BTW, PHP 5.3 is expiring in only a few months (this July),

    http://en.wikipedia.org/wiki/PHP

    So if Plesk won't support the newer PHP releases, you will have to migrate to another platform to avoid issues.

    Tuesday, March 11, 2014 2:44 AM
  • User615295471 posted

    Thanks, I've enabled that feature although I'm not sure what difference that will make as I know I didn't change the handler mappings yesterday and nobody else has access to the server other than me.

    IIS was running with PHP5 (Not PHP5.3) by default, obviously this is outdated. Plesk only supports upto 5.3 so I couldn't change this via the Plesk panel but to change it via the IIS handler mappings.

    The strange thing is, is that I completely removed any/all versions of PHP and added PHP5.5.8. Now yesterday, I'm writing a test PHP script that worked fine. A couple of hours later (hadn't even logged into the server remotely to do anything) the 2 domains that I were working on were not working and was due to PHP running 5.

    Is there anything that would make it revert to default settings? I know I now have that log enabled, but what do I do just sit and wait for the websites to fail again? 

    I'll speak to Fasthosts about possibly switching from Plesk as I've had nothing but issues with it, and if they can't be bothered to keep up with the latest versions of PHP then I shouldn't bother with them.

    Tuesday, March 11, 2014 5:14 AM
  • User1183424175 posted

    Hi,

    You can try configuring the php version via command line:

    %windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI ^  
    /+[fullPath='c:\php531\php-cgi.exe']  
    

    For more information, you can refer here

    http://ruslany.net/2009/12/multiple-php-versions-on-the-same-iis-server/

    #iis manager UI

    http://blogs.msdn.com/b/brian_swan/archive/2010/08/30/managing-multiple-php-versions-with-php-manager-for-iis-7.aspx?Redirected=true

    Hope it can help you.

    Tuesday, March 18, 2014 3:48 AM
  • User615295471 posted

    Thank you.

    I can confirm that this has happened again. It's completely removed all versions of PHP other than PHP5-FastCGI. 

    I set up the logging in event viewer under Applications and Service Logs -> Microsoft -> Windows -> IIS-Configuration but I really don't know what I'm looking for.

    Please help.

    [EDIT TO ADD]

    I found the entry that made the change. I installed Google Sitemap Generator. Why on earth would this change the PHP handler mapping on IIS? Is there anything I can do to stop this happening in future? Here is the log:

    - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    - <System>
      <Provider Name="Microsoft-Windows-IIS-Configuration" Guid="{DC0B8E51-4863-407A-BC3C-1B479B2978AC}" /> 
      <EventID>29</EventID> 
      <Version>0</Version> 
      <Level>5</Level> 
      <Task>0</Task> 
      <Opcode>0</Opcode> 
      <Keywords>0x4000000000000000</Keywords> 
      <TimeCreated SystemTime="2014-03-18T10:16:53.101757800Z" /> 
      <EventRecordID>3086</EventRecordID> 
      <Correlation /> 
      <Execution ProcessID="5932" ThreadID="6260" /> 
      <Channel>Microsoft-IIS-Configuration/Operational</Channel> 
      <Computer>DSVR017177</Computer> 
      <Security UserID="S-1-5-21-455497440-3941878070-1858641177-500" /> 
      </System>
    - <EventData>
      <Data Name="PhysicalPath">\\?\C:\Windows\system32\inetsrv\config\applicationHost.config</Data> 
      <Data Name="ConfigPath">MACHINE/WEBROOT/APPHOST</Data> 
      <Data Name="EffectiveLocationPath">Google Sitemap Generator Admin Console</Data> 
      <Data Name="Configuration">/system.webServer/handlers/add[@name="CGI-exe"]/@modules</Data> 
      <Data Name="EditOperationType">1</Data> 
      <Data Name="OldValue">ManagedPipelineHandler</Data> 
      <Data Name="NewValue">CgiModule</Data> 
      </EventData>
      </Event>

    Tuesday, March 18, 2014 9:05 AM
  • User-1731511703 posted

    Are you setting the Handler Mappings at the site level?  If so, those changes are being set in the web site's web.config file.  If anybody uploads a new copy to the server it will overwrite any previous changes that were made for the site and not synced with the offline copy.

    Tuesday, March 18, 2014 9:24 AM
  • User615295471 posted

    Thanks for your reply. I set it up on IIS via the Handler Mappings Module but on 2 individual domains. Would this still cause a sync issue? If so, I don't understand why there would even be a handler mapping module on the site level? Sorry if my question is a little dumb, still learning my way.

    [EDIT]

    Now that you mention it, I deleted the web.config file earlier on whilest doing a cleanup. To test whether it was me or the installation of Google Sitemap Tool, do you recommend tracing back my steps to try and replicate the issue to confirm exactly what caused the problem?

    Thanks.

    Tuesday, March 18, 2014 9:33 AM