Оптимизация производительности групповой политики

В моей предыдущей статье «Рекомендации по проектированию групповой политики» я описал, как с самого начала получить групповую политику, тщательно спланировав структуру Active Directory. Причина в том, что если вы не примете во внимание групповую политику до того, как начнете создавать свои домены, подразделения и сайты, вам может понадобиться использовать так называемые «расширенные» функции групповой политики, такие как блокировка наследования, принудительное применение или петля для заставьте вашу реализацию групповой политики делать то, что вы хотите, и использование этих функций усложнит устранение неполадок в дальнейшем. Тем не менее, хорошо спроектированная реализация групповой политики обычно прекрасно работает без необходимости использования какой-либо из этих «расширенных» функций (кроме использования фильтрации безопасности и иногда фильтров WMI), и в результате получается простая структура объекта групповой политики, которую легко понять. и устранить неполадки.

Однако частью разработки групповой политики является учет взаимодействия с конечным пользователем. В плохо разработанной реализации групповой политики пользователи могут столкнуться с длительными задержками, прежде чем появится окно «Добро пожаловать в Windows», предлагающее им нажать CTRL+ALT+DEL для входа в систему, или они могут столкнуться с дополнительными длительными задержками после ввода учетных данных для входа и до того, как они появляется рабочий стол, чтобы они могли начать свою работу. На самом деле длительные задержки при входе в систему обычно являются наиболее неприятным аспектом работы пользователя с точки зрения групповой политики, хотя на втором месте стоит ситуация, когда пользователи жалуются на то, что администраторы слишком сильно заблокировали свои рабочие столы с помощью групповой политики до такой степени, что пользователи чувствуют себя неуверенно. они не могут нормально выполнять свою работу. Давайте рассмотрим несколько советов о том, как можно оптимизировать групповую политику для ускорения входа в систему при сохранении уровня безопасности, который должна обеспечить реализация групповой политики.

Распространенный миф

Распространенный миф о групповой политике заключается в том, что чем больше у вас объектов групповой политики (GPO), тем больше времени требуется для их обработки во время запуска и входа в систему. На самом деле, в статье базы знаний Microsoft фактически говорится, что «время запуска и входа в систему прямо пропорционально количеству объектов групповой политики, которые необходимо обработать». Это несколько вводит в заблуждение по следующим причинам.

Во-первых, статья действительно права, когда говорится, что время запуска и входа в систему может зависеть от «количества объектов групповой политики, которые необходимо обработать». Ключевое слово здесь «обработано». Другими словами, важно не то, сколько объектов групповой политики вы создали в своей сети, а то, сколько объектов групповой политики фактически обрабатывается во время запуска или входа в систему. Так, например, предположим, что у вас есть двадцать подразделений верхнего уровня в вашем домене, и каждое подразделение верхнего уровня имеет под собой два подразделения более низкого уровня (одно для учетных записей пользователей и одно для учетных записей компьютеров), и что каждое подразделение имеет уникальный объект групповой политики, связанный с Это. Предположим также, что у вас есть только один объект групповой политики, привязанный к домену (политика домена по умолчанию), и нет объектов групповой политики, связанных с сайтом. Таким образом, всего у вас будет 20 + 40 + 1 = 61 объект групповой политики, что кажется очень много. Но для каждой конкретной комбинации пользователь/компьютер в процессе запуска/входа в систему будут обработаны только четыре объекта групповой политики: политика домена по умолчанию, объект групповой политики, связанный с OU верхнего уровня, и объекты групповой политики, связанные с двумя OU более низкого уровня, расположенными ниже верхнего уровня. уровень ОУ. Точнее, во время запуска обрабатываются три объекта групповой политики (политика домена по умолчанию, политика объекта групповой политики верхнего уровня и политика объекта групповой политики учетной записи компьютера), а во время входа в систему аналогичным образом обрабатываются три объекта групповой политики (политика домена по умолчанию, политика объекта групповой политики верхнего уровня и политика объекта групповой политики учетной записи пользователя). ). Таким образом, хотя у вас есть 61 объект групповой политики, немногие из них фактически обрабатываются для какого-либо конкретного пользователя или компьютера. Поэтому помните, что на самом деле важно не то, сколько у вас GPO, а то, сколько из них обрабатывается.

