+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 для автоматического развертывания обновленной версии клиента поверх установленной старой. Для обновления это работает.
Фото:

Новый механизм сканирования в Trend Micro OfficeScan 10

Вопросы
Выпустив новую версию своего основного корпоративного антивирусного продукта для защиты конечных точек - OfficeScan (OSCE) 10.0, компания Trend Micro сделала то, о чем говорила уже достаточно давно. Теперь в OfficeScan для антивирусной проверки файлов на защищенной системе можно использовать как традиционный (conventional scan) метод сканирования файлов на основе сигнатур (pattern), так и сканирование "в облаке" - этот новый метод называется smart scan.
Технология Smart Scan, входящая в "облачную" инициативу Trend Micro Smart Protection Network, в контексте файлового антивируса позволяет (теоретически) повысить скорость обнаружения новых вредоносных кодов за счет отказа от фиксированного паттерна, обновляемого с достаточно большой (10-15 часов) задержкой, снизить нагрузку на сетевой сегмент (паттерн не нужно передавать с антивирусного сервера на каждый защищаемый узел), а также оптимизировать использование памяти сканером реального времени (полное содержимое паттерна более не должно распаковываться в оперативную память системы - к примеру, сегодняшняя Windows-версия 6.575.00 основного паттерна Trend Micro имеет размер 33.6 Мбайт в упакованном виде). Каким образом это реализовано?

Как это работает
В инфраструктуре OfficeScan 10, включающей технологию smart scan, появляется еще один, фактически независимый, серверный компонент - Smart Scan Server, представляющий собой сетевой паттерн-сервер, тот самый "облачный" элемент. Клиенты, настроенные на использование smart scan (так называемые smart clients), отправляют на Smart Scan Server сигнатуры анализируемого файла. Сервер анализирует сигнатуры и отправляет клиенту ответ о статусе файла (в простейшем случае вариантов два - заражен или нет, однако нельзя забывать и про эвристику. На самом деле, ответ включает полную информацию о вредоносном коде, а также ActiveAction - что Trend Micro рекомендует с ним делать).

Здесь сразу же возникает масса вопросов. Во-первых - если, к примеру, антивирусный клиент настроен на проверку каждого файла при любом обращении, неужели каждая такая проверка будет порождать отдельный запрос на smart scan сервер? Во-вторых, что именно передается на сервер - уж не проверяемый ли файл целиком (а как иначе его можно проверить на вредоносное содержание) - но если это так, то о какой экономии пропускной способности сети может идти речь? Кроме того, откуда smart scan сервер берет информацию, если сигнатуры не используются?
Что касается последнего вопроса, ответ прост. Паттерн по прежнему используется - чудес не бывает. Это так называемый Smart Scan Server Pattern - обновление, которое smart scan сервер должен загрузить (с сайта Trend Micro ActiveUpdate, с сервера Control Manager организации или откуда-либо еще). Однако, во-первых, он обновляется значительно чаще, чем традиционный (конфигурируемый интервал обновления составляет всего 15 минут), во-вторых, он доступен всем smart-клиентам сразу по загрузке сервером (так как размещен на стороне сервера и не требует полного копирования на клиентскую сторону).
На клиенте работает так называемый smart query filter - "умный" компонент, который определяет, нужно ли в данный момент проверять данный файл (скажем, если паттерн на smart scan сервере не обновлялся, а файл не модифицировался с момента последней проверки - проверка не нужна). Кроме того, используется интеллектуальный проприетарный алгоритм, позволяющий исключить отправку полной копии файла на сервер (выглядит это примерно так - "удаленно определить, есть ли в сигнатурной базе smart scan сервера сигнатура данного файла";). При этом, smart scan паттерн и результаты его работы (на основании уже выполненных запросов) кэшируется (все-таки!) на клиенте на случай, если в какой-то момент он станет автономным, отключившись от сети, и доступа к smart scan серверу не будет.
Для передачи хэшей передаваемых файлов на smart scan сервер клиент использует протокол DNS. В этом ничего нового нет - подобный метод уже использовался ранее в OSCE 8 для запроса репутации посещаемых веб-сайтов в реальном времени (при активном компоненте Web Threat Protection), а в IMSS 7.0 таким же образом (с помощью DNS-запросов) на серверы репутации Trend Micro передавались хэши предполагаемых спам-сообщений (это был один из методов проверки электронных писем в составе Spam Prevention Solution), не говоря уже о "классическом" использовании DNS в Network Reputation Services (выполнение запросов к черным спискам IP-адресов отправителей SMTP как DNS-запросов). Поскольку запросы DNS обычно не блокируются ни для каких конечных клиентов, дополнительных требований по организации сетевого взаимодействия smart-клиента и сервера нет.
Smart Scan сервер может быть запущен на OfficeScan сервере как отдельная служба (в сочетании с традиционным компонентом OfficeScan Master Service) - так называемый integrated-режим. Однако он может быть развернут и автономно (режим standalone), на виртуальном appliance (представляет собой специальную виртуальную машину VMware под управлением CentOS) - это предоставляет дополнительную гибкость при проектировании и сопровождении системы. Smart Scan серверов может быть больше одного (в этом случае клиент в случае недоступности какого-либо из серверов будет перебирать оставшиеся по конфигурируемому списку). Для меняющих расположение (покидающих корпоративную сеть или перемещающихся внутри ее) клиентов список smart scan серверов может быть динамическим (например, привязанным к конкретному сетевому сегменту). Для roaming-клиентов можно использовать Smart Scan серверы, размещенные в облаке общего доступа Trend Micro (наподобие, как roaming-клиенты могли использовать Trend Micro ActiveUpdate без специальной переконфигурации в предыдущих версиях OfficeScan).
Оба метода (conventional scan и smart scan) могут быть использованы параллельно в рамках одной инсталляции. Антивирусный клиент является унифицированным - то есть, один и тот же клиент OSCE 10 может работать и как обычный, и как smart-клиент, без переинсталляции или перезагрузки. Переключение режимов осуществляется в реальном времени, с помощью привычной веб-консоли администрирования сервера OfficeScan.

