+7 (812) 325 84 00

+7 (499) 322 07 96

Опыт траблшутинга SEP 12.1 Client AutoUpgrade

Опять о том же.

Получил достаточно интересный опыт применения технологии AutoUpgrade для развернутого решения SEP 12.1 для обновления клиентов. Требовалось обновить инсталляцию c RU3 до RU5.

Технология AutoUpgrade  вскользь упоминалась в предыдущем посте (“Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик AD”, http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php).

Полностью процесс обновления SEP описан здесь – “Upgrade or migrate to Symantec Endpoint Protection 12.1.5” https://support.symantec.com/en_US/article.TECH224034.html. Начинать надо с обновления серверной части.

Здесь речь пойдет о двух специфических моментах, связанных с обновлением клиентов (собственно технологией AutoUpgrade). Сама процедура обновления описана в статье “Upgrade Symantec Endpoint Protection 12.1 clients using AutoUpgrade”, https://support.symantec.com/en_US/article.TECH96789.html.

1.
Для того, чтобы обновление успешно запустилось на группе, по факту нужно установить несколько параметров распространения пакета в следующие значения (на скрине пример нужных настроек):



· Сохранить существующие функции клиента при обновлениифлаг снят;
· Расписание обновленияфлаг снят;
· Время рассылки обновлений0 дней.

Последние два параметра инициируют немедленную рассылку пакета (при следующей пульсовой передаче). А если не снять первый флаг, пакет обновления может быть отклонен клиентом.

Соответствующие вопросы обсуждаются на форумах Symantec Connect, например, здесь: http://www.symantec.com/connect/articles/upgrade-clients-sep-121-auto-upgrade-feature

2.
В процессе развертывания, некоторые разрозненные клиенты RU3 (порядка 4%), все равно явно отклонили пакет обновления RU5, записав об этом в лог. Выглядело это вот так (в свойствах клиента):



Чтобы найти причину, в конце концов понадобилось включить SMC/Sylink Debugging на тестовом клиенте (“Enable sylink debugging for Endpoint Protection clients”, https://support.symantec.com/en_US/article.TECH104758.html). Выяснилось, что в дебаг логе клиента SMC c:\ programdata\symantec\symantec endpoint protection\12.1.3001.165\Data\Logs\debug.log в момент загрузки пакета обновления фиксируются следующие строки:

2015/04/23 23:46:12.822 [4068:4180] unmatched language type.  the requested auto-upgrade cancelled.
2015/04/23 23:46:12.822 [4068:4180] Upgrade package not needed by SMC. .checking if opstate to be sent or not.

Анализ показал, что на проблемных системах ошибочно определялась ситуация, описанная в статье “AutoUpgrade fails if the language of the assigned package does not match the language of the currently installed client”, https://support.symantec.com/en_US/article.TECH153398.html - несовпадение языков установленного клиента и назначенного пакета обновления. Причем, в реальности, никакого несовпадения не было.

SEP клиент 12.1 RU3 отслеживает свою локализацию по двум параметрам реестра в ключе  HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC : HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\ProductLocale (тип REG_DWORD) и HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\Language (тип REG_SZ).

На русских версиях клиента параметры должны быть такие: ProductLocale =0x00000419 (1049), и Language =”Russian”.

Оказалось, что на проблемных системах RU3, отклонивших обновление до RU5, параметр Language почему-то установился в “ English”, хотя и локаль клиента, и операционная система были русские. Видимо, SEP клиент RU3 так определил язык при изначальной инсталляции. Почему – неизвестно; возможно, причиной было наличие какого-то специфического стороннего программного компонента либо настройки, или еще что-то в этом роде.

Workaround заключается в том, чтобы вручную через реестр сменить параметр HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\Language на "Russian”, затем перезапустить клиент командами smc –stop и smc –start (делать это нужно с правами  администратора; при остановке клиента спрашивается пароль на выгрузку SEP, если он установлен), и затем переобъявить пакет обновления до RU5 на группу средствами SEP Manager. Решение помогает сразу.

ПРИМЕЧАНИЕ.
Для очень больших групп, немедленное развертывание клиента теоретически может вызвать лаг сети и сервера, о чем SEPM честно предупреждает при публикации пакета. Однако я с какими-либо проблемами производительности на инсталляции порядка 650 клиентов, распределенных по примерно 7 группам, не столкнулся.

Распространение SEP 12.1 с помощью групповых политик. Вариант для беспроводных соединений с авторизацией по входу пользователя в домен

Cтатья описывает несколько видоизменное решение из предыдущего поста (“Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик AD”, http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php).

В процессе того же внедрения, обнаружилась специфическая именно для данной инфраструктуры проблема. Заказчик в офисе активно использовал Wi-Fi, и более половины парка рабочих станций составляли ноутбуки, работавшие только по беспроводному соединению; причем, авторизация системы на точках доступа внутренней сети происходила только после входа пользователя в домен (для выдачи сертификатов авторизации использовалась служба AD CS).

В ОС Windows политики, назначенные на контейнер Computer Configuration, запускаются в обработку, в общем случае, еще до момента входа пользователя в систему (и до появления стандартного приглашения на вход по Ctrl-Alt-Del). Поэтому предложенный ранее метод для беспроводных клиентов не работал - так как, на момент инициализации и применения политик, системы еще не были авторизованы в сети, и не имели доступа к файловым ресурсам с дистрибутивами. В то же время, для проводной сети все работало отлично.

Поэтому решили инициировать запуск скрипта установки альтернативным методом – путем добавления задачи в планировщик Task Scheduler операционной системы через механизм Group Policy Preferences (GPP). Поскольку все клиенты работали под управлением Windows 7/8, проблем с совместимостью параметров GPP со старыми версиями ОС не возникло.

Процесс по шагам:

1.
Для того, чтобы создать нужное задание в планировщике, в GPO в контейнере Computer Configuration\Preferences\Control Panel Settings\Scheduled Tasks создаем новое задание командой New\Scheduled Task (At least Windows 7), и устанавливаем такие параметры задания (вкладка General):


Доменная учетная запись SEPInstall должна иметь административные права на целевой рабочей станции, доступ на чтение к файловому ресурсу с дистрибутивом и постоянный пароль на время развертывания (пароль сохраняется в свойствах назначенного задания);

2.
Триггер старта задания устанавливаем, например, так:


Так как задача запускается периодически, в скрипт должна быть добавлена какая-то логика определения уже успешной установки, дабы процедура не запускалась снова и снова (см. мой комментарий к предыдущему посту);

3.
На вкладке Actions устанавливаем запуск скрипта:


Обращаю внимание, что, пакетов будет два - для x86 и x64 версий клиента (см. предыдущий пост http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php), поэтому политик GPO и скриптов установки опять таки должно быть по паре, для систем разной разрядности. То есть, все, что говорилось в ранее о таргетировании с помощью WMI-фильтров на 32- и 64-разрядные системы, в силе - повторяться не буду;

4.
Ниже рабочие примеры вкладок Conditions и Settings, оттестированные в реальном окружении:



5.
И, наконец, сами скрипты для установки клиента – те же, что уже публиковались (http://www.polikom.ru/blog/Systems_Engineer_notes/rasprostranenie-klientov-symantec-endpoint-protection-121-shtatnymi-sr.php?commentId=1590). По сути, методика может использоваться и для систем с обычным (проводным) подключением. Теперь можно отказаться и от перезагрузки системы для запуска процедуры инсталляции (задача добавляется в планировщик сразу же при очередном цикле применения GPO).

ЗАМЕЧАНИЯ.

· Идея взята отсюда - http://www.grouppolicy.biz/2010/01/how-to-schedule-a-delayed-start-logon-script-with-group-policy.
Но - есть определенные нюансы безопасности при хранении учетных данных назначенных заданий в объектах GPO, и в самом планирощике Task Scheduler. В принципе, это может быть проблемой, так что решение предоставляется AS IS.
В любом случае, по завершении развертывания, соответствующие объекты групповых политик и планировщика желательно удалить, а пароль служебной учетной записи инсталляции – поменять;

· Для синхронизации применения групповых политик с моментом входа пользователя в систему существуют альтернативные решения, см. многочисленные посты по теме на http://social.technet.microsoft.com/Forums/windowsserver/en-US/home. Но, по ряду причин, в данном конкретном случае применять их было нежелательно. Поэтому и придуман вариант с GPP;

· Опять-таки - решение не заменит полноценную систему управления конфигурациями, даже для установки ПО. Для серьезных ИТ-инфраструктур она обязательна!

Распространение клиентов Symantec Endpoint Protection 12.1 с помощью групповых политик Active Directory

Во время одного внедрения антивирусного решения Symantec Endpoint Protection 12.1 в достаточно крупной сети (порядка 1000 клиентов под разными версиями ОС Windows, один сервер SEP Manager), потребовалось организовать автоматизированное развертывание клиентов SEP.

Symantec Endpoint Protection, в общем, не предоставляет для этого собственных средств. Консоль SEPM имеет исчерпывающий функционал по генерации пакетов развертывания, и интерактивный интерфейс для push-инсталляции, предполагающий, что клиент доступен по сети в момент установки. В большой среде такое, фактически ручное, “проталкивание” клиента, конечно, неэффективно.  

Кроме того, по установленным регламентам, рабочие станции были достаточно строго закрыты брандмауэром Windows Firewall, что делало доступ к ним через сеть по протоколам RPC/SMB невозможным. Обычные методы удаленной инсталляции антивирусных клиентов с сервера (это справедливо не только для SEP, но и, скажем, для Trend Micro OfficeScan, Kaspersky Security, и т.д.) предполагают соблюдение, как минимум, следующих условий:

·   Доступность удаленного хоста по RPC/SMB, что, в случае брандмауэра Windows Firewall, означает включенные стандартные правила группы “Общий доступ к файлам и принтерам” для входящих подключений;
·   Доступность административного общего ресурса ADMIN$ на удаленном хосте;
·   Отключенный простой общий доступ к файлам (см. “How to disable simple file sharing and how to set permissions on a shared folder in Windows XP”, http://support.microsoft.com/kb/307874/en-us) на удаленном хосте;
·   Запущенную на удаленном хосте службу Remote Registry (в новых версиях ОС Windows по умолчанию отключена);
·   Начиная с ОС Windows Vista, некоторые специфические настройки UAC (см. “Description of User Account Control and remote restrictions in Windows Vista”, http://support.microsoft.com/kb/951016).

В контексте клиента SEP, требования подробно описаны вот здесь:
·   “Push install Symantec Endpoint Protection 12.1 clients using Remote Push”, http://www.symantec.com/business/support/index?page=content&id=tech164327;
·   “Preparing Windows and Mac computers for remote deployment”, http://www.symantec.com/business/support/index?page=content&id=HOWTO80805.

В данном случае условия частично не выполнялись. Полноценной системы управления конфигурациями (Microsoft SCCM, Symantec Altiris, и т.п.), как обычно, не было, поэтому решено было обойтись средствами AD. Решение описано ниже.

1.
Клиент SEP - стандартный для всех версий клиентских ОС Windows, но отдельный для разрядностей x86 и x64. Способа подготовить единый пакет для обеих разрядностей не существует, поэтому необходимы два пакета. Клиенты для ОС Windows можно найти в распакованном виде в структуре дистрибутива ПО Symantec Endpoint Protection. В моем примере (для билда RU3, дистрибутив скачан с Symantec FileConnect, распакован в папку C:\Distribs\SEP 12.3\unpack), они лежат в локальных папках:

C:\Distribs\SEP 12.3\unpack\Symantec_Endpoint_Protection_12.1.3_Part1_Installation_RU\SEP
и
C:\Distribs\SEP 12.3\unpack\Symantec_Endpoint_Protection_12.1.3_Part1_Installation_RU\SEPx64

для x86 и x64 соответственно.

Сначала необходимо создать административную установку клиентов x86 и x64 в сети на сетевом ресурсе (общей папке), доступной с клиентских рабочих станций. Папка и файловая система NTFS должны иметь разрешения, как минимум, Read для учетных записей компьютеров AD (обычно достаточно разрешения Read для группы Domain Computers на общем ресурсе). Это важно, так как пакет будет назначаться (assign) для учетной записи компьютера, что обеспечит и независимость от наличия пользовательских административных прав, и автоматическую установку при следующем старте системы.

Для того, чтобы подготовить административную установку пакета x86, необходимо из каталога C:\Distribs\SEP 12.3\unpack\Symantec_Endpoint_Protection_12.1.3_Part1_Installation_RU\SEP запустить msiexec /a Sep.msi. Откроется мастер установки, в котором нужно указать единственный параметр – целевой каталог в удаленном общем ресурсе. В моем примере создана структура типа \\SERVER1\SHARE1\SEPClient, и в нем папки x86 и x64 для двух разных пакетов. То есть, для пакета x86 целевым ресурсом будет \\SERVER1\SHARE1\SEPClient\x86.
Для пакета x64, аналогично, из каталога C:\ Distribs\ SEP 12.3\ unpack\ Symantec_ Endpoint_ Protection_12.1.3_ Part1_ Installation_ RU\ SEPx64 запустить команду msiexec / a Sepx64.msi, и указать целевой ресурс:
\\SERVER1\SHARE1\SEPClient\x64.

2.
Пакеты созданы, но пока “отвязаны” от сервера SEPM (так как взяты непосредственно из дистрибутива). Их надо “натравить” на наш конкретный сервер SEPM, иначе они поставятся как неуправляемые (unmanaged). Чтобы клиенты установились как управляемые (managed), нужно скопировать в пакеты конфигурационный файл SyLink.XML. Это файл привязки, он содержит ссылку на сервер управления SEPM и его цифровой сертификат SSL.

Мы предполагаем, что сервер SEPM уже развернут – а это значит, что образец такого файла есть в инсталляции серверной части. Идем в папку установки SEPM на сервере управления, нас интересует каталог % Program Files (x86)%\Symantec\Symantec Endpoint Protection Manager\ data\outbox\agent. В нем находится, как минимум, одна подпапка с именем _UID_, где UID - это уникальный идентификатор пакета, например, 8F171749C0A85C820163FBAA230DBF18 (реально для разных версий клиента папок будет несколько). Заходим в любую такую папку, и копируем из нее файл Sylink.XML (они одинаковые для всех UID-папок). Этот файл нужно положить в корни каталогов с сформированными намиранее административными установками клиента - то есть, в нашем примере, в папки \\SERVER1\SHARE1\SEPClient\x86 и\\SERVER1\SHARE1\SEPClient\x64.

Примечание. Инсталляционный пакет клиента также можно брать не из дистрибутива, а экспортировать из установленного SEPM стандартными средствами консоли SEP Manager. Здесь эта процедура не рассматривается. Она описана в ряде статей Symantec Support Knowledge Base, в частности, в статье “Creating custom client installation packages in the Symantec Endpoint Protection Manager console”, http://www.symantec.com/business/support/index?page=content&id=TECH102817. Для возможности установки клиента через групповые политики необходимо выбрать вариант экспорта в формате .MSI (а не .EXE) Экспорт пакетов также документирован в Symantec Endpoint Protection Administration Guide (для SEP 12.1 RU5, руководство лежит по ссылке http://www.symantec.com/business/support/index?page=content&id=DOC7698). Пакеты из SEPM можно экспортировать со списком включаемых компонент и c настройками (в частности, задавать целевую клиентскую группу, применяемые политики, и т.д.), и также распространять их средствами AD. Такой вариант может быть даже предпочтительным, так как дает гораздо больший контроль.

Мы же, в своем примере, генерируем “нулевой” пакет непосредственно из дистрибутива. Клиенты, поставленные таким образом (со стандартным файлом SyLink.XML), попадут в клиентскую группу по умолчанию, и к ним применится стандартный набор параметров.

3.
Дальнейшие шаги, в сущности, похожи для установки любого ПО, назначаемого через групповые политики. Необходимо создать два объекта GPO с помощью консоли Group Policy Management. Политик будут две – отдельно для x86 и x64 клиента. В нашем примере они называются так:
·   “Install SEP x86 Managed Client” – для 32-битного клиента;
·   “Install SEP x86 Managed Client” – для 64-битного клиента.

Обе политики назначаем на один и тот же целевой контейнер AD, в котором располагаются учетные записи компьютеров (предполагается, что там есть клиенты разной разрядности). В политику нужно включить следующие параметры:

· Сам пакет. Пакеты назначаются (тип Assigned) на контейнер Computer Configuration (не User Configuration), то есть, на раздел GPO Computer Configuration\Policies\Software Settings\Assigned Applications. Для 32-разрядной политики назначаем пакет \\SERVER1\SHARE1\SEPClient\x86\sep.msi, для 64-разрядной - пакет\\SERVER1\SHARE1\SEPClient\x64\sep64.msi. Настройки пакетов по умолчанию, файлы преобразований (transform) не используются;
· Параметр Computer Configuration\Policies\Administrative Templates\System/Logon\Always wait for the network at computer startup and logonВключить (задает синхронную установку); · Параметр Computer Configuration\Policies\Administrative Templates\Windows Components/Windows Installer\Always install with elevated privileges – Включить (установка выполняется с максимальными привилегиями).

Больше ничего в политиках конфигурировать не надо. Последние два параметра в отчете GPMC выглядят вот так:



4.
Далее, пакеты необходимо таргетировать на системы соответствующей разрядности. Для этого проще всего воспользоваться WMI-фильтрами. Пример рабочего решения - http://serverfault.com/questions/18670/group-policy-preferences-that-only-target-32bit-or-64bit-os. Фильтры нужно создать с помощью консоли Group Policy Management, в моем примере они называются “x86 System” и “x64 System”. Фильтр “x86 System”.

Фильтр “x86 System”:


Фильтр “x64 System”:


Теперь назначаем фильтры на политики с помощью GPMC:
· Политика “Install SEP x86 Managed Client” – WMI-фильтр “x86 System”;
· Политика “Install SEP x64 Managed Client” – WMI-фильтр “x64 System”.

5.
Групповая политика установки SEP-клиента применится при следующей перезагрузке целевой рабочей станции. Дабы избежать лага в производительности сети и файл-сервера, на котором размещены установочные пакеты, крайне рекомендуется создать специальную группу безопасности в AD, и включать в нее целевые учетные записи компьютеров поэтапно (например, пачками по 50 штук за раз), и использовать для созданных групповых политик фильтрацию по ACE “Apply Group Policy” (опция Security Filtering консоли GPMC) для этой группы. Таким образом можно контролировать развертывание на вполне приемлемом уровне.

ЗАМЕЧАНИЯ.
·       Решение не заменит полноценную систему управления конфигурациями, даже для установки ПО. Однако, при ее отсутствии, этим способом можно выполнять достаточно масштабные развертывания;
·       Установка синхронная, до ее завершения пользователь лишен возможности войти в систему. Поэтому перед роллапом людей надо предупреждать;
·       Подобная методика может, в принципе, быть использована для распространения не только клиента SEP, но и для любых других, не очень больших по размеру, пакетов .MSI;
·       После начального развертывания SEP клиентов, подключенных к серверу SEPM, в дальнейшем для апгрейда на более новые  версии (скажем, с 12.1 RU3 до 12.1 RU5), групповые политики использовать необходимости уже нет. Можно вместо этого задействовать возможности SEP Manager для автоматического развертывания обновленной версии клиента поверх установленной старой. Для обновления это работает.
Фото: