@домівка Віктора Чмеля

Задача: Представим, что у клиента есть один центральный офис и несколько филиалов раскиданных по стране. В головном офисе стоит OSCE Server, который послушно получает обновления от TM Control Manager и далее раздает их всем своим клиентам. Проблема в том, что если в филиале 100 клиентов OSCE, то обновления закачиваются туда 100 раз ;(, а это не есть хорошо т.к. грузит канал.

Для оптимизации этого дела славной фирмой Trend Micro в этом самом продукте OSCE придумана такая функция, как превращение обычного OSCE клиента в т.н. Update Agent, которому обновление закачивается 1 раз, а он потом отдает его всем ассоциированным с ним клиентам.

Ну, вроде бы все понятно, особенно после прочтения документации ;). Но есть одно НО. Update Agent желательно ставить не на рабочую станцию, а на сервер, чтоб он вечно жил и защищал. А в филиале стандартных серверов есть 2 штуки: Active Directory, которая держит домен Windows и почтовый Exchange, которые защищены продуктами Trend Micro ServerProtect и ScanMail for Exchange соответственно. Вначале было естественное желание поставить клиента OSCE на контроллер домена, но оказалось, что и у ServerProtect-а и у OfficeScan-а есть real-time модули сканирования и они по определению на одной машине не уживаются [*]. Поэтому было решено ставить на почтновый сервер НО с отключенной функцией Real-Time сканирования и сканирования по расписанию, чтоб не было конфликтов со ScanMail. Таким образом, получаем только точку для раздачи обновлений и ничего более, что нам и надо.

Ок, значит, как я это делал. На примере одного филиала.

• Зашел в Web-консоль управления OSCE Server-ом в головном офисе. Clients>Remote Install и удаленно установил агента на Exchange сервере.
• В Clients>Client Priviledges добавляем галочку в подразделе Update, опция - "Act as Update Agent (For Windows NT/2000/XP/Server 2003 clients only)", Save, Close.
• В Clients>Scan Options заходим в Real-time Scan Settings и запрещаем его (мы ведь договорились, что OSCE клиент нам нужен только как единая точка раздачи апдейтов в своем офисе, а не как сканирующий модуль). Если у вас включены какие-то Scheduled Scan Settings по умолчанию, то тоже их отключите.
• Далее Updates>Client Deployment>Update Source выбираем Customized Update Source и добавляем подсеть и конкретного агента, который должен ее обслуживать. Если у вас так организована инфраструктура, что по подсетям не выходит, то можно добавлять хоть по одной машине.

Когда это все будет добавлено, неплохо бы сообщить о ваших изменениях всем OSCE-клиентам (кликнуть на кнопочку Notify all Client(s)) Ну, вот по идее и все;)

[*] Это все касается версии OfficeScan 6.5, в которой хоть и заявлена работа на серверных Windows-платформах, но на данный момент все это происходит с некоторыми багами, в частности объекты OSCE-клиентов регулярно исчезают из Web-консоли. В апреле 2005 обещают OfficeScan 7.0 лишенную этих проблем. Тогда для данной задачи возможен и такой вариант решения: деинсталлируем ServerProtect и на его место ставим клиента OfficeScan, который будет и сервер проверять на вирусы и обновления рассылать в своем филиале. (Далее ServerProtect может быть полезен лишь как продукт умеющий работать на кластерах и UNIX/Linux платформах.)