Выводы и советы
Решение, конечно, смелое и для защиты конечных точек, предлагаемой Trend Micro, концептуально новое. Как и всегда в таких случаях, понятно недоверие заказчиков (особенно в контексте такого "деликатного" вопроса, как антивирусная защита) к подобным инновациям. Уверен, что ни один серьезный системный администратор не бросится внедрять данную технологию во вверенной ему сетевой инфраструктуре, не потратив времени на предварительное исследование вопроса и пилотное тестирование. И это абсолютно правильно. Здесь, пожалуй, можно провести некую аналогию со всем известным антивирусным ПО Microsoft Forefront - я не сомневаюсь ни его действенности, ни в хороших перспективах, но известные лично мне внедрения пока можно пересчитать по пальцам, а ведь продукт существует (под брендом Microsoft) уже почти три года.
В любом случае, в рамках конкретной инфраструктуры, при планировании внедрения технологии Smart Scan нужно начинать с тестирования в пилотной зоне, которая по своему составу должна быть максимальна приближена к "боевой". Причем тестирование должно занимать, думаю, не менее двух месяцев - особенно сейчас, когда технология еще относительно свежая - за меньший период необходимую информацию и статистику использования просто невозможно собрать.
Внедрение также должно быть постепенным. Клиенты могут переключаться из одного режима в другой в любой момент. Smart Scan сервера тоже могут быть добавлены в сеть, когда это потребуется. Кстати говоря, Smart Scan может быть поднят и на conventional-сервере OSCE 10 уже после его развертывания - без переинсталляции, соответствующая процедура называется "Integrated Smart Scan Server Reactivation" и описана в Smart Scan Getting Started Guide на странице 3-25. Документ обязателен к изучению всеми "заинтересованными лицами" и на данный момент доступен по ссылке http://www.trendmicro.com/ftp/documentation/guides/OfficeScan10_PDF_SmartScanGSG.zip .

P.S. 3 ноября 2009 в офисе Поликом Про будет проводится семинар по тематике Trend Micro. Один из докладов будет посвящен как раз новым возможностям продукта OfficeScan 10. Подробности на http://www.polikom.ru/seminar/5493/, милости просим.
Фото: