Опыт миграции на Sep 12.1 (2)


Не так давно писал о своем опыте миграции на SEP 12.1 (Опыт миграции на Sep 12.1) И история не закончилась. Закончилось место на диске! :-) Очень быстро нашлась раздувшаяся папка C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\content И как обычно на сайте поддержки Symantec нашлась куча статей по решению этой проблемы, которые либо ничего не решали, либо откровенно устарели. Тем не менее на форуме нашелся ответ:

  1. Open SEPM console
  2. Admin
  3. Servers
  4. Local Site
  5. Edit Site Properties
  6. Liveupdate
  7. Number of content revisions to keep: default is 30, tried a value of 10 -> FIXED.

Все банально просто :-) Если учесть, что одно такое хранимое обновление весит около гигабайта, то  решайте сами сколько места вы хотите похоронить :-)

Опыт миграции на Sep 12.1


Хочу поделиться опытом миграции на SEP 12.1.

Так как документации мы не читаем J, а разработчики нам отвечают нам тем же: не пишут ее (да есть такое у Symantec – в документации одно, а на деле другое), то грабли собираются косяками.

И так после установки сервера SEPM 12.1 сразу возникла проблема с пустыми страницами Home, Monitors и Reports. «Ха!», – глубокомысленно подумал я и решил, что надо подкрутить те же параметры, что и раньше Консоль SEP 11: «unable to communicate with the reporting component». Но не тут-то было: выяснилось, что в Sep 12.1 больше не используется IIS! Вместо него Apache и все тот же PHP. Видимо разработчики решили таким образом обеспечить большую кроссплатформенность. Не знаю насколько они в этом приуспели, но новые глюки потребителям добавили.

После плясок с бубном выяснилось, что в этой версии не работает Windows аутентификация с SQL сервером! После перехода на SQL аутентификацию консоль SEPM 12.1 запустилась в нормальном режиме.

Далее после настройки и запуска LiveUpdate все время в журнале «LuAll.exe finished with return code 2». Поиск в Интернете показал, что проблема с прокси. Оказалось, что в текущей версии не работает Windows аутентификация с ISA/TMG! Как только переключил настройки и сделал анонимный выход в Интернет для сервера SEPM, пошла закачка обновлений.

Во время всех этих плясок выяснилось, что SEMP теперь требует установки лицензии и последующей ее активации! Иначе работает в триальном режиме 60 дней. При решении выше описанных проблем у меня было подозрение, что консоль не работает без активации. Но выяснилось, что это не так. Выяснилось ценой одной активированной лицензии J.

Но это еще не всё! Т.к. я размещал базу на MS SQL 2008 R2, то решил поставить последню версию клиента SQL на сервер SEPM – да, такой клиент необходим, если вы решили разместить базу на MS SQL. Тут оказалось, что если раньше можно взять в дистрибутиве MS SQL или на сайте Microsoft небольшой автономный пакет и установить его, то в этом случае фокус неудался: помимо клиента для работы SEMP 12.1 нужны дополнительные утилиты из дистрибутива MS SQL (в частности bcp.exe). Поэтому пришлось запускать установку MS SQL и выбирать для установки два компонента: Connectivity Tools и Management Tools в полном объеме.

Но и это еще не все! Фаэрвол. Ну это не новое, но если переезжать с Windows Server 2003 на Windows Server 2008 R2, то не забудьте про него J Вот описание портов http://www.symantec.com/connect/forums/sep-port-clarification

Но и это еще не все мои злоключения J Пока я пытался побороть клюки SEPM, уже шел процесс миграции клиентов по второму методу (репликация) статьи http://www.symantec.com/business/support/index?page=content&id=TECH104389 Тут я упустил разницу портов: новая версия использзует порт 8014, а старая порт 80. Часть клиентов успешно мигрировала на новый сервер. Потом когда мне потребовалось вернуть их обратно, чтобы переустановить новый сервер, был изменен приоритет серверов на обратный и … клиенты заблокировались! – они пытались поблючиться на порт 8014 к старому серверу вместо порта 80. И не туды и не сюды… Переустановка клиентов? Ужас! Нашел статью http://www.symantec.com/business/support/index?page=content&id=TECH92556 Первый метод переустановки не сработал, второй требовал обращения в тех.поддержку. Нашел другую статью http://www.symantec.com/business/support/index?page=content&id=TECH90761 Хоть и ручной метод, но все же быстрее чем полная переустановка. И опять облом: при нажатии на кнопку Импорт клиенты сказали, что функция заблокирована.

Что ж, база знаний Symantec выдала еще одну статью (на самом деле этих статей там на одну и ту же тему очень много – если бы такая база знаний была у Microsoft, то ее бы просто смешали с землей!) http://service1.symantec.com/SUPPORT/ent-security.nsf/2326c6a13572aeb788257363002b62aa/13669c4f8319b89e882574e5004e7328?OpenDocument Отлично! Берем утилиту SylinkDrop.exe, берем SyLink.xml со старого сервера, как описано в статье, обновляем клиента – не сработало L Странно. Находим еще одну статью http://www.symantec.com/business/support/index?page=content&id=TECH157585 Оказывается местоположение файла SyLink.xml в версии 12.1 изменилось! Берем утилиту SylinkDrop.exe старой версии (версии клиентов) – Ура! Клиент похватил новые настройки, подключился к старому серверу и закачал обновления.

Теперь осталось выполнить эту операцию для всех пострадавших клиентов. К счастью это уже поле не Symantec: выкладываем SylinkDrop.exe и SyLink.xml на шару, делаем политику с логон скриптом (у SylinkDrop.exe есть ключи запуска!) – после перезагрузки компьютеров они успешно подхватили настройки, подключились к старому серверу SEPM и обновились.

Мне осталось только заново установить и настроить сервер SEPM 12.1 с учетом накопленного опыта и снова мигрировать на него клиентов.

Вместо заключения

Я работал с антивирусом от Symantec уже много лет. Версия SAV 8, а потом версия SAV 9, поражали своей стабильностью, скоростью работы и простотой. Версия 10 подозрительно отяжалела, но работала сносно.

Когда же мы обновились до версии 11, пользователи взвыли: компьютеры стали медленно грузиться и медленно работать. Выкручивание параметров и настроек не сильно помогало. Надежда на обновления не оправдалась: SP, MR и т.п. выходили регулярно, но сути не меняли – антивирус пожирал львиную долю ресурсов компьютера. Более того сами обновления выходили с такими багами, что тут же перевыпускась заново! К тому же очередной MR мог оказаться несовместимым с предыдущими версиями! – а это приводило к проблемам автоматической установки обновлений: после установки такого обновления приходилось сносить клиента и ставить его с нуля.

Да… что-то сломалось несколько лет к команде SEP.

Честно говоря, это уже достало. И я планировал перейти на Forefront. Но анонс версии SEP 12.1 внушил надежду, что ситуация исправится: Symantec обещал, что клиент станет намного умнее и шустрее. Сейчас буду наблюдать за пользователями: если жалобы на тормознутость компьютеров продолжатся, то придется вплотную заняться тестированием Forefront. Кстати на Exchange сервер он показал себя достойной заменой Symantec – работает шустро и стабильно, а главное качественно фильтрует спам. А вот Symantec пока надежд не оправдывает…

Если у вас есть полезный опыт – Welcome! – пишите в комментариях или оставляйте ссылки на свои статьи.

Консоль SEP 11: “unable to communicate with the reporting component”


Очень забавная проблема возникла после установки Symantec Endpoint Protection Manager 11: запускаем консоль, вводим имя и пароль, консоль запускается и пишет «unable to communicate with the reporting component», после чего консоль открывается, но целый ряд страничек пустой.

Ошибка оказалась популярной: каких только рекомендаций не было найдено в Интернете и на сайте Symantec!

В конце концов нашел рекомендацию: дать всем полный доступ на директорию отчетов  C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting

После этого консоль вообще перестала запускаться! Вроде стартует и тут же возвращается к вводу имени и пароля. Включил логи для виртуальной директории Reporting. В логах так и написано:

GET /Reporting/login/logoutSPM.php ssc=1

— с логикой компьютера не поспоришь :-). Вот только непонятно почему идет «логоф»… Но уже хоть какой-то прогресс!

После очередной порции поисков в Интернете нашел рекомендацию: дать всем полный доступ на директорию временных файлов

%ALLUSERSPROFILE%\Application Data\Symantec\Symantec
Endpoint Protection Manager\Php\temp

и О! Чудо! Консоль запустилась со всеми страничками dashboard и отчетов.

Но как-то неправильно это давать права Everyone, да еще и полные. Вернул исходные права. Решил подкрутить IIS. Попытка поменять учетку пула приложений закончилась неудачей – консоль не стартует как надо. Странно: под какой же учеткой стартует консоль? Запустил Task Manager, залогинился в консоле, и увидел запуск процесса php-cgi.exe под учеткой, которую я указал для подключения к SQL базе! Вот и догадайся! :-)

Теперь осталось дать этой учетке полные права на выше указанные директории, и консоль заработала как положено.

Вывод: вот почему я не люблю Java. Казалось бы причем тут она, но консоль SEP это жуткое мессиво Java, PHP и Tomcat) – поиск неисправностей это какой-то ужас! Или как минимум масса потраченного
времени.