Не удалось проверить лес active directory ошибка 58

Один из механизмов Active Directory (AD), с которым могут быть связаны всевозможные затруднения, это репликация. Репликация – критически важный процесс в работе одного или более доменов или контроллеров домена (DC), и не важно, находятся они на одном сайте или на разных. Неполадки с репликацией могут привести к проблемам с аутентификацией и доступом к сетевым ресурсам. Обновления объектов AD реплицируются на контроллеры домена, чтобы все разделы были синхронизированы. В крупных компаниях использование большого количества доменов и сайтов – обычное дело. Репликация должна происходить внутри локального сайта, так же как дополнительные сайты должны сохранять данные домена и леса между всеми DC.

В этой статье речь пойдет о методах выявления проблем с репликацией в AD. Кроме того, я покажу, как находить и устранять неисправности и работать с четырьмя наиболее распространенными ошибками репликации AD:

• Error 2146893022 (главное конечное имя неверно);
• Error 1908 (не удалось найти контроллер домена);
• Error 8606 (недостаточно атрибутов для создания объекта);
• Error 8453 (доступ к репликации отвергнут).

Вы также узнаете, как анализировать метаданные репликации с помощью таких инструментов, как AD Replication Status Tool, встроенная утилита командной строки RepAdmin.exe и Windows PowerShell.

Для всестороннего рассмотрения я буду использовать лес Contoso, который показан на рисунке. В таблице 1 перечислены роли, IP-адреса и настройки DNS-клиента для компьютеров данного леса.

Рисунок. Архитектура леса

Для обнаружения неполадок с репликацией AD запустите AD Replication Status Tool на рабочей станции администратора в корневом домене леса. Например, вы открываете этот инструмент из системы Win8Client, а затем нажимаете кнопку Refresh Replication Status для уверенности в четкой коммуникации со всеми контроллерами домена. В таблице Discovery Missing Domain Controllers на странице Configuration/Scope Settings инструмента можно увидеть два недостающих контроллера домена, как показано на экране 1.

Экран 1. Два недостающих контроллера домена

В таблице Replication Status Collection Details вы можете проследить статус репликации контроллеров домена, которые никуда не пропадали, как показано на экране 2.

Экран 2. Статус репликации контроллеров домена

Пройдя на страницу Replication Status Viewer, вы обнаружите некоторые ошибки в репликации. На экране 3 видно, что возникает немалое число ошибок репликации, возникающих в лесу Contoso. Из пяти контроллеров домена два не могут видеть другие DC, а это означает, что репликация не будет происходить на контроллерах домена, которые не видны. Таким образом, пользователи, подключающиеся к дочерним DC, не будут иметь доступ к самой последней информации, что может привести к проблемам.

Экран 3. Ошибки репликации, возникающие в лесу Contoso

Поскольку ошибки репликации все же возникают, полезно задействовать утилиту командной строки RepAdmin.exe, которая помогает получить отчет о состоянии репликации по всему лесу. Чтобы создать файл, запустите следующую команду из Cmd.exe:

Repadmin /showrel * /csv > ShowRepl.csv

Проблема с двумя DC осталась, соответственно вы увидите два вхождения LDAP error 81 (Server Down) Win32 Err 58 на экране, когда будет выполняться команда. Мы разберемся с этими ошибками чуть позже. А теперь откройте ShowRepl.csv в Excel и выполните следующие шаги:

1. Из меню Home щелкните Format as table и выберите один из стилей.
2. Удерживая нажатой клавишу Ctrl, щелкните столбцы A (Showrepl_COLUMNS) и G (Transport Type). Правой кнопкой мыши щелкните в этих столбцах и выберите Hide.
3. Уменьшите ширину остальных столбцов так, чтобы был виден столбец K (Last Failure Status).
4. Для столбца I (Last Failure Time) нажмите стрелку вниз и отмените выбор 0.
5. Посмотрите на дату в столбце J (Last Success Time). Это последнее время успешной репликации.
6. Посмотрите на ошибки в столбце K (Last Failure Status). Вы увидите те же ошибки, что и в AD Replication Status Tool.

Таким же образом вы можете запустить средство RepAdmin.exe из PowerShell. Для этого сделайте следующее:

1. Перейдите к приглашению PowerShell и введите команду

Repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView

2. В появившейся сетке выберите Add Criteria, затем Last Failure Status и нажмите Add.

3. Выберите подчеркнутое слово голубого цвета contains в фильтре и укажите does not equal.

4. Как показано на экране 4, введите 0 в поле, так, чтобы отфильтровывалось все со значением 0 (успех) и отображались только ошибки.

Экран 4. Задание фильтра

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

Исправление ошибки AD Replication Error -2146893022

Итак, начнем с устранения ошибки -2146893022, возникающей между DC2 и DC1. Из DC1 запустите команду Repadmin для проверки статуса репликации DC2:

Repadmin /showrepl dc2

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

Экран 5. Проблема с DC2 — целевое основное имя неверно

Во-первых, следует определить, есть ли базовое подключение LDAP между системами. Для этого запустите следующую команду из DC2:

Repadmin /bind DC1

На экране 5 видно, что вы получаете сообщение об ошибке LDAP. Далее попробуйте инициировать репликацию AD с DC2 на DC1:

Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»

И на этот раз отображается та же ошибка с главным именем, как показано на экране 5. Если открыть окно Event Viewer на DC2, вы увидите событие с Event ID 4 (см. экран 6).

Экран 6. Сообщение о событии с Event ID 4

Выделенный текст в событии указывает на причину ошибки. Это означает, что пароль учетной записи компьютера DC1 отличается от пароля, который хранится в AD для DC1 в Центре распределения ключей – Key Distribution Center (KDC), который в данном случае запущен на DC2. Значит, следующая наша задача – определить, соответствует ли пароль учетной записи компьютера DC1 тому, что хранится на DC2. В командной строке на DC1 введите две команды:

Repadmin /showobjmeta dc1 «cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com» > dc1objmeta1.txt

Repadmin /showobjmeta dc2 «cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com» > dc1objmeta2.txt

Далее откройте файлы dc1objmeta1.txt и dc1objmeta2.txt, которые были созданы, и посмотрите на различия версий для dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet и lmPwdHistory. В нашем случае файл dc1objmeta1.txt показывает версию 19, тогда как версия в файле dc1objmeta2.txt – 11. Таким образом, сравнивая эти два файла, мы видим, что DC2 содержит информацию о старом пароле для DC1. Операция Kerberos не удалась, потому что DC1 не смог расшифровать билет службы, представленный DC2.

KDC, запущенный на DC2, не может быть использован для Kerberos вместе с DC1, так как DC2 содержит информацию о старом пароле. Чтобы решить эту проблему, вы должны заставить DC2 использовать KDC на DC1, чтобы завершить репликацию. Для этого вам, в первую очередь, необходимо остановить службу KDC на DC2:

Net stop kdc

Теперь требуется начать репликацию корневого раздела Root:

Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»

Следующим вашим шагом будет запуск двух команд Repadmin /showobjmeta снова, чтобы убедиться в том, что версии совпадают. Если все хорошо, вы можете перезапустить службу KDC:

Net start kdc

Обнаружение и устранение ошибки AD Replication Error 1908

Теперь, когда мы устранили ошибку -2146893022, давайте перейдем к ошибке репликации AD 1908, где DC1, DC2 и TRDC1 так и не удалось выполнить репликацию из ChildDC1. Решить проблему можно следующим образом. Используйте Nltest.exe для создания файла Netlogon.log, чтобы выявить причину ошибки 1908. Прежде всего, включите расширенную регистрацию на DC1, запустив команду:

Nltest /dbflag:2080fff

Теперь, когда расширенная регистрация включена, запустите репликацию между DC – так все ошибки будут зарегистрированы. Этот шаг поможет запустить три команды для воспроизведения ошибок. Итак, во-первых, запустите следующую команду на DC1:

Repadmin /replicate dc1 childdc1 dc=child,dc=root,
dc=contoso,dc=com

Результат, показанный на экране 7, говорит о том, что репликация не состоялась, потому что DC домена не может быть найден.

Экран 7. Репликация не состоялась, потому что DC домена не может быть найден

Во-вторых, из DC1 попробуйте определить местоположение KDC в домене child.root.contoso.com с помощью команды:

Nltest /dsgetdc:child /kdc

Результаты на экране 7 свидетельствуют, что такого домена нет. В-третьих, поскольку вы не можете найти KDC, попытайтесь установить связь с любым DC в дочернем домене, используя команду:

Nltest /dsgetdc:child

В очередной раз результаты говорят о том, что нет такого домена, как показано на экране 7.

Теперь, когда вы воспроизвели все ошибки, просмотрите файл Netlogon.log, созданный в папке C:Windowsdebug. Откройте его в «Блокноте» и найдите запись, которая начинается с DSGetDcName function called. Обратите внимание, что записей с таким вызовом будет несколько. Вам нужно найти запись, имеющую те же параметры, что вы указали в команде Nltest (Dom:child и Flags:KDC). Запись, которую вы ищете, будет выглядеть так:

DSGetDcName function called: client PID=2176,
Dom:child Acct:(null) Flags:KDC

Вы должны просмотреть начальную запись, равно как и последующие, в этом потоке. В таблице 2 представлен пример потока 3372. Из этой таблицы следует, что поиск DNS записи KDC SRV в дочернем домене был неудачным. Ошибка 1355 указывает, что заданный домен либо не существует, либо к нему невозможно подключиться.

Поскольку вы пытаетесь подключиться к Child.root.contoso.com, следующий ваш шаг – выполнить для него команду ping из DC1. Скорее всего, вы получите сообщение о том, что хост не найден. Информация из файла Netlogon.log и ping-тест указывают на возможные проблемы в делегировании DNS. Свои подозрения вы можете проверить, сделав тест делегирования DNS. Для этого выполните следующую команду на DC1:

Dcdiag /test:dns /dnsdelegation > Dnstest.txt

На экране 8 показан пример файла Dnstest.txt. Как вы можете заметить, это проблема DNS. Считается, что IP-адрес 192.168.10.1 – адрес для DC1.

Экран 8. Пример файла Dnstest.txt

Чтобы устранить проблему DNS, сделайте следующее:

1. На DC1 откройте консоль управления DNS.

2. Разверните Forward Lookup Zones, разверните root.contoso.com и выберите child.

3. Щелкните правой кнопкой мыши (как в родительской папке) на записи Name Server и выберите пункт Properties.

4. Выберите lamedc1.child.contoso.com и нажмите кнопку Remove.

5. Выберите Add, чтобы можно было добавить дочерний домен сервера DNS в настройки делегирования.

6. В окне Server fully qualified domain name (FQDN) введите правильный сервер childdc1.child.root.contoso.com.

7. В окне IP Addresses of this NS record введите правильный IP-адрес 192.168.10.11.

8. Дважды нажмите кнопку OK.

9. Выберите Yes в диалоговом окне, где спрашивается, хотите ли вы удалить связующую запись (glue record) lamedc1.child.contoso.com [192.168.10.1]. Glue record – это запись DNS для полномочного сервера доменных имен для делегированной зоны.

10. Используйте Nltest.exe для проверки, что вы можете найти KDC в дочернем домене. Примените опцию /force, чтобы кэш Netlogon не использовался:

Nltest /dsgetdc:child /kdc /force

11. Протестируйте репликацию AD из ChildDC1 на DC1 и DC2. Это можно сделать двумя способами. Один из них – выполнить команду

Repadmin /replicate dc1 childdc1 «dc=child,dc=root,
dc=contoso,dc=com»

Другой подход заключается в использовании оснастки Active Directory Sites и Services консоли Microsoft Management Console (MMC), в этом случае правой кнопкой мыши щелкните DC и выберите Replicate Now, как показано на экране 9. Вам нужно это сделать для DC1, DC2 и TRDC1.

Экран 9. Использование оснастки Active Directory Sites и?Services

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

Экран 10. Ошибка при репликации

Когда все шаги выполнены, вернитесь к AD Replication Status Tool и обновите статус репликации на уровне леса. Ошибки 1908 больше быть не должно. Ошибка, которую вы видите, это ошибка 8606 (недостаточно атрибутов для создания объекта), как отмечалось на экране 10. Это следующая трудность, которую нужно преодолеть.

Устранение ошибки AD Replication Error 8606

Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).

Чтобы устранить проблему, в первую очередь убедитесь в наличии ошибки, выполнив следующую команду Repadmin на DC1:

Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»

Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.

Экран 11. Ошибка из-за наличия устаревшего объекта

Экран 12. Событие с кодом 1988

Вы должны скопировать три пункта из информации об ошибке 1988 в событиях: идентификатор globally unique identifier (GUID) устаревшего объекта, сервер-источник (source DC), а также уникальное, или различающееся, имя раздела – distinguished name (DN). Эта информация позволит определить, какой DC имеет данный объект.

Прежде всего, используйте GUID объекта (в данном случае 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) в следующей команде Repadmin, которая отправляет результаты в файл Objects.txt:

Repadmin /showobjmeta * «e8bd5af127d8>» > Objects.txt

Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. DC, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).

Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. DSA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:

Repadmin /showrepl DC1 > Showrepl.txt

В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:

DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e

Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.

Repadmin /removelingeringobjects DC2 70ff33ce-2f41-4bf4-
b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com»
/Advisory_mode

Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.

Вы можете удалить устаревшие объекты несколькими способами. Предпочтительно использовать ReplDiag.exe. В качестве альтернативы вы можете выбрать RepAdmin.exe.

Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:

Repldiag /removelingeringobjects
Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»

Первая команда удаляет объекты. Вторая команда служит для проверки успешного завершения репликации (иными словами, ошибка 8606 больше не регистрируется). Возвращая команды Repadmin /showobjmeta, вы можете убедиться в том, что объект был удален из всех, что объект был удален DC. Если у вас есть контроллер только для чтения read-only domain controller (RODC) и он содержал данный устаревший объект, вы заметите, что он все еще там находится. Дело в том, что текущая версия ReplDiag.exe не удаляет объекты из RODC. Для очистки RODC (в нашем случае, ChildDC2) выполните команду:

Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=root,dc=contoso,dc=com» /Advisory_mode

После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.

Экран 13. Сообщение об удалении устаревших объектов

Используем RepAdmin.exe. Другой способ, позволяющий удалить устаревшие объекты – прибегнуть к помощи RepAdmin.exe. Сначала вы должны удалить устаревшие объекты главных контроллеров домена (reference DC) с помощью кода, который видите в листинге 1. После этого необходимо удалить устаревшие объекты из всех остальных контроллеров домена (устаревшие объекты могут быть показаны или на них могут обнаружиться ссылки на нескольких контроллерах домена, поэтому убедитесь, что вы удалили их все). Необходимые для этой цели команды приведены в листинге 2.

Как видите, использовать ReplDiag.exe гораздо проще, чем RepAdmin.exe, поскольку вводить команд вам придется намного меньше. Ведь чем больше команд, тем больше шансов сделать опечатку, пропустить команду или допустить ошибку в командной строке.

Устранение ошибки AD Replication Error 8453

Предыдущие ошибки репликации AD были связаны с невозможностью найти другие контроллеры домена. Ошибка репликации AD с кодом состояния 8453 возникает, когда контроллер домена видит другие DC, но не может установить с ними связи репликации.

Например, предположим, что ChildDC2 (RODC) в дочернем домене не уведомляет о себе как о сервере глобального каталога – Global Catalog (GC). Для получения статуса ChildDC2 запустите следующие команды на ChildDC2:

Repadmin /showrepl childdc2 > Repl.txt

Данная команда отправляет результаты Repl.txt. Если вы откроете этот текстовый файл, то увидите вверху следующее:

BoulderChildDC2
DSA Options: IS_GC DISABLE_OUTBOUND_REPL IS_RODC
WARNING: Not advertising as a global catalog

Если вы внимательно посмотрите на раздел Inbound Neighbors, то увидите, что раздел DC=treeroot,DC=fabrikam,DC=com отсутствует, потому что он не реплицируется. Взгляните на кнопку файла – вы увидите ошибку:

Source: BoulderTRDC1
******* 1 CONSECTUTIVE FAILURES since 2014-01-12 11:24:30
Last error: 8453 (0x2105):
Replication access was denied
Naming Context: DC=treeroot,DC=fabrikam,DC=com

