Случается так, что в рамках GPO монолитные объекты провоцируют понижение производительности, в силу особенностей контроля версиями политик групп, что далеко не всегда является очевидным с самого начала.
На самом деле причины эти связаны с тем, что в механизме обработки групповых политик отсутствует концепция контроля, основанная на расширении CSE. Приведем простой пример: к конкретному пользователю было применено до 3 объектов GPO, каждый из которых является монолитным в плане реализации в нескольких сферах. Допустим, что в рамках каждого объекта средствами GPO реализуются политики использованием административного шаблона, перенаправления директорий и установки ПО. Допустим, что администратор решил изменить политику админ-шаблона для одного из вышеупомянутых объектов GPO. За счет внесения подобного изменения будет увеличен номер версии, после чего пользователь, который будет производить обработку политик групп с использованием CSE. При запуске этого расширения пользователь заметит, что к одному из GPO-объектов стал снова обрабатывать все три GPO-объекта.
Когда происходит запуск CSE-расширений, перенаправления директорий и установки программного обеспечения, они также отмечают номер версии для объекта GPO. Но так как номер версии малоинформативен в отношении того, какая из политик применялась к данному объекту, CSE обрабатывают его повторно. Все это приводит к затрате ресурсов для обработки в другой области. Если мы говорим о функциональных объектах GPO, то чем больше их приходится на локальную машину или пользователя, тем больше времени требуется механизму групповой политики на их перечисление при основной обработке политик групп.
Измерение параметров производительности GPO
Так или иначе, для правильной настройки в контексте производительности GPO потребуется измерение данного параметра в условиях реальной среды.
Говоря о снижении производительности мы подразумеваем, что обработка групповых политик определенным образом влияет на качество пользовательского обслуживания.
Для измерения продолжительности цикла обработки GPO в рамках Windows 7/Server2008 можно использовать рабочие журналами для просмотра событий :
«Журналы приложений» => «Журналы служб и приложений» => Microsoft => Windows => «Действующая». Это удобное и функциональное решение для контроля цикла обработки политики групп на каждом этапе.
Оптимизация производительности для групповых политик – полезные рекомендации
Все рекомендации, которые мы решили привести в данной статье, сводятся к четырем базовым пунктам.
1. При внесении в GPO-объекты частых изменений, следует помнить о том, что изменения для одного CSE-расширения может отразиться на обработке всех расширений CSE. В этой связи при необходимости регулярно вносить изменения, к примеру в политику реестра, целесообразно поместить эту политику в рамка функционального GPO-объекта, который отвечает исключительно за политику реестра. Это позволит изолировать другие CSE-расширения от изменений, которые провоцируют повторные циклы обработки.
2. Обдумывая то, сколько может потребоваться объектов GPO, не следует забывать о том, что политика будет обрабатываться лишь после изменений. С другой стороны CSE-расширения, требующие затрат дополнительных ресурсов, включая установку ПО, перенаправление директорий, установка разрешений для больших файловых каталогов и обработка большого количества политик, будут занимать достаточно много времени.
3. Необходимо избегать таких поведенческих моделей, которые определенным образом влияют на производительность при обработке политик, существенно снижая ее. Так, Вы можете установить политику, которая назначит обработку для расширений CSE даже при условии, что GPO-объект остается неизменным («Конфигурация компьютера» => «Административные шаблоны» => «Система» => «Групповая политика»). НО в данном случае придется брать в расчет то, что циклы обработки будут более продолжительными.
4. Не следует забывать и о последствиях, которые влечет за собой оптимизация входа в систему. В Windows 7 можно ускорить вход в систему, настроив политику в «Конфигурация компьютера» «Административные шаблоны» => «Система» => «Вход в систему» => «Всегда ждать ответа сети при запуске компьютера и входе пользователя в систему». При включении данной политики обработка переднего плана переходит с асинхронного в синхронный режим. Фактически это означает, что пользователь сможет управлять рабочим столом и компьютером только после того, как пользовательская политика и политика компьютера будут выполнены полностью. В свою очередь это будет полезным при необходимости производить два и более входа и перезапуска системы с тем, чтобы привести в действие политики по перенаправлению папок и установке требуемого ПО.
