+7 (812) 325 84 00

+7 (499) 322 07 96

Распространение 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;

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