Эта ошибка означает, что ChildDC2 не может добавить связь репликации (replication link) для раздела Treeroot. Как показано на экране 14, данная ошибка также записывается в журнал регистрации событий Directory Services на ChildDC2 как событие с кодом 1926.

Экран 14. Отсутствие связи репликации

Здесь вам нужно проверить, нет ли проблем, связанных с безопасностью. Для этого используйте DCDiag.exe:

Dcdiag /test:checksecurityerror

На экране 15 показан фрагмент вывода DCDiag.exe.

Экран 15. Фрагмент вывода DCDiag.exe

Как видите, вы получаете ошибку 8453, потому что группа безопасности Enterprise Read-Only Domain Controllers не имеет разрешения Replicating Directory Changes.

Чтобы решить проблему, вам нужно добавить отсутствующую запись контроля доступа – missing access control entry (ACE) в раздел Treeroot. В этом вам помогут следующие шаги:

1. На TRDC1 откройте оснастку ADSI Edit.

2. Правой кнопкой мыши щелкните DC=treeroot,DC=fabrikam,DC=com и выберите Properties.

3. Выберите вкладку Security.

4. Посмотрите разрешения на этот раздел. Отметьте, что нет записей для группы безопасности Enterprise Read-Only Domain Controllers.

5. Нажмите Add.

6. В окне Enter the object names to select наберите ROOTEnterprise Read-Only Domain Controllers.

7. Нажмите кнопку Check Names, затем выберите OK, если указатель объектов (object picker) разрешает имя.

8. В диалоговом окне Permissions для Enterprise Read-Only Domain Controllers снимите флажки Allow для следующих разрешений

*Read

*Read domain password & lockout policies («Чтение политики блокировки и пароля домена»)

*Read Other domain parameters

9. Выберите флажок Allow для разрешения Replicating Directory Changes, как показано на экране 16. Нажмите OK.

10. Вручную запустите Knowledge Consistency Checker (KCC), чтобы немедленно сделать перерасчет топологии входящей репликации на ChildDC2, выполнив команду

Repadmin /kcc childdc2

Экран 16. Включение разрешения Replicating Directory Change

Данная команда заставляет KCC на каждом целевом сервере DC незамедлительно делать перерасчет топологии входящей репликации, добавляя снова раздел Treeroot.

Состояние репликации критически важно

Репликация во всех отношениях в лесу AD имеет решающее значение. Следует регулярно проводить ее диагностику, чтобы изменения были видны всем контроллерам домена, иначе могут возникать различные проблемы, в том числе связанные с аутентификацией. Проблемы репликации нельзя обнаружить сразу. Поэтому если вы пренебрегаете мониторингом репликации (в крайнем случае, периодически делайте проверку), то рискуете столкнуться с трудностями в самый неподходящий момент. Моей задачей было показать вам, как проверять статус репликации, обнаруживать ошибки и в то же время как справиться с четырьмя типичными проблемами репликации AD.

REM Команды для удаления устаревших объектов
REM из раздела Configuration.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«cn=configuration,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела ForestDNSZones.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.
root.contoso.com 0b457f73-96a4-429b-ba81-
1a3e0f51c848 «dc=forestdnszones,dc=root,
dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена Root.
Repadmin /removelingeringobjects dc1.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones.
Repadmin /removelingeringobjects dc1.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=root,dc=contoso,dc=com»

REM Команды для удаления устаревших объектов
REM из раздела Configuration.
Repadmin /removelingeringobjects dc1.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела ForestDNSZones.
Repadmin /removelingeringobjects dc1.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones–Root.
Repadmin /removelingeringobjects dc2.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=domaindnszones,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена Child.
Repadmin /removelingeringobjects dc1.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones-Child.
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=domaindnszones,dc=child,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена TreeRoot.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects dc1.root.contoso.com
0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.com
0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»

Active Directory это надежный, но в то же время крайне сложный и критичный сервис, от работоспособности которого зависит работа всей вашей сети. Системный администратор должен постоянно мониторить корректность работы Active Directory. В этой статье мы рассмотрим основные методики, позволяющие вам быстро проверить и диагностировать состояние вашего домена Active Directory, контроллеров домена и репликации.

Проверка состояния контроллеров домена с помощью Dcdiag

Базовая встроенная утилита для проверки состояния контролеров домена – dcdiag.

Чтобы быстро проверить состояние конкретного контроллера домена AD воспользуйтесь командой:

Данная команда выполняет различные тесты указанного контроллера домена и возвращает статус по каждому тесту (Passed| Failed).

Помимо стандартных тестов, которые выполняются по-умолчанию, можно выполнить дополнительные проверки контроллера домена:

Например, чтобы проверить корректность работы DNS на всех контроллерах домена, используйте команду:

dcdiag.exe /s:DC01 /test:dns /e /v

В результате должна появится сводная таблица по проверкам разрешения имен службой DNS на всех контроллерах (если все ОК, везде должно быть Pass). Если где-то будет указано Fail, нужно выполнить проверку этого теста на указанном DC:

dcdiag.exe /s:DC01 /test:dns /DnsForwarders /v

Чтобы получить расширенную информацию по результатам тестов контроллера домена и сохранить ее в текстовый файл, используйте команду:

dcdiag /s:DC01 /v >> c:psdc01_dcdiag_test.log

Чтобы получить состояние всех контроллеров домена, используйте:

dcdiag.exe /s:winitpro.ru /a

Если нужно вывести только найденные ошибки, используйте параметр /q:

В моем примере утилита обнаружила ошибки репликации:

Чтобы утилита dcdiag попробовала автоматически исправить ошибки в Service Principal Names для данной учетной записи DC, используйте параметр /fix:

dcdiag.exe /s:dc01 /fix

Проверка ошибок репликации между контроллерами домена Active Directory

Для проверки репликации в домене используется встроенная утилита repadmin.

Базовая команда проверки репликации:

Утилита вернула текущий статус репликации между всеми DC. В идеальном случае значение largest delta не должно превышать 1 час (зависит от топологии и настроек частоты межсайтовых репликаций), а количество ошибок = 0. В моем примере видно, что одна из последних репликаций заняла 14 дней, но сейчас все OK.

Чтобы выполнить проверку для всех DC в домене:

Проверку межсайтовой репликции можно выполнить так:

Для просмотра топологии репликации и найденных ошибках, выполните:

Данная команда проверит DC и вернет время последней успешной репликации для каждого раздела каталога (last attempt xxxx was successful).

Для запуска репликации паролей с обычного контроллера домена на контроллер домена на чтение (RODC) используется ключ /rodcpwdrepl.

Опция /replicate позволяет запустить немедленную репликацию указанного раздела каталога на определенный DC.

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

Для просмотра очереди репликации:

В идеальном случае очередь должна быть пуста:

Вы также можете проверить состояние репликации с помощью PowerShell. Например, следующая команда выведет все обнаруженные ошибки репликации в таблицу Out-GridView:

Итак, в этой статье мы рассмотрели базовые команды и скрипты, которые можно использовать для диагностики состояния вашего домена Active Directory. Вы можете использовать их во всех поддерживаемых версия Windows Server, в том числе на контроллерах домена в режиме Server Core.

Источник

Ошибки DNS-сервера и, возможно, репликации

Всем доброго времени суток.

В организации 1 домен 3 контролера. Репликация настроена так, что 1-главный контролер, а 2 и 3 синхронизируют себя с него. Контролер 1 и 2 работают без проблем, а на контролере 3 возникают ошибки.

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = hdc
* Определен лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

DNS: список уведомления об обновлении зоны 8.168.192.in-addr.arpa не должен быть пустым.

Дата:
23.03.2016 5:51:29

Проблема:
Список серверов, получающих уведомления об обновлении зоны 8.168.192.in-addr.arpa, пуст.

Воздействие:
Дополнительные серверы зоны 8.168.192.in-addr.arpa не будут получать уведомления об изменениях записей зоны.

Разрешение
Добавьте дополнительные серверы в список уведомления об обновлении зоны 8.168.192.in-addr.arpa.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Возможно ли найти все DNS сервера
Возможно ли найти все DNS сервера в интернете и все сайты, на них расположенные?

Код ошибки: DNS_PROBE_FINISHED_NXDOMAIN: Неверный DNS-адрес сервера
С недавнего времени перестал открываться один сайт, выдает вот эту ошибку. Остальные сайты.

Нет репликации между DNS серверами
В организации был 1 контролер домена + днс сервер. Развернул второй контролер домена + еще один dns.

Какие ошибки в журнале «Служба репликации файлов» на проблемном DC?
На проблемном DC запущена служба NetLogon?

Что показывает на проблемном DC:

net sahre
ipconfig /all (с проблемного и рабочего КД)
dcdiag /test:registerindns /dnsdomain:evm.ru

На сайте сапорта мелкомягких мне подсказали изменить параметр

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = hdc
* Определен лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Источник

Не пройдена проверка dfsrevent windows server 2019

Вопрос

Был AD+DNS на сервере 2008r2 было так же зеркало его на 2008r2, надоел 2008, снес зеркало по правилам, поставил туда 2012, завел в домен все поднял, все перенес на 2012, все было ок. Начал выводить первичный 2008, дабы потом сделать из него зеркало 2012, все вывел без особых проблем. Сейчас имею один сервер на 2012r2, на нем AD DS и все, GPO не работают, ссылаются на сервер 2008, все перерыл. но как то ответов не нашел. Подскажите, как поправить?

Запуск проверки: DFSREvent
The DFS Replication Event Log.
За последние 24 часа после предоставления SYSVOL в общий доступ зафиксированы предупреждения или сообщения об
ошибках. Сбои при репликации SYSVOL могут стать причиной проблем групповой политики.
Возникла ошибка. Код события (EventID): 0xC0001390
Время создания: 10/26/2016 20:27:12
Строка события:
Службе репликации DFS не удалось установить подключение к партнеру DC01 по группе репликации Domain System V
Причиной этой ошибки может быть недоступный узел или незапущенная служба репликации DFS на сервере.

DNS-адрес партнера: DC01

Доступные дополнительные сведения:
WINS-адрес партнера: DC01
IP-адрес партнера: 192.168.0.252

