Виправлення неполадок помилок обробки групової політики в домені Active Directory

У учасників домену Active Directory (AD) можуть виникати проблеми із застосуванням групової політики з кількох причин. У цій статті обговорюються деякі з найпоширеніших із них і надаються вказівки щодо усунення основних проблем.
 
Загальне усунення
несправностейПершим кроком у вирішенні цих проблем має бути визначення їх ступеня. Якщо лише один комп'ютер не може обробити групову політику, проблема, ймовірно, пов'язана з несправністю або неправильною конфігурацією цього комп'ютера. Якщо проблема більш поширена, вона може існувати на контролері домену (DC) або в самому AD.

Якщо це стосується лише одного комп'ютера, запустіть gpupdate /force на ураженій машині перед подальшим усуненням несправностей. Це гарантує, що збій не був викликаний тимчасовою проблемою з мережею, яку з тих пір було вирішено.

Коли комп'ютер не в змозі обробити групову політику, він зазвичай генерує одну або кілька помилок Userenv у журналі програми. Поширені номери ідентифікаторів подій: 1030, 1053, 1054 і 1058. Описи конкретних помилок на ураженому комп'ютері повинні дати деяке уявлення про основну проблему.

Проблеми
з DNSМожливо, найпоширенішою причиною помилок групової політики та багатьох інших проблем із AD є проблема з розпізнаванням імен. Якщо помилки Userenv на ураженому комп'ютері включають фразу «Мережевий шлях не знайдено» або «Не вдається знайти контролер домену», можливо, винен DNS. Нижче наведено кілька порад щодо вирішення проблем такого типу:

• Відкрийте командний рядок на ураженому комп'ютері та запустіть nslookup домен (nslookup mydomain.local, наприклад). Ця команда має повертати IP-адреси всіх DC у домені. Якщо повертаються будь-які інші адреси, імовірно, у DNS є недійсні записи. Командою nslookup також можна скористатися для визначення імен окремих DC з їхніми IP-адресами.
• Бігти ipconfig /all на ураженому комп'ютері та переконайтеся, що він налаштований на використання лише внутрішніх DNS-серверів. Використання неправильних DNS-серверів є основною причиною проблем із DNS у домені, і її легко виправити. Усі комп'ютери, приєднані до домену, мають використовувати лише внутрішні DNS-сервери, які зазвичай є DC.
• Якщо здається, що уражений комп'ютер використовує правильні DNS-сервери, перевірте консоль DNS на DC, щоб переконатися, що існують належні записи. Переконайтеся, що кожен DC має два записи хоста (A) у зоні прямого пошуку домену: один із назвою хоста DC, а інший — з іменем «(те саме, що й батьківська папка)». Обидва записи повинні містити IP-адресу постійного струму.
• Після того, як проблему з DNS буде вирішено, запустіть ipconfig /flushdns на будь-яких уражених машинах. Це видалить усі недійсні дані з кешу резольвера на цих машинах.

Проблеми
з безпечним каналомЦей тип проблеми виникає, коли пароль локально збереженого комп'ютера комп'ютера, приєднаного до домену, не збігається з паролем у AD. Проблема із захищеним каналом перешкоджає автентифікації комп'ютера за допомогою постійного струму. Це часто проявляється як помилка «Доступ заборонено» щоразу, коли цей комп'ютер намагається отримати доступ до ресурсів домену, включно з оновленнями групової політики. Звичайно, не всі події «Відмовлено в доступі» пов'язані з проблемами безпечного каналу, але якщо уражена машина має помилки Userenv у журналі програм із написом «Доступ заборонено» в описі, захищений канал варто перевірити.

• Команду nltest можна використовувати для тестування (і скидання, якщо необхідно) захищеного каналу на учаснику домену.
• Об'єкт netdom Команда також може перевірити та скинути захищений канал.
• Командлет PowerShell Test-ComputerSecureChannel надає ще один засіб для тестування або скидання захищеного каналу.
• Видалення ураженого комп'ютера з домену, скидання його облікового запису комп'ютера AD і повторне приєднання до домену призведе до скидання його захищеного каналу. Однак це не завжди можливо.

Проблеми з SYSVOL
Файли шаблонів групової політики зберігаються у спільному ресурсі SYSVOL на всіх DC у домені. Дані SYSVOL реплікуються між DC за допомогою системи реплікації файлів (FRS) або розподіленої реплікації файлової системи (DFSR). Якщо спільний ресурс SYSVOL відсутній у постійному струмі, це, як правило, вказує на проблему з реплікацією SYSVOL.

Перекіс
годинникаТипово, автентифікація Kerberos вимагає, щоб годинники комп'ютерів, приєднаних до домену, знаходилися на відстані п'яти хвилин один від одного. Перевищення цього порогу спричиняє збій автентифікації, що, у свою чергу, перешкоджає обробці групової політики. Все в домені має бути налаштовано на синхронізацію його годинника з AD, за одним винятком. DC, який виконує роль емулятора PDC FSMO, є авторитетним джерелом часу для домену. Таким чином, це єдина машина в домені, яка повинна синхронізуватися із зовнішнім джерелом, таким як публічний сервер NTP.

Додаткові відомості про настроювання служби Windows Time можна знайти тут.

Відсутні файли
групової політикиМожливо, один або декілька файлів групової політики було видалено зі сховища у SYSVOL. Перевірте це, перейшовши до SYSVOL\domain\Policies у Файловому провіднику та знайшовши конкретні файли, згадані в помилках Userenv. Файли для кожного GPO зберігаються у підтеці теки Policies . Кожна вкладена папка має назву на честь шістнадцяткового глобально унікального ідентифікатора (GUID) GPO, файли якого вона містить.

Якщо виявиться, що файли правил відсутні в усіх DC, їх можна відновити з резервної копії. Якщо файли політики домену за замовчуванням або політики контролера домену за замовчуванням відсутні, а резервна копія недоступна, dcgpofix command може відновити обидві політики до типових параметрів.

Більше інформації про dcgpofix можна знайти тут.