Опыт миграции на 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) – поиск неисправностей это какой-то ужас! Или как минимум масса потраченного
времени.

SMSMSE 6.5 no longer allows wildcards


   Вчера боролся с огромной очередью печати на Exchange 2003. На нем установлен Symantec Mail Security for Microsoft Exchange (SMSMSE) 6.5 Работал как часы. И вдруг в логах все красным красно, очередь на десятки тысяч сообщений – нелегкий труд спамеров. Ужас!

   Стал лечить. Раз в логах написано, что описания вирусов повреждены, они были снесены. После их обновления ситуация не изменилась. Очень интересная ситуация: в логах одно, а проблема в другом – зачем тогда нужны логи? В конце концов было обнаружена статья в базе знаний Symantec с кратким названием “Event IDs 68 and 110 entries appear in the Application Event log after importing a Symantec Mail Security for Microsoft Exchange (SMSMSE) 6.0 settings file into SMSMSE 6.5”

Суть статьи:

Cause

SMSMSE 6.5 no longer allows wildcards in regular expressions match lists. When these expressions are encountered SMSMSE incorrectly reports virus definition corruption

   Это просто полный… Во-первых, с какого перепуга регулярные выражения раньше принимали wildcards? Во-вторых, как это работало?! В-третьих, не видел, чтобы это «новшество» было отражено хоть где-то в документации. В-четвертых, понять к чему собственно относится выражение «no longer allows wildcards in regular expressions match lists» абсолютно невозможно.

   Хорошо хоть фильтр по маске у меня стоял только в одном правиле. Полгода назад я измучился его отлаживать: логика работы совершенно мутная – спас «метод научного тыка». И вот спустя несколько (!) месяцев после перехода на версию 6.5 SMSMSE понял, что он больше «no longer allows…»

   После  отключения этого правила SMSMSE 6.5 заработал без ошибок, очередь сообщений исчезла.

Вывод из всего этого: как страшно жить! :-)