Дополнительные сведения:
Ошибка: 1722 (Сервер RPC недоступен.)
Идентификатор подключения: C1E4CE7C-C826-4704-8E6C-AF79F78E7633
Идентификатор группы репликации: 62D4EBDE-8644-4D5C-A4F6-145B940054C9
Возникла ошибка. Код события (EventID): 0xC0001204
Время создания: 10/26/2016 20:27:12
Строка события:
Служба репликации DFS инициализировала SYSVOL по локальному пути C:WindowsSYSVOLdomain и готова к начальн
ой репликации. Реплицированная папка останется в состоянии начальной синхронизации до выполнения репликации со своим пар
тнером DC01.centrzaimow.ru. Если в это время выполнялось назначение сервера контроллером домена, контроллер домена не бу
дет делать объявления и функционировать как контроллер домена, пока данная проблема не будет решена. Это могло произойти
, если указанный партнер также находится в состоянии начальной синхронизации или обнаружены нарушения общего доступа на
этом сервере или партнере синхронизации. Если данное событие произошло в результате миграции SYSVOL от службы репликации
файлов (FRS) к репликации DFS, изменения не будут реплицироваться до тех пор, пока эта проблема не будет решена. В резу
льтате этого папка SYSVOL на данном сервере может стать не синхронизированной с другими контроллерами домена.

Дополнительные сведения:
Имя реплицированной папки: SYSVOL Share
Идентификатор реплицированной папки: 16436010-64BE-4887-A2F6-F223C202E21D
Имя группы репликации: Domain System Volume
Идентификатор группы репликации: C1E4CE7C-C826-4704-8E6C-AF79F78E7633
Код участника: DD6381F6-C200-4BA0-BBD6-0EB3D58BAD54
Только для чтения: 0
Возникла ошибка. Код события (EventID): 0xC0001390
Время создания: 10/27/2016 04:30:54
Строка события:
Службе репликации DFS не удалось установить подключение к партнеру DC01 по группе репликации Domain System V
olume. Причиной этой ошибки может быть недоступный узел или незапущенная служба репликации DFS на сервере.

DNS-адрес партнера: DC01

Доступные дополнительные сведения:
WINS-адрес партнера: DC01
IP-адрес партнера: 192.168.0.252

Служба периодически будет пытаться установить подключение.

Очень странно, но папки ADnetlogon тупо нет!

PS C:Windowssystem32> dcdiag /test:dns

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = AD
* Определен лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Сервер проверки: Default-First-Site-NameAD

Запуск проверки: DNS

Выполнение проверок разделов на: DomainDnsZones

Выполнение проверок разделов на: ForestDnsZones

Выполнение проверок разделов на: Schema

Выполнение проверок разделов на: Configuration

Выполнение проверок разделов на: ххх

Выполнение проверок предприятия на: ххх.ru
Запуск проверки: DNS
Результаты проверки контроллеров домена:

Контроллер домена: AD.ХХХ.ru
Домен: ххх.ru

TEST: Dynamic update (Dyn)
Warning: Failed to delete the test record dcdiag-test-record in zone ххх.ru

Источник

Не пройдена проверка dfsrevent windows server 2019

Давайте начнем с ipconfig /all с обеих серверов и dcdiag

ipconfig /all:

Server1C:

Настройка протокола IP для Windows

Адаптер PPP RAS (Dial In) Interface:

Ethernet adapter Link to PublicGTW:

Ethernet adapter Link to LAN:

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

Victory (ранее WinDC, TempDC, DC1C):

Настройка протокола IP для Windows

Ethernet adapter LAN:

На Victory всего два туннельных интерфейса.
Так же есть ещё один интерфейс, который в дальнейшем будет смотреть так же в другую сеть, как и на Server1C. На текущий момент он отключен.

dcdiag:

Server1C:

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = Server1C
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Про проблемы с диском знаю.

Victory:

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = Victory
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Ребутнул Victory, ещё раз запустил dcdiag, после рестарта ошибок стало больше:

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = Victory
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Источник

Не пройдена проверка dfsrevent windows server 2019

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = ServerArchive
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Покажите вывод команды

dcdiag /test:registerindns /dnsdomain:xxx.ru

C:UsersАдминистратор.ххх.000>dcdiag /test:registerindns /dnsdomain:ххх.ru
Запуск проверки: RegisterInDNS
Конфигурация DNS достаточна, чтобы позволить данному контроллеру домена
динамически регистрировать в DNS записи локатора контроллера домена.

Конфигурация DNS достаточна, чтобы позволить данному компьютеру
динамически регистрировать A-запись, соответствующую его DNS-имени.

Microsoft Windows [Версия 6.0.6002]
(C) Корпорация Майкрософт, 2006. Все права защищены.

Диагностика сервера каталогов

Выполнение начальной настройки:
Выполняется попытка поиска основного сервера.
Основной сервер = ServerArchive
* Идентифицирован лес AD.
Сбор начальных данных завершен.

Выполнение обязательных начальных проверок

Выполнение основных проверок

Источник

Как узнать режим работы леса и режим работы домена Active Directory

Как узнать режим работы леса и режим работы домена Active Directory

Как узнать режим работы леса и режим работы домена Active Directory-01

Всем привет сегодня хочу рассказать как узнать режим работы леса и режим работы домена Active Directory. Режимы работы определяют доступные возможности домена или леса доменных служб Active Directory. Они также определяют версии операционных систем Windows Server, которые можно использовать на контроллерах домена в домене или в лесу. Но режимы работы не влияют на то, какие операционные системы могут использоваться на рабочих станциях и рядовых серверах, присоединенных к домену или лесу. При развертывании доменных служб Active Directory установите высшие режимы работы домена и леса, которые поддерживаются в используемой среде. Это позволит пользоваться максимальным количеством возможностей доменных служб службы Active Directory. Какие именно возможности это дает мы рассмотрим в следующих статьях.

Для того чтобы нам посмотреть нужную нам информацию есть два способа графический и через powershell, мы рассмотрим оба.

Как узнать режим работы домена Active Directory через оснастку ADUC

