Заказанная лицензия к панели Plesk по ошибке (или невнимательности) оказалась более новой версии, чем установленная версия Plesk на Вашем сервере? Ключ от версии Plesk 9 не подходит к панели plesk 8.6, как выяснилось уже позже.

При попытке обновить сервер ругается - ключ не содержит лицензии.

Не торопитесь расстраиваться и проплачивать ещё одну лицензию.

Как минимум, можно попробовать обновить версию Plesk из самой панели администрирования:
Server -> Updater (в одной из версий этот пункт назывался “Updates”).

После обновления до Plesk 9 сервер распознал ключ в лицензионном файле.

Кстати, старая “horde” перестала работать - после обновления версии plesk, возможно, потребуется обновить некоторые пакеты/компоненты.

Для многих сайтов производительность напрямую зависит от скорости ответов на mysql-запросы. Конечно, если выполняется запрос на выборку по ключу, да ещё из одной таблицы (да и в таблице записей немного) - то, скорее всего, результат будет известен быстро.

Если же требуется выполнить тяжелый (медленный?) mysql-запрос на выборку несколько связанных таблиц с кучей условий… и такого рода различных запросов порядка сотни… Чувствуется, что база не справляется, сервер “трещит по швам”… однако, где конкретно самое узкое место - непонятно. “Где тонко, там и рвется”. Возможно, достаточно оптимизировать один-два запроса, и mysql будет “летать”.. А возможно и нет.

Итак, как найти, какие mysql запросы наиболее сильно грузят сервер. Какие запросы наиболее требовательны к памяти и процессорному времени?

mysql-сервер предоставляет возможность отслеживать запросы, которые выполнялись слишком долго (long query time)

Журнал медленных запросов MYSQL

Это log-файл, в который помещается информация о запросах, которые выполняются больше указанного времени. Указанного где? Конечно, в конфигурационном файле. Кстати, по умолчанию журнал отключен - без исправлений в conf-файле не обойтись. Файл настроек для mysql обычно называется my.conf и хранится в каталоге /etc

Для включения логгирования медленных (предположительно тяжелых) запросов к серверу mysql добавляем в секцию [mysld] следующие строки:

log-slow-queries=/var/log/mysql/slow-queries.log
long_query_time=3
log-queries-not-using-indexes

Здесь в первой строке (log-slow-queries)указан путь к журналу медленных запросов (следует “организовать” сам файл и доступ к нему пользователю, от имени которого запускается mysql)
long_query_time - время выполнения медленного запроса
log-queries-not-using-indexes - фиксируем запросы, не использующие индексы

http://www.mysqlperformanceblog.com/2006/09/06/slow-query-log-analyzes-tools/

Делаем “человеческий” анкор-лист. Дешево и сердито.

Особенности:

• уходим от «склейки» - для тех, кто в нее верит; 
• даже для тех, кто не боится «тошноты» и «склейки» это пригодится, если нужно быстро создать большое количество различных анкоров для прогона по каталогам, сап-ксап и тд.
• делаем анкор-лист больше похожим на естественный;
• поднимаем по некоторым НЧ.

Технология:
1. Берем наш ключевик, к примеру, «проекты домов» и смотрим, в какие запросы он входит по статистике запросов. Лучше пользоваться статистикой Рамблера, так Яндекс выкидывает предлоги и найти по Яндексе такие запросы, как «из рук в руки», «муж на час» или «магазин на диване» вы не сможете. Найдутся только: «руки», «часы муж» и «магазины диванов».
Вместо окончаний ставим звездочки. Получится: «проект* дом*». Это еще не все. Чтобы уйти от ненужных нам запросов, типа: «проектирование домов», сделаем так:
проект* дом* !проектиров*
Запросы не совсем “по теме”  вроде «когда закроется проект дом 2» можно удалять вручную, но можно и оставлять – тоже разбавление анкор-листа, да и ключевик встречается.

2. Копируем странички получившегося списка в Excel, пока хватит терпения :).

3. Иногда Рамблер запрашивает авторизацию - не думаю, что велика проблема.

4. Подкорректируем списочек - удаляем “неугодные” и получаем результат..

Тоже самое можно проделать со статистикой от Яндекса.

Что с ним делать - на усмотрение..

Exchange находится в режиме восстановления - такое сообщение возникает у пользователя Microsoft Outlook 2003 при запуске программы. И выдается окно с выбором - подключиться к серверу или работать автономно.

Поиски в интернете - куча информации про восстановление dbx файлов. Однако, как убрать ошибку - непонятно. Вариации с включением/отключением кэширования (Учетные записи - просмотреть или изменить - изменить - Другие настройки), ни к чему не привели. Что за режим восстановления?

И тут вспоминаю, что не так давно был “переезд” - обновили сервер, привели в порядок адресную книгу.. В общем, предположение, что данные на сервере и локальные отличаются. Грузимся в автономном режиме - так и есть - имеются папки, содержащие “ошибки синхронизации”. Внимательный просмотр адресной книги - “старая” (которая была до переезда).

Удаляем и создаем заново учетную запись Exchange - все работает! Как удалять - чуть ниже…

Возможно, перед удалением, имеет смысл сохранить все сообщения в “Личных папках” на локальном компьютере.

Заходим в Панель управления - Почта - Учетные записи
* Просмотреть или удалить имеющиеся, выбираем нужную - удалить - подтверждаем - готово
* Добавить новую учетную запись… выбираем тип записи Microsoft Exchange Server, указываем сервер и имя пользователя - ок…

После запуска Outlook все работает “как по маслу”- окошко про режим восстановления Exchange не появляется - программа сразу подключается к серверу и обновляет папки.

ps. Видимо, “недопереехали”…
pps. На всякий случай - MS Exchange Server 2003, MS Outlook - 2003.. Где-то промелькнуло, что на более ранних версиях такого сообщения быть не должно.