Устранение неполадок при обработке групповой политики

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

Начните с основ

Прежде чем вы начнете использовать различные инструменты и методы устранения неполадок групповой политики, сделайте шаг назад и задайте несколько простых вопросов. Этот этап процесса устранения неполадок основан на лозунге, согласно которому минута размышлений стоит часа грубой силы. Ниже приведены несколько простых вопросов, которые вы должны задать себе, прежде чем погрузиться в процесс устранения неполадок.

1. Следует ли применять политику к затронутым пользователям и компьютерам? Это отличный вопрос для начала, не так ли? Скажем, пользователь приходит к вам и говорит, что не может установить определенное приложение, вызвав ярлык в меню «Пуск». Его соседние рабочие могут это сделать, но его машина должна быть сломана, потому что у него нет ярлыка для этой программы. Итак, он жалуется, а вы чешете голову, задаваясь вопросом, почему политика установки программного обеспечения, которая устанавливает эту программу, не применяется к этому пользователю. Но должно ли оно применяться в первую очередь? Что пользователь имеет в виду под своими «соседними работниками»? Возможно, другие сотрудники на том же этаже, но принадлежащие к другому отделу, и хотя пользователям в этом отделе нужна эта конкретная программа, у жалующегося пользователя нет и, возможно, не должно быть доступа к программе. Так что на самом деле групповая политика в этой ситуации работает просто отлично — сломлен пользователь ! Пользователи особенно завидуют привилегиям других пользователей, и в некоторых компаниях часто случаются такие тонкости. Ключевой вопрос по устранению неполадок здесь: «К кому должна применяться эта политика?
2. Что является общим для пользователей или компьютеров, к которым политика не применяется? Этот вопрос применим, если несколько человек или машин не получают политику, которую они должны получать. Пять человек из отдела маркетинга приходят к вам и жалуются, что больше не могут получить доступ к Панели управления из меню «Пуск». Что это говорит вам? Проверьте объект групповой политики, связанный с OU для пользователей Marketing, и проверьте, включена ли политика «Запретить доступ к панели управления» (эта политика находится в разделе «Конфигурация пользователяАдминистративные шаблоныПанель управления»). Если эта политика отключена или не настроена, проверьте объекты групповой политики, связанные с родительскими подразделениями в Marketing или связанные с доменом, и проверьте, не настроена ли по ошибке фильтрация безопасности, чтобы эта политика применялась к пользователям в группе безопасности Marketing.
3. Когда пользователи начали жаловаться на проблему? Было ли это сразу после того, как вы внесли некоторые изменения в настройки групповой политики, например, создав и связав новый объект групповой политики с OU? Это должно сказать вам что-то прямо сейчас. Или это произошло, когда вы внесли какие-то административные изменения в Active Directory, например, переместили некоторые учетные записи компьютеров из контейнера Computers по умолчанию в OU, созданную специально для таких учетных записей. В этом случае учетные записи компьютеров ранее получали свою политику от объектов групповой политики, связанных с доменом, но теперь любые объекты групповой политики, связанные с новым подразделением, также будут влиять на них. Или жалобы начали поступать на ровном месте, а вы несколько месяцев не вносили никаких изменений в GPO? В этом случае что-то еще мешает обработке групповой политики для затронутых пользователей или компьютеров, и вам нужно будет использовать некоторые из инструментов, описанных ниже, чтобы попытаться найти причину. Или, может быть, пользователи вообще не жаловались вам.
4. Когда вы на самом деле настроили рассматриваемую политику? В этой ситуации произошло то, что вы настроили политику, а затем проверили с целевыми пользователями, была ли применена политика или нет. Что ж, не забывайте, что групповая политика обновляется в фоновом режиме только периодически, так что, возможно, все в порядке, и вам просто нужно немного подождать, пока групповая политика обновится автоматически. Или, возможно, настроенная вами политика не может быть применена во время фонового обновления и требует от пользователя выхода и повторного входа в систему или перезагрузки компьютера. Примеры таких политик включают политику установки программного обеспечения, перенаправления папок и сценариев. В этом случае, чтобы убедиться, что новая политика обработана, вам придется подождать, пока пользователи не выйдут из системы в конце дня, отправить им электронное письмо с просьбой выйти из системы, а затем снова войти, или принудительно перезагрузить их машины удаленно и столкнуться с их проблемами. гнев, если они потеряют любую из своих работ. Или, может быть, вы настроили политику перенаправления папок, и пользователи перезагрузили свои машины, а политика все еще не применяется. В этом случае заданный ранее вопрос «Что у них общего?» может показать, что все затронутые пользователи работают на удаленном сайте и получают свою политику через подключение к глобальной сети от контроллеров домена в штаб-квартире компании. В этом случае может вступить в силу обработка медленных каналов для групповой политики, что снова может помешать обработке некоторых видов политик из-за ограничений пропускной способности каналов WAN.

Принесите инструменты

