Виправлення неполадок помилок обробки групової політики в домені 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 також можна використовувати для визначення імен окремих ДЦ за їхніми 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, який виконує роль FSMO емулятора PDC, є авторитетним джерелом часу для домену. Тому це єдина машина в домені, яка повинна синхронізуватися із зовнішнім джерелом, таким як публічний сервер NTP.

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

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

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

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