Во-вторых, утверждение о том, что время запуска/входа в систему «прямо пропорционально» количеству обработанных объектов групповой политики, также вводит в заблуждение. Что на самом деле происходит, так это то, что если x — это время входа в систему по умолчанию без обработанных объектов групповой политики, а y — время обработки любого одного объекта групповой политики, то общее время входа в систему составляет приблизительно x + Ny, где N — количество объектов групповой политики, обработанных во время входа в систему (то же самое относится для запуска, но мы сосредоточимся здесь на входе в систему для простоты). Однако эта формула является приблизительной, поскольку значение y может различаться для каждого объекта групповой политики. На самом деле, чем больше параметров политики вы включили или отключили в объекте групповой политики, тем больше значение y для этого объекта групповой политики. Кроме того, когда в объекте групповой политики настроено всего несколько параметров, значение y для этого объекта групповой политики обычно намного меньше, чем x, и в этом случае общее время входа в систему составляет всего x плюс немного больше, чем x+Ny.

Реальность

Что действительно влияет на время входа в систему, так это не то, сколько объектов групповой политики обрабатывается, а скорее то, сколько параметров настроено в каждом объекте групповой политики. Если во время входа в систему обрабатывается всего несколько объектов групповой политики, но для этих объектов групповой политики настроены сотни параметров, при этом конфликтующие параметры одного объекта групповой политики перезаписывают параметры другого объекта групповой политики во время обработки, то пользователи, вероятно, будут испытывать неприятные задержки входа в систему — по крайней мере, когда пользователи входят в систему. первый раз после того, как вы настроили большое количество параметров в GPO, которые они обрабатывают при входе в систему. Но даже при включенных или отключенных сотнях настроек в объекте групповой политики это может привести к отображению окна «Применение ваших личных настроек» только на несколько дополнительных секунд и, таким образом, добавить всего несколько секунд к процессу входа в систему, который обычно занимает несколько секунд в любом случае., так что даже наличие большого количества объектов групповой политики с большим количеством настроенных параметров не всегда будет вызывать гнев ваших пользователей и заставлять их жаловаться на то, что «сеть сегодня кажется медленной» и так далее.

Что еще более важно, чем количество объектов групповой политики, обрабатываемых во время запуска/входа в систему, и количество параметров, настроенных в этих объектах групповой политики, так это то, для чего предназначены параметры этих объектов групповой политики. Например, если вы настроите новый параметр «Перенаправление папок», то у пользователей, на которых настроен этот параметр, может возникнуть первоначальная задержка, поскольку их папки перенаправляются на сетевой файловый сервер. Или, если вы назначаете программное обеспечение с помощью объекта групповой политики, пользователи будут испытывать задержку запуска по мере установки новой программы. Но простые настройки безопасности или настройки блокировки рабочего стола обычно не вызывают чрезмерных задержек при запуске или входе в систему для пользователей.

Другие советы по повышению производительности

Еще одним фактором, который может существенно повлиять на время запуска или входа в систему, является размер обрабатываемых объектов групповой политики. Под размером объекта групповой политики я имею в виду количество и размер административных шаблонов (файлов.adm), которые вы импортировали в свои объекты групповой политики. Например, если вы управляете Microsoft Office с помощью групповой политики, то вы импортировали некоторые файлы офиса.adm в свои объекты групповой политики, и это может значительно увеличить размер объектов групповой политики и, следовательно, время, необходимое Windows для их обработки на клиентских компьютерах.. Таким образом, мораль здесь такова: импортируйте только те дополнительные файлы.adm в объекты групповой политики, которые нацелены на пользователей и компьютеры, которым действительно нужны эти настройки. Это особенно верно для удаленного управления настройками пользователей и компьютеров через медленную глобальную сеть, так как любой способ, которым вы можете минимизировать объем процессов групповой политики, которые вы можете выполнить через глобальные сети, определенно поможет удаленным пользователям избежать раздражающих задержек.