Открываем оснастку пользователи и компьютеры, делается это через Пуск-Администрирование или ввод в меню Выполнить команды dsa.mac

Как узнать режим работы леса и режим работы домена Active Directory-02

Щелкаем правым кликом по вашему домену и выбираем Повысить режим работы домена

Как узнать режим работы леса и режим работы домена Active Directory-03

И видим что текущий режим Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-04

Как узнать режим работы леса и режим работы домена Active Directory через оснастку домены и доверие

Открываем оснастку домены и доверие через меню пуск-Администрирование, либо в меню выполнить введите domain.msc.

Как узнать режим работы леса и режим работы домена Active Directory-05

Щелкаем правым кликом по Active Directory — домены и доверие и из контекстного меню выбираем Изменить режим работы леса

Как узнать режим работы леса и режим работы домена Active Directory-06

и видим что лес работает в режиме Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-07

Если щелкнуть правым кликом там же но по домену и выбрать изменение режима работы домена, то вы так же увидите в каком режиме работает ваш домен.

Как узнать режим работы леса и режим работы домена Active Directory-08

Как узнать режим работы леса и режим работы домена Active Directory через powershell

Для этого дела у Microsoft естественно есть свои командлеты. Для начала давайте откроем powershell от имени администратор через правый кликом и посмотрим список доступных модулей powershell с помощью команды

Если среди них нет модуля Active Directory то он устанавливается командой

И загружаем модуль Active Directory с помощью команды

Как узнать режим работы леса и режим работы домена Active Directory-09

Для вывода информации по домену мы вводим команду, и в поле DomainMode видим что это уровень Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-10

Для вывода информации по лесу мы вводим команду. и в поле ForestMode видим что это уровень Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-11

Вот так вот просто узнать режим работы леса и режим работы домена Active Directory через оснастки и командную строку.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Обновление схемы Active Directory

Как известно — ничего вечного нет, все меняется, особенно в такой отрасли как IT. Развернутая один раз инфраструктура постоянно развивается, расширяется, совершенствуется и наступает момент когда в вашу Active Directory требуется ввести контроллер домена под управлением более поздней версии операционной системы.

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

Схемой AD называется описание всех объектов каталога и их атрибутов. По существу схема отражает базовую структуру каталога и имеет первостепенное значение для его правильного функционирования.

Новые версии ОС и содержат новые объекты и атрибуты, поэтому для их нормального функционирования в качестве контроллеров домена нам потребуется обновить схему.

Вроде бы понятно, но не совсем, поэтому перейдем к распространенным ошибкам и заблуждениям.

• Обновление схемы необходимо для включения в домен ПК под управлением более новых версий ОС Windows. Это не так, даже самые последние версии Windows могут вполне успешно работать в домене уровня Windows 2000 без обновления схемы. Хотя, если вы все-таки обновите схему, то ничего страшного не произойдет.

• Для включения в домен контроллера под управлением более новой ОС требуется повысить уровень работы домена (леса). Это тоже не так, но в отличие от предыдущего случая, данная операция сделает невозможным использование контроллеров домена под управлением ОС ниже, чем режим его работы. Поэтому в случае ошибки вам придется восстанавливать вашу структуру AD из резервной копии.

Также заострим ваше внимание на режиме работы леса и домена. Домены входящие в лес могут иметь различные режимы работы, например один из доменов может работать в режиме Windows 2008, а остальные в режиме Windows 2003. Схема работы леса не может быть выше, чем схема работы самого старого домена. В нашем примере режим работы леса не может быть выше, чем Windows 2003.

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

Ознакомившись с теорией, перейдем к практическому примеру. Допустим у нас есть домен уровня Windows 2000 (смешанный режим) — самый низкий уровень AD — в котором имеется контроллер под управлением Windows 2003, а наша цель — создать новый контроллер взамен вышедшего из строя.

Новый сервер работает под управлением Windows 2008 R2. Заметьте, у нас не возникло никаких сложностей по включению данного сервера в существующий домен.

Однако при попытке добавить новый контроллер домена мы получим ошибку:

Для успешного включения контроллера под управлением более новой версии ОС нам потребуется обновить схему леса и схему домена. Исключение составляет Windows Server 2012, который при добавлении нового контроллера домена произведет обновление схемы самостоятельно.

Для обновления схемы используется утилита Adprep которая находится в папке supportadprep на установочном диске Windows Server. Начиная с Windows Server 2008 R2 эта утилита по умолчанию 64-разрядная, при необходимости использовать 32-разрядную версию следует запускать adprep32.exe.

Для выполнения обновления схемы леса данная утилита должна быть запущена на Хозяине схемы, а для обновления схемы домена на Хозяине инфраструктуры. Чтобы узнать какие из контроллеров имеют необходимые нам роли FSMO воспользуемся командой:

В Windows 2008 и новее данная утилита установлена по умолчанию, а в Windows 2003 ее нужно установить с диска из директории supporttools

Результатом вывода данной команды будет перечисление всех ролей FSMO и контроллеров имеющих данные роли:

В нашем случае все роли находятся на одном контроллере, поэтому копируем папку supportadprep на жесткий диск (в нашем случае в корень диска C:) и приступаем к обновлению схемы леса. Для успешного выполнения операции ваш аккаунт должен входить в группы:

• Администраторы схемы
• Администраторы предприятия
• Администраторы домена, в котором находится хозяин схемы

Чтобы обновить схему леса выполните команду:

Ознакомьтесь со стандартным предупреждением и продолжите нажав C, затем Enter.