После того, как вы задали эти предварительные вопросы, которые необходимо задать, поскольку они часто могут точно определить проблему, но обычно помогают сузить область того, что вам нужно исследовать, пришло время начать тестирование с использованием различных инструментов, от ping до ведение журнала userenv. В короткой статье трудно осветить такую обширную тему, поэтому я просто дам вам несколько советов, которые направят вас в правильном направлении:

1. Проверьте сетевое подключение для затронутой машины. Возможно, не работает не только обработка групповой политики; возможно, затронутый пользователь не может даже подключиться к сети, потому что сетевой кабель для ее компьютера отключен! Удивительно, как такая простая вещь может стать источником того, что на первый взгляд кажется сложной проблемой. Ибо групповая политика довольно сложна в том, как она работает, и понимание того, как она работает, может помочь вам легче выявить проблемы. Хорошее объяснение того, как работает групповая политика, см. в новом руководстве по групповой политике от Microsoft Press, которое является частью недавно выпущенного набора ресурсов Microsoft Windows Server 2003. Я работал техническим редактором над этой книгой, и это отличный ресурс по всем аспектам групповой политики, который администраторы Windows обязательно должны иметь на своей книжной полке.
2. Проверьте, могут ли затронутые машины правильно выполнять разрешение DNS. Вероятно, половина всех проблем с обработкой групповой политики связана с проблемами DNS, такими как поврежденные записи ресурсов на DNS-серверах, неправильно настроенные параметры DHCP на DHCP-серверах, изменение пользователями настроек DNS на своих компьютерах и т. д. Помните, что для обработки групповой политики компьютер должен сначала получить список применимых к нему объектов групповой политики. Для этого им необходимо запросить контроллер домена. И чтобы найти контроллер домена, им нужны правильные настройки DNS клиента, чтобы они могли получать записи SRV, запрашивая DNS-сервер. Так что, если DNS не работает, то и групповая политика тоже. Инструменты для проверки и тестирования DNS включают ipconfig, nslookup, netdiag и Network Diagnostics в центре справки и поддержки.
3. Если вы используете консоль управления групповыми политиками (GPMC) для работы с групповой политикой, запустите мастер результатов групповой политики, указав затронутых пользователя и компьютер на страницах мастера. Это запросит WMI на затронутой машине и создаст отчет в формате HTML, в котором будет показано, какие объекты групповой политики были обработаны и какие параметры политики были применены. Вы можете сохранять эти отчеты и просматривать их на любом компьютере с помощью Internet Explorer, и это отличный способ устранения неполадок групповой политики. Альтернативой использованию мастера является запуск инструмента командной строки Gpresults.exe на уязвимой машине, см. статью Брайена Поузи на эту тему прямо здесь, на WindowsNetworking.com. Помимо создания отчетов RSoP, консоль управления групповыми политиками также может помочь вам в устранении неполадок групповой политики другими способами. Например, если щелкнуть правой кнопкой мыши объект групповой политики, можно выбрать «Сохранить отчет», чтобы создать отчет в формате HTML, показывающий все настроенные параметры объекта групповой политики. Это позволяет легко выяснить, какое влияние конкретный объект групповой политики на самом деле оказывает на учетные записи в контейнере, с которым он связан, — это намного проще, чем открывать объект групповой политики в редакторе объектов групповой политики и развертывать все узлы, чтобы увидеть, какие политики настроен. Еще одно преимущество консоли управления групповыми политиками по сравнению с готовыми инструментами групповой политики, включенными в Windows Server 2003, заключается в том, что вы можете легко увидеть, какие объекты групповой политики и где связаны, а какие отключены, в каких контейнерах настроена блокировка наследования, какие ссылки объектов групповой политики применяются принудительно., и так далее. Получите консоль управления групповыми политиками сегодня с веб-сайта Microsoft и используйте ее для управления групповой политикой в вашей сети.

Вывод

Есть много других способов устранения неполадок групповой политики, но приведенные выше советы должны помочь вам начать работу и решить большую часть проблем, которые могут возникнуть. Более продвинутые пользователи могут захотеть включить подробное ведение журнала для Userenv.dll (механизм групповой политики), что описано в статье 221833 базы знаний Майкрософт (в статье объясняется, как включить подробное ведение журнала, но не объясняется, как интерпретировать такие журналы — для этого см. Руководство по групповой политике от Microsoft Press). Вы также можете использовать Event Viewer для проверки событий Userenv в журнале приложений, но мы все знаем, насколько загадочными могут быть события журнала событий Windows (хороший источник информации о событиях журнала событий можно найти на EventID.Net, проекте сообщества). для составления подробной справочной информации о загадочных событиях). И, наконец, вы можете выполнить поиск или просмотреть базу знаний на TechNet и найти малоизвестные статьи, подобные этой, в которых говорится, что обработка групповой политики завершается сбоем, когда клиент DFS отключен или когда разрешение на чтение и выполнение для группы «Все» удаляется из корня системы. раздел — всего лишь один из тех малоизвестных кусочков информации, которые вы, возможно, захотите сохранить в своем и без того переполненном мозгу на черный день.