Еще один совет по повышению производительности, который может ускорить обработку групповой политики, заключается в отключении пользовательской или компьютерной части объекта групповой политики, если эта часть не требуется во время обработки. Например, если объект групповой политики связан с подразделением, которое содержит только учетные записи компьютеров и не содержит учетных записей пользователей, то нет причин включать пользовательскую часть этого объекта групповой политики, поскольку никакие параметры, настроенные в этой части, все равно не будут обрабатываться учетными записями компьютеров. Точно так же, если объект групповой политики связан с подразделением, которое содержит только учетные записи пользователей и не содержит учетных записей компьютеров, нет необходимости включать часть компьютера этого объекта групповой политики, поскольку никакие параметры, настроенные в этой части, не будут обрабатываться учетными записями пользователей. Чтобы отключить пользовательскую или компьютерную часть объекта групповой политики, выполните следующие действия.

1. Откройте консоль управления групповыми политиками (дополнительную информацию см. в этой статье на сайте WindowsSecurity.com) и расширяйте узел домена, пока не найдете ссылку на объект групповой политики.
2. Выберите вкладку «Сведения» на правой панели.
3. Щелкните раскрывающийся список GPO Status и выберите, следует ли отключать настройки пользователя или компьютера соответственно (см. рис. 1).

Рисунок 1. Отключение пользовательской части объекта групповой политики, предназначенной только для учетных записей компьютеров

Еще один совет по оптимизации обработки групповой политики: разумно используйте фильтры WMI. Я имею в виду следующее: фильтры WMI — это мощный инструмент, который позволяет нацеливать групповую политику на очень специфические вещи. Например, вы можете создать фильтр WMI, который будет применять определенный объект групповой политики только к тем компьютерам, которые работают под управлением процессора Pentium III, имеют 256 МБ ОЗУ или меньше и так далее. Несмотря на то, что фильтры WMI позволяют очень точно определить, как вы нацеливаете политику, вы должны понимать, что выполнение фильтра WMI для набора удаленных компьютеров может занять значительное время, поэтому лучше избегать использования этой расширенной функции групповой политики. если только у вас нет абсолютно веских причин для этого.

Наконец, если ваши клиентские машины работают под управлением Windows XP Professional, то по умолчанию на них включена оптимизация быстрого входа в систему (если только вы не используете перемещаемые профили пользователей, в этом случае эта функция отключена). Оптимизация быстрого входа в систему заставляет обработку запуска/входа в систему групповой политики вести себя точно так же, как фоновое обновление групповой политики, другими словами, асинхронно. Результатом включения оптимизации быстрого входа в систему на компьютерах с Windows XP является то, что пользователи смогут входить на свои компьютеры до того, как групповая политика завершит обработку. Причина, по которой эта функция была введена в XP, заключалась в том, чтобы решить проблему длительных задержек, с которыми часто сталкивались пользователи при входе в систему Windows 2000 Professional. Эти задержки были вызваны тем фактом, что Windows 2000 обрабатывала групповую политику синхронно во время запуска/входа в систему, что означало, что обработка политики компьютера должна была завершиться до отображения экрана входа в систему, а обработка пользовательской политики должна была быть завершена до того, как пользователь появился рабочий стол.

К сожалению, хотя оптимизация быстрого входа в систему сокращает время, необходимое пользователю для доступа к своему рабочему столу после загрузки компьютера, она может иметь некоторые негативные побочные эффекты. Совершенно очевидно, что если пользователь доберется до своего рабочего стола до того, как политика завершит обработку, он сможет ненадолго выполнить определенные действия, для предотвращения которых разработана политика. Например, вы можете включить политику, запрещающую пользователям доступ к панели управления, но если эта политика применяется через несколько секунд после появления их рабочего стола, у них может появиться короткое окно, в котором они могут получить доступ к своей панели управления. поражений вся цель политики, не так ли? Таким образом, хотя оптимизация быстрого входа в систему может значительно ускорить обработку групповой политики, она также может создать угрозу безопасности среды вашего рабочего стола, давая пользователям возможность выполнять действия, которые вы не хотите, чтобы они выполняли. Дополнительные сведения об этой функции и о том, как ее отключить, см. в этой статье базы знаний Майкрософт.