Начнется процесс обновления схемы. Как видим ее версия изменится с 30 (Windows 2003) до 47 (Windows 2008 R2).

После обновления схемы леса следует обновить схему домена. Перед этим следует убедиться что домен работает как минимум в режиме Windows 2000 (основной режим). Как помним, у нас домен работает в смешанном режиме, поэтому следует изменить режим работы домена на основной или повысить его до Windows 2003. Так как в данном домене у нас нет контроллеров под управлением Windows 2000, то наиболее разумно будет повысить режим домена.

Для успешного обновления схемы домена эту операцию следует производить на Хозяине инфраструктуры и иметь права Администратора домена. Выполняем команду:

И внимательно читаем выводимую информацию. Обновляя схему домена с уровня Windows 2000 или Windows 2003 необходимо выполнить изменение разрешений файловой системы для групповых политик. Данная операция производится один раз и в дальнейшем, например обновляя схему с уровня 2008 на 2008 R2, выполнять ее нужно. Для обновления разрешений объектов GPO введите команду:

В версиях AD начиная с Windows 2008 появился новый тип контроллеров домена: контроллер домена только для чтения (RODC), если вы планируете развернуть такой контроллер, то вам нужно подготовить схему. Вообще мы рекомендуем выполнить данную операцию вне зависимости от того, собираетесь вы в ближайшее время устанавливать RODC или нет.

Данную операцию можно выполнить на любом контроллере домена, однако вы должны входить в группу Администраторы предприятия и Хозяин именований и Хозяин инфраструктуры должны быть доступны.

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

Как видим, обновление схемы домена, будучи правильно спланировано не вызывает каких либо затруднений, однако в любом случае следует помнить, что это необратимая операция и иметь под рукой необходимые резервные копии.

Источник

Сбой проверки реплики лес работает в режиме windows 2000

Общие обсуждения

Доброго времени суток!

хочу установить дополнительный контроллер домена windows server 2008 R2 в существующий домен на windows server 2012. При попытке настроить его (windows server 2008 R2) через dcpromo.exe выводится ошибка: «Режим работы леса несовместим с данной операционной системой».

Реально-ли вообще организовать репликацию между 2012 и 2008 R2? Нужно-ли подготавливать заранее существующий домен на 2012 с утилитой adprep? или производить какие-нибудь другие подготовительные действия

Все ответы

Active Directory? Ask me how.

ну первая ссылка всего лишь чочокак про уровни функционирования леса и домена и поддерживаемые при этом оси на DC

ну а вторая ссыль это уж костыль — лучше чем ничего, но я бы так не делал 🙂

ну первая ссылка всего лишь чочокак про уровни функционирования леса и домена и поддерживаемые при этом оси на DC

ну а вторая ссыль это уж костыль — лучше чем ничего, но я бы так не делал 🙂

Это не костыль, а поддерживаемое решение. Можно свободно с 2012 откатиться до 2008R2

Просто немногие про это знают- старые привычки мешают актуализировать знания. 🙂

поддерживаемое — имхо не есть рекомендуемое, я бы таки воздержался от практики ромашка устраивать с уровнями функционирования 🙂

ну ладно, будем знать.

Это не костыль, а поддерживаемое решение. Можно свободно с 2012 откатиться до 2008R2

Просто немногие про это знают- старые привычки мешают актуализировать знания. 🙂

Дим, если прочитать внимательнее выше, то была оговорка 🙂 в твоей статье тоже описано про клэймы «если домен Windows Server 2012 настроен для предоставления заявок от всех контроллеров домена» — это как минимум стоит упомянуть и здесь. Насчёт поддерживаемое — будет правильнее увидеть здесь ссылку на статью, где описано что оно прям поддерживаемое — честно говоря, я таковую найти не смог 🙂

http://support.microsoft.com/kb/2753560/en-us — вот собственно кбшка, в которой также говорится о «When the migration is complete, you can raise the domain and forest functional levels back to Windows Server 2012.»

Active Directory? Ask me how.

вот оригинальная статья

Ромашка устраивать было тщательнейшим образом протестировано в лабах и продакшене. Как-то так.

Что касается levels back, Кирилл, то ничего не мешает их подниматьопускать когда захочется. еще один миф в нашу копилку 🙂

всем чмоке в чятике 🙂 а топик стартер кудой делся?

Дмитрий, ну как бы ваше «зуб даю» мнение то авторитетное, однако как грится его к делу не пришьёшь. Согласитесь, анализ предполагаемых последствий изменения продакшена основывающийся на «One dude from forum said..» будет выглядеть слегка не очень, не?

Кабэшка описывает исключительно частный случай и как бы ни на чо не претендует в смысле можно и протестировано и ваще. Мало того там указаны исключения на которые указал AndricoRus (вот ктати не совсем вьехал, изменения в керберосе коснулись только Dynamic Access Control в плане привязки к уровню функционирования домена и больше ничего заафекчено не было?).

Кстати под «миф про levels back» вы имели в виду даунгрейд уровня функционирования лесадомена 2012 -> 2008 R2 или нынче у нас димакратия и можно ваще все 😉 ?

Upd, про димакратию вопрос вроде снимается,

даунгрейд 2008R2 грится возможным только до 2008

«Starting in Windows Server 2008 R2, however, you do have a limited ability to lower the Domain or Forest Functional Levels. The Windows Server 2008 R2 Domain or Forest Functional level can be lowered to Windows Server 2008, and no lower, if and only if none of the Active Directory features that require a Windows Server 2008 R2 Functional Level has been activated. «

Источник