Blogs‎ > ‎

Late Night Plesk 11.5 to 12.5 Upgrade. And the Morning After...

posted 17 Jan 2016, 11:39 by Andrew at Lycom   [ updated 17 Jan 2016, 11:40 ]
Most sysadmins hate upgrades. I mean, they really hate them. Things break. Stuff that should just keep on working doesn't. But you can't not do it - life is about security updates now; products move on and have new requirements.

I had to look at a Plesk 11.5 setup that has been working pretty well. But the PHP versions were stuck in the dark ages, and that was starting to impact on some projects.   So, I reviewed the Parallels doc on choosing upgrade strategy:

and decided to go ahead with an upgrade to Plesk 12.5.  I read the bit about checking where your db is

mysql. OK, good.

Then used the guide:

and also

I kicked off the upgrade from being RDP'd into the server one night. All seemed to go well until I realised it wasn't doing much, eventually I spotted the 'pop-up' window that hadn't 'popped-up':

The following services require a system restart:
 Component-Based Servicing pending restart
 Restart the system before continuing installation.

Rebooted and restarted the upgrade

Plesk pre-upgrade checking...

WARNING: After upgrade you have to add write pemissions to psacln group on folder C:\inetpub\mailroot\pickup. Please, check for more details.

And then it carried on with the upgrade, and on, and ... until I got worried and searched some more:

This is the useful bit:

Open autoinstaller.log in C:\ParallelsInstaller and scroll down to the end. Last line will show you the action that is currently running.

  1. SI: Action 18:22:52: Applying security. Applying security for D:\Plesk\
  2. If there a lot of files in Plesk directory. For example, customer may put vhosts directory under Plesk installation directory or there is a lot of mails saved on the server. In this case Applysecurity.exe will check all files in Plesk installation directory. If there are a lot of domains and files in vhosts folder, it may takes a lot of time for completing the task.
And they are not kidding -  applying security permissions took for ever. This was quite a well used hosting server with a lot of files - don't underestimate just how long this will take.

Anyway, eventually it completed and all seemed well - Plesk interface loaded fine, IIS sites were up and a random selection of websites could be browsed. Job done. Go to bed.

The Next Morning.

Never good when you get txts while eating your breakfast. What isn't in the Plesk documentation is any warning of the number of things that might go awry during the upgrade. Here's my list from today's experience:

  1. Various IIS sites start asking for authentication (Authentication Required error 401). Nice.  Turns out there's a Plesk tool that fixes this

    But more specifically:
    Run the following command:
    "%plesk_cli%\repair.exe" --reconfigure-web-site -web-site-name
    Then perform the following command to re-create NTFS permissions for additional FTP-accounts (if any):
    "%plesk_cli%\repair.exe" --reconfigure-ftp-site -web-site-name

  2. PHP Hell.

    Remember that time the upgrade spent applying permissions? Some of those may well break your installs. Check things like permissions on the PHP sessions dir (e.g. c:\windows\temp) for the psacln group. Verify the ACLS on the httpdocs dir for problem sites. Getting lots of 'Internal Server Error 500' messages? Probably 'FASTCGI_UNEXPECTED_EXIT' errors:


    HTTP Error 500.0 - Internal Server Error

    C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\php-cgi.exe - The FastCGI process exited unexpectedly

    IIS will return a generic Internal Server Error 500 if it doesn't have any more specific error from the application, in this case PHP/FastCGI.

    To provide IIS with all necessary php error information and NOT display the generic Internal Server Error, do the following to your php.ini file:

    log_errors = off

    To ensure PHP error messages do make it to the web page do this:

    display_errors = on

    The level of PHP error reporting can be controlled by (more about this at ):

    error_reporting = E_ALL & ~E_NOTICEAnd this should give you clues on where to go next.  I found several sites which had deprecated PHP code elements - moving up to a supported PHP version (now I had lots of versions to choose from in Plesk 12.5) helped to resolve most of those.

  3. File Manager zip extracting fails.

    Find that 7-zip directory and give psacln rights to it.

And several more knobbly problems to keep you occupied.  Web.config file reporting a duplicate MIME type? That sort of thing.

Ah, well. All sorted eventually ... until the next upgrade!