Rid хозяин операций ошибка - Решение и исправление самых разных ошибок на TopOshibok.ru

Приветствую уважаемый форум и прошу помощи!

Вероятно, из-за манипуляций по переносу контроллеров домена (все контроллеры — виртуалки Hyper-V), нарушилась репликация каталога и перестали синхронизироваться политики в домене.

Всего 3 КД, изначально были DMD и DMD2, вчера ввел в домен третий КД DMD3 в надежде перенести все роли на него.

Но в его логах ругань на невозможность реплицировать каталог. Каталог сейчас расположен на DMD2

Плюсом, к сожалению, нет понимания какой из контроллеров «неправильный»

Ниже результаты dcdiag со всех трех КД, что еще предоставить не знаю.

Очень прошу помочь. Заранее благодарен всем откликнувшимся

DMD Server:

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

Выполнение начальной настройки:

Выполняется попытка поиска основного сервера...

Основной сервер = dmd

* Идентифицирован лес AD.
Сбор начальных данных завершен.

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

Сервер проверки: Default-First-Site-Name\DMD

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

......................... DMD - пройдена проверка Connectivity

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

Сервер проверки: Default-First-Site-Name\DMD

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

......................... DMD - пройдена проверка Advertising

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

За последние 24 часа после предоставления SYSVOL в общий доступ

зафиксированы предупреждения или сообщения об ошибках. Сбои при

репликации SYSVOL могут стать причиной проблем групповой политики.
......................... DMD - пройдена проверка FrsEvent

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

......................... DMD - пройдена проверка DFSREvent

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

......................... DMD - пройдена проверка SysVolCheck

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

......................... DMD - пройдена проверка KccEvent

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

[DMD2] Сбой функции DsBindWithSpnEx() с ошибкой -2146893022,

Главное конечное имя неверно..
Внимание: DMD2 является Domain Owner, но не отвечает на привязку DS

RPC.

[DMD2] Сбой привязки LDAP с ошибкой 8341,

Произошла ошибка службы каталогов..
Внимание: DMD2 является Domain Owner, но не отвечает на привязку LDAP.

Внимание: DMD2 является PDC Owner, но не отвечает на привязку DS RPC.

Внимание: DMD2 является PDC Owner, но не отвечает на привязку LDAP.

Внимание: DMD2 является Infrastructure Update Owner, но не отвечает на

привязку DS RPC.

Внимание: DMD2 является Infrastructure Update Owner, но не отвечает на

привязку LDAP.

......................... DMD - не пройдена проверка

KnowsOfRoleHolders

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

......................... DMD - пройдена проверка MachineAccount

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

......................... DMD - пройдена проверка NCSecDesc

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

......................... DMD - пройдена проверка NetLogons

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

......................... DMD - пройдена проверка ObjectsReplicated

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

[Replications Check,DMD] Сбой при последней попытке репликации:

Из DMD2 в DMD

Контекст именования: DC=ForestDnsZones,DC=domain,DC=local

При репликации возникла ошибка (1256):

Удаленная система недоступна. За информацией о разрешении проблем в сети, обратитесь к справочной системе Windows.

Сбой возник в 2016-08-23 12:46:34.

Последняя успешная операция была в 2016-07-26 18:32:00. После

последней успешной операции было

697 сбоев.

[Replications Check,DMD] Сбой при последней попытке репликации:

Из DMD2 в DMD

Контекст именования: DC=DomainDnsZones,DC=domain,DC=local

При репликации возникла ошибка (1256):

Сбой возник в 2016-08-23 12:46:34.

Последняя успешная операция была в 2016-07-26 18:32:01. После

последней успешной операции было

710 сбоев.

[Replications Check,DMD] Сбой при последней попытке репликации:

Из DMD2 в DMD

Контекст именования: CN=Schema,CN=Configuration,DC=domain,DC=local

При репликации возникла ошибка (-2146893022):

Главное конечное имя неверно.

Сбой возник в 2016-08-23 12:46:34.

Последняя успешная операция была в 2016-07-26 18:32:02. После

последней успешной операции было

676 сбоев.

[Replications Check,DMD] Сбой при последней попытке репликации:

Из DMD2 в DMD

Контекст именования: CN=Configuration,DC=domain,DC=local

При репликации возникла ошибка (-2146893022):

Главное конечное имя неверно.

Сбой возник в 2016-08-23 12:46:34.

Последняя успешная операция была в 2016-07-27 17:47:37. После

последней успешной операции было

644 сбоев.

[Replications Check,DMD] Сбой при последней попытке репликации:

Из DMD2 в DMD

Контекст именования: DC=domain,DC=local

При репликации возникла ошибка (-2146893022):

Главное конечное имя неверно.

Сбой возник в 2016-08-23 12:49:47.

Последняя успешная операция была в 2016-07-26 18:32:02. После

последней успешной операции было

1967 сбоев.

......................... DMD - не пройдена проверка Replications

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

......................... DMD - пройдена проверка RidManager

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

......................... DMD - пройдена проверка Services

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

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 11:51:49

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя cifs/dmd2.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 12:01:55

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя DNS/dmd2.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 12:38:35

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя domain\DMD2$. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 12:46:34

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя E3514235-4B06-11D1-AB04-00C04FC2DCD2/cc5c6e59-04de-4d28-9dfe-a361e9a8e4b7/domain.local@domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 12:47:50

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя cifs/DMD2.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 12:50:33

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя LDAP/cc5c6e59-04de-4d28-9dfe-a361e9a8e4b7._msdcs.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

Возникла ошибка. Код события (EventID): 0x40000004

Время создания: 08/23/2016 12:50:33

Строка события:

Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя ldap/dmd2.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

......................... DMD - не пройдена проверка SystemLog

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

......................... DMD - пройдена проверка VerifyReferences

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

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

......................... ForestDnsZones - пройдена проверка

CheckSDRefDom

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

......................... ForestDnsZones - пройдена проверка

CrossRefValidation

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

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

......................... DomainDnsZones - пройдена проверка

CheckSDRefDom

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

......................... DomainDnsZones - пройдена проверка

CrossRefValidation

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

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

......................... Schema - пройдена проверка CheckSDRefDom

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

......................... Schema - пройдена проверка

CrossRefValidation

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

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

......................... Configuration - пройдена проверка

CheckSDRefDom

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

......................... Configuration - пройдена проверка

CrossRefValidation

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

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

......................... domain - пройдена проверка CheckSDRefDom

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

......................... domain - пройдена проверка

CrossRefValidation

Выполнение проверок предприятия на: domain.local

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

......................... domain.local - пройдена проверка LocatorCheck

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

......................... domain.local - пройдена проверка Intersite

DMD2 Server:

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

Выполнение начальной настройки:

Выполняется попытка поиска основного сервера...

Основной сервер = dmd2

* Идентифицирован лес AD.
Сбор начальных данных завершен.

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

Сервер проверки: Default-First-Site-Name\DMD2

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

......................... DMD2 - пройдена проверка Connectivity

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

Сервер проверки: Default-First-Site-Name\DMD2

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

Внимание: DsGetDcName вернул сведения для \\dmd.domain.local при попытке

получения доступа к DMD2.

СЕРВЕР НЕ ОТВЕЧАЕТ или НЕ СЧИТАЕТСЯ ПРИЕМЛЕМЫМ.

......................... DMD2 - не пройдена проверка Advertising

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

За последние 24 часа после предоставления SYSVOL в общий доступ

зафиксированы предупреждения или сообщения об ошибках. Сбои при

репликации SYSVOL могут стать причиной проблем групповой политики.
......................... DMD2 - пройдена проверка FrsEvent

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

......................... DMD2 - пройдена проверка DFSREvent

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

......................... DMD2 - пройдена проверка SysVolCheck

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

Возникло предупреждение. Код события (EventID): 0x8000082C

Время создания: 08/23/2016 12:34:33

Строка события:

Возникло предупреждение. Код события (EventID): 0x8000082C

Время создания: 08/23/2016 12:34:33

Строка события:

Возникла ошибка. Код события (EventID): 0xC0000748

Время создания: 08/23/2016 12:34:33

Строка события:

Ниже отображено состояние репликации в следующем разделе каталога на сервере каталогов.

Возникло предупреждение. Код события (EventID): 0x8000082C

Время создания: 08/23/2016 12:34:33

Строка события:

Возникла ошибка. Код события (EventID): 0xC0000748

Время создания: 08/23/2016 12:34:33

Строка события:

Ниже отображено состояние репликации в следующем разделе каталога на сервере каталогов.

Возникло предупреждение. Код события (EventID): 0x8000082C

Время создания: 08/23/2016 12:34:33

Строка события:

Возникла ошибка. Код события (EventID): 0xC0000748

Время создания: 08/23/2016 12:34:33

Строка события:

Ниже отображено состояние репликации в следующем разделе каталога на сервере каталогов.

Возникла ошибка. Код события (EventID): 0xC0000748

Время создания: 08/23/2016 12:34:33

Строка события:

Ниже отображено состояние репликации в следующем разделе каталога на сервере каталогов.

Возникла ошибка. Код события (EventID): 0xC0000748

Время создания: 08/23/2016 12:34:33

Строка события:

Ниже отображено состояние репликации в следующем разделе каталога на сервере каталогов.

Возникло предупреждение. Код события (EventID): 0x8000082C

Время создания: 08/23/2016 12:35:33

Строка события:

......................... DMD2 - не пройдена проверка KccEvent

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

......................... DMD2 - пройдена проверка KnowsOfRoleHolders

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

......................... DMD2 - пройдена проверка MachineAccount

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

......................... DMD2 - пройдена проверка NCSecDesc

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

......................... DMD2 - пройдена проверка NetLogons

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

......................... DMD2 - пройдена проверка ObjectsReplicated

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

[Проверка репликации,Replications Check] Входящая репликация

отключена.

Для исправления выполните "repadmin /options DMD2

-DISABLE_INBOUND_REPL"

[Проверка репликации,DMD2] Исходящая репликация отключена.

Для исправления выполните "repadmin /options DMD2

-DISABLE_OUTBOUND_REPL"

......................... DMD2 - не пройдена проверка Replications

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

......................... DMD2 - пройдена проверка RidManager

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

Служба w32time в [DMD2] остановлена

Служба NETLOGON в [DMD2] приостановлена

......................... DMD2 - не пройдена проверка Services

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

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 11:53:45

Строка события:

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

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 11:58:48

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:03:51

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:08:53

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:13:56

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:18:59

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:24:02

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:29:05

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:34:07

Строка события:

Возникло предупреждение. Код события (EventID): 0x0000A001

Время создания: 08/23/2016 12:39:10

Строка события:

Системе безопасности не удалось установить безопасное соединение с сервером ldap/dmd3.domain.local/domain.local@domain.local. Протоколы проверки подлинности недоступны.

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:39:10

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:44:13

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:48:53

Строка события:

Возникла ошибка. Код события (EventID): 0x00000406

Время создания: 08/23/2016 12:49:14

Строка события:

......................... DMD2 - не пройдена проверка SystemLog

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

......................... DMD2 - пройдена проверка VerifyReferences

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

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

......................... ForestDnsZones - пройдена проверка

CheckSDRefDom

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

......................... ForestDnsZones - пройдена проверка

CrossRefValidation

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

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

......................... DomainDnsZones - пройдена проверка

CheckSDRefDom

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

......................... DomainDnsZones - пройдена проверка

CrossRefValidation

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

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

......................... Schema - пройдена проверка CheckSDRefDom

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

......................... Schema - пройдена проверка

CrossRefValidation

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

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

......................... Configuration - пройдена проверка

CheckSDRefDom

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

......................... Configuration - пройдена проверка

CrossRefValidation

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

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

......................... domain - пройдена проверка CheckSDRefDom

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

......................... domain - пройдена проверка

CrossRefValidation

Выполнение проверок предприятия на: domain.local

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

......................... domain.local - пройдена проверка LocatorCheck

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

......................... domain.local - пройдена проверка Intersite

DMD3 Server:

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


Выполнение начальной настройки:

   Выполняется попытка поиска основного сервера...

   Основной сервер = dmd3

   * Идентифицирован лес AD. 
   Сбор начальных данных завершен.


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

   
   Сервер проверки: Default-First-Site-Name\DMD3

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

         ......................... DMD3 - пройдена проверка Connectivity



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

   
   Сервер проверки: Default-First-Site-Name\DMD3

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

         ......................... DMD3 - пройдена проверка Advertising

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

         За последние 24 часа после предоставления SYSVOL в общий доступ

         зафиксированы предупреждения или сообщения  об ошибках.  Сбои при

         репликации SYSVOL могут стать причиной проблем групповой политики. 
         ......................... DMD3 - пройдена проверка FrsEvent

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

         ......................... DMD3 - пройдена проверка DFSREvent

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

         ......................... DMD3 - пройдена проверка SysVolCheck

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

         Возникло предупреждение. Код события (EventID): 0x80000785

            Время создания: 08/23/2016   12:46:42

            Строка события:

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


         Возникло предупреждение. Код события (EventID): 0x80000785

            Время создания: 08/23/2016   12:46:42

            Строка события:

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


         Возникло предупреждение. Код события (EventID): 0x80000785

            Время создания: 08/23/2016   12:46:42

            Строка события:

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


         Возникло предупреждение. Код события (EventID): 0x80000785

            Время создания: 08/23/2016   12:46:42

            Строка события:

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


         Возникло предупреждение. Код события (EventID): 0x80000785

            Время создания: 08/23/2016   12:46:42

            Строка события:

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


         ......................... DMD3 - пройдена проверка KccEvent

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

         [DMD2] Сбой функции DsBindWithSpnEx() с ошибкой -2146893022,

         Главное конечное имя неверно..
         Внимание: DMD2 является Domain Owner, но не отвечает на привязку DS

         RPC.

         [DMD2] Сбой привязки LDAP с ошибкой 8341,

         Произошла ошибка службы каталогов..
         Внимание: DMD2 является Domain Owner, но не отвечает на привязку LDAP.

         Внимание: DMD2 является PDC Owner, но не отвечает на привязку DS RPC.

         Внимание: DMD2 является PDC Owner, но не отвечает на привязку LDAP.

         Внимание: DMD2 является Infrastructure Update Owner, но не отвечает на

         привязку DS RPC.

         Внимание: DMD2 является Infrastructure Update Owner, но не отвечает на

         привязку LDAP.

         ......................... DMD3 - не пройдена проверка

         KnowsOfRoleHolders

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

         ......................... DMD3 - пройдена проверка MachineAccount

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

         ......................... DMD3 - пройдена проверка NCSecDesc

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

         ......................... DMD3 - пройдена проверка NetLogons

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

         ......................... DMD3 - пройдена проверка ObjectsReplicated

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

         ПРЕДУПРЕЖДЕНИЕ О ЗАДЕРЖКЕ ПОЛУЧЕННОЙ РЕПЛИКАЦИИ

         DMD3:  Текущее время - 2016-08-23 12:48:02.

            DC=ForestDnsZones,DC=domain,DC=local
               Последняя репликация получена из DMD2 в 
          2016-07-26 18:33:00 
            DC=DomainDnsZones,DC=domain,DC=local
               Последняя репликация получена из DMD2 в 
          2016-07-26 18:33:01 
            CN=Schema,CN=Configuration,DC=domain,DC=local
               Последняя репликация получена из DMD2 в 
          2016-07-26 18:33:03 
            CN=Configuration,DC=domain,DC=local
               Последняя репликация получена из DMD2 в 
          2016-07-27 17:47:41 
            DC=domain,DC=local
               Последняя репликация получена из DMD2 в 
          2016-07-26 18:33:03 
         ......................... DMD3 - пройдена проверка Replications

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

         ......................... DMD3 - пройдена проверка RidManager

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

         ......................... DMD3 - пройдена проверка Services

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

         Возникла ошибка. Код события (EventID): 0x00000457

            Время создания: 08/23/2016   11:49:39

            Строка события:

            Драйвер Send To Microsoft OneNote 2010 Driver для принтера Отправить в OneNote 2010 не опознан. Обратитесь к сетевому администратору, чтобы он установил нужный драйвер.

         Возникла ошибка. Код события (EventID): 0x00000457

            Время создания: 08/23/2016   11:49:40

            Строка события:

            Драйвер Kyocera FS-4100DN KX (XPS) для принтера !!DMD-PRINT!KyoceraFS-4100DN не опознан. Обратитесь к сетевому администратору, чтобы он установил нужный драйвер.

         Возникла ошибка. Код события (EventID): 0x00000457

            Время создания: 08/23/2016   11:49:40

            Строка события:

            Драйвер HP LaserJet Pro MFP M521 PCL 6 для принтера !!DMD-PRINT!MFP_521_office не опознан. Обратитесь к сетевому администратору, чтобы он установил нужный драйвер.

         Возникла ошибка. Код события (EventID): 0x40000004

            Время создания: 08/23/2016   11:50:13

            Строка события:

            Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя ldap/dmd2.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

         Возникла ошибка. Код события (EventID): 0x40000004

            Время создания: 08/23/2016   12:30:52

            Строка события:

            Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя domain\DMD2$. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

         Возникла ошибка. Код события (EventID): 0x40000004

            Время создания: 08/23/2016   12:31:42

            Строка события:

            Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя E3514235-4B06-11D1-AB04-00C04FC2DCD2/cc5c6e59-04de-4d28-9dfe-a361e9a8e4b7/domain.local@domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

         Возникла ошибка. Код события (EventID): 0x40000004

            Время создания: 08/23/2016   12:46:42

            Строка события:

            Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера dmd2$. Использовалось конечное имя LDAP/cc5c6e59-04de-4d28-9dfe-a361e9a8e4b7._msdcs.domain.local. Это означает, что конечному серверу не удалось расшифровать билет, предоставленный клиентом. Это может быть из-за того, что имя участника службы конечного сервера (SPN) зарегистрировано на учетной записи, отличной от учетной записи, используемой конечной службой. Убедитесь, что конечное имя SPN зарегистрировано только на учетной записи, используемой сервером. Причиной этой ошибки может быть еще и то, что конечная служба использует другой пароль для учетной записи конечной службы, отличный от пароля центра распределения ключей Kerberos (KDC) для учетной записи конечной службы. Убедитесь, что и служба на сервере, и KDC обновлены, чтобы использовать текущий пароль. Если имя сервера задано не полностью и конечный домен (domain.local) отличен от домена клиента (domain.local), проверьте, нет ли серверных учетных записей с таким же именем в этих двух доменах, или используйте полное имя для идентификации сервера.

         ......................... DMD3 - не пройдена проверка SystemLog

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

         ......................... DMD3 - пройдена проверка VerifyReferences

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

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

         ......................... ForestDnsZones - пройдена проверка

         CheckSDRefDom

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

         ......................... ForestDnsZones - пройдена проверка

         CrossRefValidation

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

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

         ......................... DomainDnsZones - пройдена проверка

         CheckSDRefDom

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

         ......................... DomainDnsZones - пройдена проверка

         CrossRefValidation

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

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

         ......................... Schema - пройдена проверка CheckSDRefDom

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

         ......................... Schema - пройдена проверка

         CrossRefValidation

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

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

         ......................... Configuration - пройдена проверка

         CheckSDRefDom

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

         ......................... Configuration - пройдена проверка

         CrossRefValidation

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

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

         ......................... domain - пройдена проверка CheckSDRefDom

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

         ......................... domain - пройдена проверка

         CrossRefValidation

   
   Выполнение проверок предприятия на: domain.local

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

         ......................... domain.local - пройдена проверка LocatorCheck

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

         ......................... domain.local - пройдена проверка Intersite

Источник

Определившись с назначением ролей FSMO рассмотрим варианты передачи ролей другому контроллеру домена, а также принудительное назначение, или «захват» роли в случае недоступности контроллера домена, который ее выполняет.

При создании домена, по умолчанию все роли назначаются первому контроллеру домена в лесу. Переназначение ролей требуется крайне редко. Microsoft рекомендует использовать передачу ролей FSMO в следующих случаях:

• Плановое понижение роли контроллера домена, являющегося обладателем ролей FSMO, например с целью вывода сервера из эксплуатации;
• Временное отключение контроллера домена, например для выполнения профилактических работ. В этом случае его роли должны быть назначены другому, работающему контроллеру домена. Это особенно необходимо при отключении эмулятора PDC. Временное отключение остальных хозяев операций в меньшей степени сказывается на работе AD.

Захват ролей FSMO производится в следующих случаях:

• Если в работе текущего обладателя роли FSMO возникли сбои, препятствующие успешному выполнению функций, присущих данной роли, и не дающие выполнить передачу роли;
• На контролере домена, являвшемся обладателем роли FSMO, переустановлена или не загружается операционная система;
• Роль контроллера домена, являвшегося обладателем роли FSMO, была принудительно понижена с помощью команды dcpromo /forceremoval.

Примечание. Начиная с Windows Server 2003 SP1 при выполнении команды dcpromo /forceremoval осуществляется проверка, имеет ли контроллер домена роль хозяина операций, является DNS-сервером или сервером глобального каталога. Для каждой из этих ролей будет получено уведомление с указаниями по выполнению соответствующих действий.

В том случае, если в домене два или более контроллеров, первым делом нам необходимо выяснить, кто является обладателем каждой из ролей FSMO. Это достаточно просто сделать с помощью команды netdom query fsmo

Ну а теперь приступим к передаче ролей. Есть несколько вариантов действий, рассмотрим их все по порядку. Вариант первый, самый простой и доступный.

Добровольная передача ролей FSMO с помощью оснасток управления Active Directory

Для передачи ролей уровня домена (RID Master, PDC Emulator и Infrastructure Master) используем оснастку Active Directory Пользователи и компьютеры (Users and Computers). Для этого заходим на контроллер домена, которому хотим передать роли, запускаем оснастку и щелкнув правой клавишей мыши на нужном домене, выбираем пункт «Хозяева операций».

В открывшемся окне выбираем нужную нам роль (в нашем примере RID Master) и нажимаем кнопку «Изменить».

Далее подтверждаем перенос роли

И смотрим на результат. Дело сделано, роль передана другому серверу.

Перенос роли Domain Naming Master осуществляется из оснастки Active Directory Домены и доверие (Domains and Trust). Запускаем оснастку, при необходимости подключаемся к нужному контроллеру домена, щелкаем правой клавишей мыши в корне оснастки и выбираем пункт меню «Хозяин операций».

Открывается знакомое окно, в котором надо нажать кнопку «Изменить», а затем подтвердить изменения так же, как и в предыдущем примере.

С ролью Schema Master дела обстоят несколько сложнее. Для передачи этой роли необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory. Делается это с помощью команды regsvr32 schmmgmt.dll, введенной в окне Выполнить (Run).

Затем открываем консоль MMC и добавляем в нее оснастку Схема Active Directory .

Ну а дальше заходим в оснастку и действуем аналогично предыдущим примерам.

Если по каким то причинам не удается передать роли с помощью графических оснасток, а также для любителей командной строки есть второй вариант:

Добровольная передача ролей fsmo при помощи Ntdsutil

ntdsutil.exe – утилита командной строки, предназначенная для обслуживания каталога Active Directory. Она представляет из себя мощный инструмент управления, и в число ее возможностей входит передача и захват ролей FSMO.

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

ntdsutil
roles
connections
connect to server <имя сервера>
q

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance), и можем начать передавать роли :

transfer domain naming master — передача роли хозяина доменных имен.
transfer infrastructure master — передача роли хозяина инфраструктуры;
transfer rid master — передача роли хозяина RID;
transfer schema master — передача роли хозяина схемы;
transfer pdc — передача роли эмулятора PDC.

Для завершения работы Ntdsutil вводим команду q и нажимаем Ввод.

Примечание. Начиная с Windows Server 2008R2 команда для передачи роли хозяина доменных имен transfer naming master.

В качестве примера передадим роль Infrastructure Master серверу SRV2 и проверим результат.

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

Принудительное назначение ролей fsmo при помощи Ntdsutil

Принудительное назначение, или захват ролей производятся только в случае полного выхода из строя сервера, с невозможностью его восстановления. Если возможно, лучше восстановить работоспособность вышедшего из строя контроллера домена, которому назначены роли FSMO. Сама процедура захвата не особо отличается от передачи ролей. Заходим на контроллер домена, которому хотим передать роли и последовательно вводим в командной строке:

ntdsutil
roles
connections
connect to server <имя сервера>
q

Для захвата ролей FSMO используется команда seize

seize domain naming master — захват роли хозяина доменных имен;
seize infrastructure master — захват роли хозяина инфраструктуры;
seize rid master — захват роли хозяина RID;
seize schema master — захват роли хозяина схемы;
seize pdc — захват роли эмулятора PDC.

Примечание. Начиная с Windows Server 2008R2 команда для захвата роли хозяина доменных имен seize naming master.

В качестве примера отберем у сервера SRV2 переданную ему роль Infrastructure Master и передадим ее серверу DC1. Как видно из примера, сначала предпринимается попытка передачи роли, и только в случае невозможности этого действия осуществляется захват.

И еще несколько важных моментов, которые нужно учесть при передаче\захвате ролей FSMO:

• Для передачи ролей уровня домена (RID Master, PDC Emulator и Infrastructure Master) ваша учетная запись должна быть членом группы Администраторы домена (Domain admins), а для передачи ролей уровня леса (Domain Naming Master и Schema Master) — Администраторы предприятия (Enterprise Admins).
• По возможности не назначайте роль Infrastructure Master контроллеру домена, являющемуся сервером глобального каталога, поскольку в этом случае он не будет обновлять сведения об объектах. Причина такого поведения заключается в том, что сервер глобального каталога хранит частичные реплики всех объектов в лесу.
• В случае захвата ролей FSMO контроллер домена, ранее исполнявший эти роли, ни в коем случае нельзя возвращать обратно, т.к. при его появлении в сети возникнет конфликт, что может вызвать проблемы в работе домена. Кроме того, его необходимо удалить из Active Directory. В Windows Server 2008 и 2008 R2 это можно сделать, просто удалив объект сервера в оснастке Active Directory Пользователи и компьютеры, а в Windows Server 2003 с помощью программы Ntdsutil , используя команду ntdsutil — metadata cleanup. Подробнее об этом можно почитать в техподдержке Microsoft http://support.microsoft.com/kb/216498.

Источник

Содержание

1 Постановка задачи
2 Добавление контроллера домена
3 Перенос роли хозяина операций
4 Работа над ошибками
- 4.1 DNS не удаётся разрешить IP-адрес
- 4.2 Ошибка репликации 8453
- 4.3 На контроллере нет сетевых ресурсов NetLogon и SysVol
5 См. также

Постановка задачи

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

Предположим:

MYDOMAIN.LOCAL — наш домен под управлением Active Directory в Windows 2012 Server
DC1 — единственный контроллер домена
DC2 — новый добавляемый сервер, который будет вторым контроллером домена и впоследствии хозяином операций

Добавление контроллера домена

После установки на Windows 2012 Server роли «Доменные службы Active Directory» и повышения уровня сервера до контроллера домена (см офиц инструкцию) необходимо перед дальнейшими действиями дать несколько часов на синхронизацию между контроллерами доменов.

Затем следует проверить насколько гладко новый котроллер вошёл в домен.

C:\Windows\system32>nltest /dclist:mydomain.local
Получить список контроллеров домена в домене "mydomain.local" из "\\dc1.mydomain.local".
    dc1.mydomain.local [PDC]  [DS] Сайт: Default-First-Site-Name
    DC2.mydomain.local        [DS] Сайт: Default-First-Site-Name
Команда выполнена успешно.

Можно альтернативно запросить туже информацию непосредственно из каталога Active Directory:

C:\Windows\system32>dsquery server
"CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomain,DC=local"
"CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=mydomain,DC=local"

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

repadmin /replsummary
repadmin /queue
repadmin /showrepl

Если репликации не были успешными, то можно запустить репликацию принудительно, но при этом командный интерпритатор cmd должне быть запущен с административными правами:

repadmin /syncall

Командой dcdiag можно более подробно диагностировать состояние контроллера домена, а также отдельно запустить более подробные тесты для проверки разных служб (офиц. описание)

Перенос роли хозяина операций

Прежде чем начать перенос ролей, желательно добиться отсутствия ошибок в dcdiag!

Алгоритм переноса ролей FSMO (Flexible Single-Master Operations) такой же как и при захвате. В первом случае используется работающий главный контроллер домена (PDC), и переносимые роли на нём отключаются, если же он потерян, то роли захватываются новым контроллером принудительно.

Посмотрим список контроллеров домена mydomain.local:

nltest /dclist:mydomain.local

Выясняем, кто из контроллеров является хозяином операций:

C:\Users\pnm>netdom query FSMO
Хозяин схемы                dc1.mydomain.local
Хозяин именования доменов   dc1.mydomain.local
PDC                         dc1.mydomain.local
Диспетчер пула RID          dc1.mydomain.local
Хозяин инфраструктуры       dc1.mydomain.local
Команда выполнена успешно.

Перенос ролей можно сделать двумя способами:

1. через оснастку «Active Directory — Домены и доверие», открыв её из Диспетчера серверов — Средства.

2. консольной утилитой управления доменом ntdsutil (офиц. документация). Если роли передаются, то используем команду transfer, если же захватываются, то seize. Ниже приведён алгоритм захвата ролей новым контроллером dc2:

C:\Users\pnm>ntdsutil 
ntdsutil: roles
fsmo maintenance: connections 
server connections: connect to server dc2
Привязка к dc2 ...
Подключен к dc2 с помощью учетных данных локального пользователя.
server connections: quit
fsmo maintenance: seize infrastructure master
fsmo maintenance: seize naming master
fsmo maintenance: seize PDC
fsmo maintenance: seize RID master
fsmo maintenance: seize schema master
quit
quit

Находясь в разделе fsmo maintenance можно узнать список всех ролей, послав команду ?.

В случае успешного захвата мы должны увидеть следующее

C:\Users\pnm>netdom query FSMO
Хозяин схемы                dc2.mydomain.local
Хозяин именования доменов   dc2.mydomain.local
PDC                         dc2.mydomain.local
Диспетчер пула RID          dc2.mydomain.local
Хозяин инфраструктуры       dc2.mydomain.local
Команда выполнена успешно.

Работа над ошибками

Некоторые примеры диагностики проблем с контроллерами домена рассмотрены в примерах команды dcdiag

DNS не удаётся разрешить IP-адрес

dcdiag выдаёт ошибку DNS:

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

   Сервер проверки: Default-First-Site-Name\DC2
    Запуск проверки: Connectivity
       Узел a20970bf-3f73-400a-85ac-69c8f7b34301._msdcs.mydomain.local не удается
       разрешить в IP-адрес. Проверьте DNS-сервер, DHCP, имя сервера и т. д.
       Получена ошибка при проверке подключения LDAP и RPC. Проверьте параметры
       брандмауэра.
       ......................... DC2 - не пройдена проверка Connectivity

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

   Сервер проверки: Default-First-Site-Name\DC2
      Пропуск всех проверок, так как сервер DC2 не отвечает на запросы службы каталогов.

РЕШЕНИЕ:

Нужно проверить существует ли обратная DNS зона и синхронизирована ли она между контроллерами.

Детальная проверка службы DNS (может занять пару минут):

dcdiag /test:dns

Рекомендации по настройке службы DNS на контроллере домена
DNScmd — консольная утилита для управления DNS сервером (офиц. описание)

Ошибка репликации 8453

repadmin /showrepl выдаёт ошибку:

Процесс DsReplicaGetInfo() завершился ошибкой с кодом состояния 8453 (0x2105):
    Доступ к репликации отвергнут.

РЕШЕНИЕ:

Запустить репликацию вручную и командной строки с административными правами

repadmin /syncall

На контроллере нет сетевых ресурсов NetLogon и SysVol

Эта ошибка означает, что репликация данных с главного контроллера домена (хозяина операций) на проблемный не была произведена до конца.

Доступность сетевых ресурсов можно проверить командой:

net share

Исправность ресурсов SysVol и NetLogon можно проверить командой:

dcdiag /test:netlogons

Официальную инструкцию по пересозданию ресурсов NetLogon и SysVol на английском можно прочесть в статье Restoring and Rebuilding SYSVOL. Ниже приведён краткий алгоритм этого процесса.

См. также

Active Directory — общая информация

Источник

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

Если причина восстановления — невозможность использования базы данных на контроллере домена, у вас два пути. Можно не пытаться восстанавливать Active Directory на поврежденном сервере, а просто создать новый контроллер домена на другом сервере с Windows Server 2003. Этот метод позволяет вернуть функциональность контроллера домена. Альтернативный путь — восстановить поврежденный сервер и базу данных Active Directory на нем. При этом будет выполнено восстановление без полномочий (nonauthoritative), после которого все изменения, произошедшие после резервного копирования, будут реплицированы на восстановленный контроллер.

Если восстановление необходимо из-за удаления большого числа объектов, то единственный способ — восстановить базу данных Active Directory с резервной копии, содержащей удаленные объекты. После этого следует провести восстановление с полномочиями (authoritative), в ходе которого восстановленные данные будут реплицированы на все контроллеры домена, заменяя удаленные данные.

Восстановление Active Directory путем создания нового контроллера домена

Один из способов восстановления функциональности Active Directory — создание нового контроллера домена в замен отказавшему. Если контроллер домена выходит из строя, можно настроить другой сервер с Windows Server 2003 и Active Directory 2003 или превратить один из текущих серверов в контроллер домена. После этого стандартная репликация Active Directory позволит заполнить базу данных нового контроллера. Этот метод наиболее подходит в определенных ситуациях.

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

Если у вас есть возможность отремонтировать отказавший контроллер домена без его полного воссоздания, то перечисленные ранее методы восстановления не потребуются. Windows Server 2003 предлагает улучшенные инструменты для диагностики и устранения проблем, такие как «Last Known Good Configuration» и «Safe Mode». Прежде чем приступать к полному восстановлению, рекомендуется попробовать восстановить работоспособность контроллера с помощью этих инструментов.

Для замены отказавшего сервера можно использовать существующий сервер с Windows Server 2003 или создать новый и сделать его контроллером домена. В процессе этого преобразования каталог будет реплицирован с другого контроллера домена. Если отказавший контроллер выполнял функции глобального каталога или был одним из операционных мастеров, следует учесть восстановление этих функций. Детальное описание восстановления таких серверов приведено далее в этой главе.

Как упоминалось ранее, Windows Server 2003 предоставляет возможность установки нового контроллера домена и загрузки базы данных Active Directory из резервной копии, минуя стандартный процесс репликации. Это особенно актуально при настройке контроллера в удаленном офисе с медленным интернет-соединением, так как не требуется передача больших объемов данных. Если у вас есть актуальная резервная копия отказавшего контроллера в удаленном офисе, этот метод может быть применен для создания нового контроллера.

При восстановлении функциональности Active Directory путем создания нового контроллера домена необходимо удалить старый контроллер из каталога и DNS. Если планируется использование имени отказавшего контроллера для нового, следует очистить каталог до начала восстановления. В случае выбора другого имени для нового контроллера, каталог следует очистить после установки.

Для очистки каталога выполните действия на рабочей станции или сервере с Windows 2000, Windows XP Professional или Windows Server 2003, которые являются членами домена. Откройте командную строку и введите ntdsutil.

Для начала работы в командной строке утилиты Ntdsutil введите команду metadata cleanup. Это переведет вас в режим «Очистка мета-данных».

Далее, чтобы установить соединение с текущим контроллером домена с целью удаления отказавшего контроллера, введите connections. После этого вам будет предоставлено окно «Подключение к серверу».

В этом окне введите команду connect to server servername, где servername — имя рабочего контроллера домена. Если у вас есть административные права в Active Directory, вы автоматически подключитесь к этому контроллеру. В противном случае используйте команду set creds domain username password для ввода учетных данных пользователя с правами на уровне домена.

Если вы введете команду help, то увидите опцию connect to server %s. Здесь %s — это либо DNS-имя контроллера домена, либо IP-адрес сервера.

Чтобы вернуться к окну «Очистка мета-данных», введите команду quit.

Для выбора домена, сайта и контроллера домена используйте команду select operation target. Это позволит вам выбрать нужный контроллер домена для удаления.

В окне «Выбор адресата операции» введите list domains для просмотра всех доменов вашего леса с присвоенными им номерами.

Напечатайте select domain number(выбрать номер домена), где number указывает домен, содержащий отказавший контроллер домена. Если вы напечатаете help перед тем, как напечатать select domain number, то увидите, что одна из опций команды -select domain %d(выбрать домен %d). Переменная %d должна всегда заменяться числом. Напечатайте list sites(перечислить сайты). Будут перечислены все сайты леса. Напечатайте select site number(выбрать номер сайта), чтобы выбрать сайт, содержащий контроллер домена, который вы должны удалить. Напечатайте list servers in site(перечислить серверы в сайте). Все контроллеры домена, имеющиеся в выбранном сайте, будут перечислены. Используйте команду select server number, чтобы выбрать контроллер домена, который вы должны удалить. Утилита Ntdsutil покажет выбранный домен, сайт и контроллер домена (см. рис. 15-1.)

Отображение домена, сайта и контроллера домена в утилите Ntdsutil

Рис. 15-1. Отображение домена, сайта и контроллера домена в утилите Ntdsutil

Напечатайте quit. Вы войдете в окно Metadata Cleanup. Напечатайте remove selected server (удалите выбранный сервер). Вас попросят подтвердить, что вы хотите удалить сервер из каталога. Щелкните на Yes (Да). Чтобы выйти из утилиты Ntdsutil, печатайте quit в каждой командной строке, пока не выйдите из программы.

Инструмент Ntdsutil

В главе 14 были показаны примеры использования утилиты Ntdsutil для управления базой данных Active Directory. Ntdsutil — это инструмент командной строки, который применяется для управления некоторыми компонентами Active Directory и базой данных. Ntdsutil является мощным инструментом, им надо пользоваться с осторожностью. Запустите инструмент Ntdsutil, напечатав в командной строке ntdsutil. Инструмент выдает приглашение к вводу команд Ntdsutil. Вы можете вводить разнообразные команды в зависимости от того, что вы хотите сделать. Если вы напечатаете help в любой командной строке, то получите список всех команд, которые можно использовать в этом положении. На рисунке 15-2 показан список команд, доступных из окна Ntdsutil.

Список команд, доступных из командной строки в утилите Ntdsutil

Рис. 15-2. Список команд, доступных из командной строки в утилите Ntdsutil

Далее вы увидите несколько примеров использования утилиты Ntdsuti для управления службой Active Directory. Подробнее об использовании утилиты Ntdsutil можно узнать в Help And Support Center. После очищения каталога от ненужных объектов с помощью Ntdsutil, следует очистить DNS-записи отказавшего контроллера домена. Удалите все DNS-записи, включая записи контроллера домена, записи GC-сервера и записи эмулятора основного контроллера домена (PDC). Если вы не очистите записи DNS, клиенты будут продолжать получать информацию DNS и пытаться соединиться с этим контроллером домена. Также следует удалить вышедший из строя контроллер домена из сайта и домена. Используйте инструмент Active Directory Users And Computers и удалите объект, связанный с этим компьютером, из OU Domain Controllers. В инструменте Active Directory Sites And Services удалите объект этого компьютера из контейнера Servers того сайта, где он был расположен.

Выполнение неофициального восстановления

Еще один способ восстановления базы данных Active Directory — ремонт отказавшего контроллера домена с последующим восстановлением базы данных. Вместо восстановления отказавшего контроллера можно восстановить базу данных на новом сервере. Этот метод наиболее подходит в определенных условиях.

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

Без тестирования различных вариантов в вашей конкретной среде сложно определить, что будет работать быстрее: восстановление контроллера домена с резервной магнитной ленты или восстановление Active Directory путем создания дополнительного контроллера домена. В некоторых ситуациях очевидно, что создание нового контроллера домена займет меньше времени, особенно если у вас есть сервер с Windows Server 2003 на быстром сегменте сети и размер вашей базы данных Active Directory не превышает 100 Мб. Однако в других ситуациях ремонт отказавшего контроллера домена и восстановление доменной информации с резервной копии может быть быстрее, особенно если ваша база данных велика, и другие контроллеры домена имеют медленное соединение. Большинство сценариев находится между этими крайностями. Чтобы понять, какой вариант оптимальнее для вашей среды, рекомендуется провести тестирование заранее.

Для восстановления базы данных Active Directory необходима актуальная резервная копия контроллера домена. Если вы столкнулись с проблемами только с диском, содержащим базу данных Active Directory, можно загрузиться в режим восстановления Active Directory и восстановить данные состояния системы. Если же возникли проблемы и с системным диском, необходимо устранить аппаратные проблемы, а затем восстановить сервер.

Иногда восстановление контроллера домена происходит на сервере с другим набором аппаратных средств. Несмотря на то, что можно восстановить Windows Server 2003 на другом оборудовании, этот процесс может вызвать проблемы. Если решите восстановить Windows Server 2003 на другом сервере, выберите максимально совместимое оборудование. Убедитесь, что уровень аппаратного абстрагирования (HAL), видеокарты и сетевые платы совпадают. Конфигурация жесткого диска на новом сервере также должна совпадать с первоначальным сервером. Несмотря на соблюдение этих мер предосторожности, восстановление Windows Server 2003 на другом оборудовании может быть сложным и не гарантирует успеха. Возможная альтернатива — создание контроллера домена из резервной копии, что позволит сочетать преимущества чистой установки Windows Server 2003 и использование начальной копии базы данных из резервной копии.

Автоматизированное восстановление системы

Один из вариантов резервирования и восстановления в Windows Server 2003 — это автоматизированное восстановление системы (Automated System Recovery — ASR). Эта опция упрощает процесс восстановления данных состояния системы. Прежде чем вы будете использовать ASR, создайте ASR-копию, т.е. с помощью инструмента Backup сделайте резервную копию данных состояния системы и создайте загрузочный диск ASR. Загрузочный диск содержит файлы, необходимые для загрузки сервера, а также информацию о конфигурации жесткого диска на сервере и резервную копию состояния системы. Если сервер выйдет из строя, эта ASR-копия может использоваться для частичной автоматизации восстановления сервера.

Если вы сделали какие-либо изменения к Active Directory после создания резервной копии, то они будут отсутствовать в копии. Однако другие контроллеры домена в домене будут иметь самую современную информацию. Если вы восстанавливаете контроллер домена в связи с поломкой сервера, то контроллер домена должен получить изменения от своих партнеров по репликации после того, как закончится восстановление. Для этого сделайте восстановление без полномочий.

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

Восстановите отказавший контроллер домена и повторно установите на сервере систему Windows Server 2003. После восстановления сервера перезапустите его и нажмите клавишу F8, чтобы загрузить Windows Advanced Options Menu (Меню дополнительных параметров Windows).

Выберите загрузку контроллера домена в режиме восстановления службы каталога Directory Services Restore Mode (Windows Domain Controllers Only) (Только контроллеры домена с системой Windows)). После этого контроллер домена загрузится в безопасном режиме, но не будут загружены компоненты Active Directory.
Выберите операционную систему, которую вы хотите запустить.
Войдите на сервер, используя учетную запись Administrator с паролем Directory Services Restore (Восстановление службы каталога), который был сконфигурирован на контроллере домена при инсталляции Active Directory.
Используйте программу создания резервной копии и восстановления системы, чтобы восстановить данные System State (Состояние системы) на сервере.
После восстановления данных перезагрузите контроллер домена.
После перезагрузки контроллер домена свяжется со своими партнерами по репликации и начнет обновлять собственную базу данных, чтобы отразить все изменения доменной информации, сделанные с момента создания резервной копии.

Примечание:
Восстанавливать информацию Active Directory могут только локальные администраторы. Эта учетная запись создается при инсталляции Active Directory на контроллере домена. Пароль для нее конфигурируется в это же время. Пароль может быть переустановлен только через утилиту Ntdsutil.

Выполнение восстановления с полномочиями

В некоторых случаях восстановление без полномочий не годится для решения проблемы, с которой вы имеете дело. Например, если кто-то только что удалил OU, содержащую несколько сотен пользователей, не нужно, чтобы контроллер домена просто перезагрузился после выполнения восстановления, а затем начал репликацию с других контроллеров домена. Если вы так сделаете, то контроллер домена получит информацию об удалении OU от своих партнеров по репликации, и к тому времени, как вы откроете инструмент Active Directory Users And Computers, OU будет удалена снова.

В этом сценарии нужно использовать восстановление с полномочиями для гарантии того, что восстановление OU будет реплицировано на другие контроллеры домена. Когда вы делаете это восстановление, восстанавливается резервная копия Active Directory, которая была сделана до того, как данные были удалены, а затем делаете принудительную репликацию этих данных на другие контроллеры домена. Принудительная репликация делается путем манипулирования порядковым номером обновления (USN) для восстановленной информации. По умолчанию, когда вы делаете восстановление с полномочиями, номер USN на восстановленных объектах увеличивается на 100000, чтобы восстановленный объект стал полномочной копией для всего домена.

Проблемы восстановления с полномочиями

Существует ряд проблем, связанных с восстановлением с полномочиями. Одна из ключевых проблем связана с групповым членством. В определенных ситуациях такое восстановление может вызвать ошибки в групповом членстве на контроллерах домена, которые не прошли процедуру восстановления с полномочиями. Эти ошибки могут возникать, когда восстановленный объект, такой как OU, содержит учетные записи групп и пользователей. Если информация о группе реплицируется раньше, чем информация о пользователе, это может привести к ошибкам в членстве группы. К сожалению, невозможно контролировать порядок репликации объектов.

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

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

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

Третья проблема имеет отношение к домену и доверительным отношениям компьютеров. Когда к домену добавляется компьютер, на котором выполняется система Microsoft Windows NT, Windows 2000, Windows XP Professional или Windows Server 2003, то создается пароль, известный только контроллеру домена и добавленному компьютеру-члену домена. Этот пароль используется для поддержания доверительных отношений между компьютером и доменом. По умолчанию пароль изменяется каждые семь дней. Если вы выполняете восстановление с полномочиями, то будут восстановлены пароли, которые были в использовании при создании резервной копии. Если компьютер-член домена уже получил другой пароль, то доверительные отношения между доменом и компьютером-членом домена не будут функционировать. Доверительные отношения NTLM между доменами Active Directory и доменами Windows NT используют похожие правила, поэтому они также могут перестать работать, если будет восстановлен старый пароль. Доверительные отношения домена можно восстановить, удаляя старые доверительные отношения и создавая их заново. Доверительные отношения рабочей станции с доменом можно восстановить, используя инструмент командной строки NetDom или удаляя рабочую станцию из домена, а затем добавляя ее назад.

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

Процедура восстановления с полномочиями

Наиболее типичным вариантом восстановления с полномочиями, вероятно, будет восстановление только части каталога. Например, если кто-то случайно удалит OU, вы должны восстановить с полномочиями только эту OU, а не весь каталог.

Чтобы выполнить восстановление с полномочиями, сделайте следующее.

Выполните шаги с первого по пятый процедуры восстановления без полномочий; не перезагружайте сервер, когда восстановление закончено.
Откройте командную строку и напечатайте ntdsutil.
В окне Ntdsutil напечатайте authoritative restore (восстановление с полномочиями).
В окне Authoritative Restore напечатайте restore subtree objectname (восстановление поддерева objectname). Например, чтобы восстановить OU Managers в домене NWTraders.com, нужно напечатать restore subtree ou=managers,dc=nwtraders,dc=com. Вы можете также восстановить индивидуальную группу, учетные записи пользователей (например, restore subtree en-manager1,ou=managers,dc=nwtraders,dc=com) или раздел приложений.
Чтобы восстановить с полномочиями весь каталог, напечатайте restore database (восстановить базу данных) в окне команды Authoritative Restore.
Выйдите из утилиты Ntdsutil и перезагрузите сервер.

Предостережение
В некоторых случаях потребуется восстановление всей базы данных Active Directory, используя восстановление с полномочиями. Такое восстановление всего каталога — это очень важная операция, она должна выполняться только в тех случаях, когда была разрушена база данных или произошла какая-то другая очень серьезная ошибка. Восстановление с полномочиями всего каталога увеличивает номер USN на каждом объекте в домене и в разделах конфигурации каталога на 100000. Раздел схемы не может быть восстановлен такими образом.

Восстановление информации Sysvol

До настоящего момента эта глава была посвящена восстановлению базы данных Active Directory, содержащей учетные записи и параметры настройки для домена или леса. Однако папка Sysvol на каждом контроллере домена тоже содержит критическую информацию, касающуюся домена, такую как шаблоны групповых политик и сценарии, используемые компьютерами или пользователями в сети. Поэтому восстановление информации Sysvol может быть столь же важным, как и восстановление базы данных Active Directory.

Резервная копия папки Sysvol создается как часть информации о состоянии системы, касающейся контроллера домена, т.е. если контроллер домена выйдет из строя, то информация Sysvol может быть восстановлена как часть обычного процесса восстановления контроллера домена. Кроме того, если вы не хотите восстанавливать контроллер домена, а только восстановить его функциональные возможности, создавая другой контроллер домена в домене, то информация Sysvol будет реплицироваться с любых существующих контроллеров домена. Это происходит при помощи службы репликации файлов (File Replication Service — FRS), а не в процессе репликации Active Directory.

Потенциально может возникнуть одно осложнение, если вам надо выполнить восстановление с полномочиями для контейнера Sysvol. Например, если кто-то удалил все сценарии входа в систему, находившиеся в папке Sysvol, вы захотите восстановить сценарии, вместо того чтобы заново создавать их. Проблема состоит в том, что, если удаление было реплицировано на все другие контроллеры домена, то оно будет иметь более довременное репликационное значение, чем на восстановленном контроллере домена. Поэтому если вы выполните просто обычное восстановление контроллера домена, то он реплицирует удаление с другого контроллера домена. Решение проблемы состоит в том, чтобы выполнить основное (primary) восстановление информации Sysvol. Если вы используете системную резервную копию сервера Windows Server 2003 и программу восстановления, то будет выполняться обычное восстановление без полномочий, но при выполнении программы восстановления не следует принимать заданные по умолчанию параметры настройки восстановления. Вместо этого в окне Advanced Restore Options (Дополнительные опции восстановления) мастера восстановления выберите опцию When Restoring Replicated Data Sets, Mark The Restored Data As The Primary Data For All Replicas (При восстановлении наборов реплицируемых данных отмечать восстановленные данные как основные для всех реплик) (см. рис. 15-3). В результате папка Sysvol на этом контроллере домена будет отмечена, как основной контейнер для репликации Sysvol.

Выполнение основного восстановления для Sysvol информации

Рис. 15-3. Выполнение основного восстановления для Sysvol информации

Восстановление хозяев операций и серверов глобального каталога

Роли серверов-хозяев операций требуют дополнительных соображений при планировании восстановления каталога после сбоя. Роли хозяев операций могут быть распределены между несколькими контроллерами домена, но в каждый момент времени каждая роль может удерживаться только одним контроллером домена в домене или лесе. Поэтому восстановление этих ролей отличается от восстановления контроллеров домена, которым не назначены роли хозяев операций. Восстановления контроллеров домена состоит, по существу, из таких же процедур, как и восстановления любого другого контроллера домена. Различие состоит в планировании того, что должно входить в восстановление после сбоя. Поскольку только один контроллер домена может удерживать определенную роль, то вы должны определить, как долго сеть будет работать без этого хозяина операций. В некоторых случаях отсутствие хозяина операций не причинит никаких неприятностей в течение нескольких дней, в других случаях отказ в выполнении функций этой роли может дать немедленный эффект. Если вы сможете восстановить контроллер домена, прежде чем понадобится роль хозяина операций, то вы можете восстановить контроллер домена и выполнить восстановление без полномочий сервера. Хозяин операций будет восстановлен после восстановления сервера.

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

Планирование

Из-за важности ролей, которые играют серверы-хозяева операций в сети, вы должны тщательно планировать размещение и управление этими ролями. Хозяин операций должен всегда включаться в регулярный режим резервного копирования. Он должен быть расположен в том же самом сайте, где находится, по крайней мере, один контроллер домена, содержащий информацию, имеющуюся у хозяина операций.

Например, если пользователь только что изменил свой пароль, используя клиента низкого уровня, то это изменение было сделано на эмуляторе PDC. Эмулятор PDC будет реплицировать это изменение партнеру по репликации, расположенному в том же самом сайте, в пределах 15 секунд. Если в этом сайте нет партнера по репликации, то репликация пароля не произойдет до следующей запланированной репликации между сайтами. Если контроллер домена выйдет из строя перед этим запланированным временем, то изменение пароля не будет реплицироваться на другие сайты. Если контроллер домена находится там же, где сервер хозяина операций, то вероятность неполной репликации гораздо меньше. Контроллер домена, находящийся в том же сайте, где расположен хозяин операций, является также наилучшим кандидатом на захват роли хозяина операций, потому что он имеет самую свежую информацию от хозяина операций. Если у вас имеется больше одного дополнительного контроллера домена в том же самом сайте, где расположен отказавший хозяин операций, то вы можете использовать команду repadmin / showvector namingcontext, чтобы определить, какой из контроллеров домена имеет самые свежие обновления с вышедшего из строя контроллера домена.

Чтобы захватить роли хозяина операций, вы можете использовать утилиту Ntdsutil или инструмент Active Directory Users And Computers (чтобы захватить роли эмулятора PDC и хозяина инфраструктуры). Роли хозяина RID, хозяина схемы и хозяина именования доменов можно захватить только с помощью утилиты Ntdsutil.

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

Откройте командную строку и напечатайте ntdsutil.
В окне команд Ntdsutil напечатайте roles(роли).
В окне команд Fsmo Maintenance (Обслуживание Fsmo) напечатайте connections(подключения).
В окне команд Server Connections (Подключения сервера) напечатайте connect to server servername.domainname(соединиться с сервером servername.domainname), где servername — контроллер домена, на котором вы хотите захватить роль хозяина операций. Напечатайте quit(выход).
В окне команд Fsmo Maintenance напечатайте seize operations_master_role(захватить роль хозяина операций). Где operations_master_role — это роли, которые вы хотите захватить: schema master(хозяин схемы), domain naming master(хозяин именования доменов), infrastructure master(хозяин инфраструктуры), RID-master(хозяин RID) или PDC.
Примите предупреждение. Сервер сначала будет пробовать выполнить нормальную передачу роли хозяина операций. Если это не получится, потому что с вышедшим из строя контроллером домена нельзя войти в контакт, то роль будет захвачена. На рисунке 15-4 смотрите пример захвата роли хозяина RID.

Вывод утилиты Ntdsutil при захвате роли хозяина RID

Рис. 15-4. Вывод утилиты Ntdsutil при захвате роли хозяина RID

Напечатайте quit(выход) в каждой командной строке, пока не выйдете из утилиты Ntdsutil.

Эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены также через инструмент администрирования Active Directory Users And Computers. Откройте инструмент Active Directory Users And Computers и используйте опцию Connect To Domain Controller (Подключиться к контроллеру домена), чтобы удостовериться, что он связан с контроллером домена, на котором вы хотите захватить роль. Затем щелкните правой кнопкой мыши на имени домена и выберите Operations Masters (Хозяева операций). Если вы попробуете захватить роль, получите предупреждающее сообщение (см. рис. 15-5). Если вы выберите вынужденную передачу, то роль хозяина операций будет захвачена. Только эмулятор PDC и роль хозяина инфраструктуры могут быть захвачены таким образом, т.е. попытки передать любую другую роль хозяина операций с помощью другого инструмента, кроме утилиты Ntdsutil, потерпят неудачу.

Предупреждающее сообщение, полученное при захвате роли хозяина операций через инструмент Active Directory Users And Computers

Рис. 15-5. Предупреждающее сообщение, полученное при захвате роли хозяина операций через инструмент Active Directory Users And Computers

Эмулятор PDC

В большинстве сетей отказ эмулятора PDC обычно вызывает немедленный отклик, чем отказ любого другого хозяина операций. В домене, который работает на функциональных уровнях Windows 2000 mixed (смешанный) или Windows Server 2003 interim (временный), эмулятор PDC является основным (primary) партнером по репликации для всех резервных копий контроллеров домена Windows NT (BDC). Пока не восстановлен эмулятор PDC, BDC-контроллеры не будет получать модифицированную информацию. Кроме того, низкоуровневые клиенты типа Windows NT, Windows 95 и Windows 98 (не имеющие клиентов службы каталога) должны соединяться с эмулятором PDC, чтобы пользователь имел возможность изменять свой пароль. Даже в домене, работающем на функциональном уровне Windows 2000 native (естественный) или на более высоком, эмулятор PDC играет роль основного партнера по репликации для замен пароля. Эмулятор PDC является также предпочтительным сервером для создания каких-либо изменений к групповым политикам. Если эмулятор PDC недоступен, когда вы пытаетесь просмотреть групповые политики, вы получите предупреждающее сообщение. Поскольку эмулятор PDC поддерживает все эти службы, то восстановление роли эмулятора PDC в сети должно иметь высокий приоритет.

Хотя эмулятор PDC играет важнейшую роль в домене, захват этой роли другим контроллером домена, в то время как оригинальный эмулятор PDC недоступен, имеет свои ограничения. Фактически, захват этой роли подобен захвату роли PDC в домене Windows NT. Если PDC когда-либо выходил из строя в домене Windows NT, вы могли выбирать другой контроллер домена и конфигурировать его так, чтобы он был PDC-контроллером. Те же самые функциональные возможности существуют в Windows Server 2003. Если эмулятор PDC выходит из строя, вы должны передать эту роль на другой контроллер домена. Даже если контроллер домена будет недоступен только в течение пары часов, все равно нужно передать эту роль. Когда оригинальный эмулятор PDC будет восстановлен и снова связан с сетью, он обнаружит присутствие нового эмулятора PDC и уступит ему эту роль.

Хозяин схемы

Хозяин схемы играет важнейшую роль в домене сервера Windows Server 2003, но эта роль используется очень редко. Хозяин схемы является единственным контроллером домена, в котором может быть изменена схема. Если этот сервер выйдет из строя, вы не сможете делать изменения к схеме, пока сервер не будет восстановлен или пока эта роль не будет захвачена другим контроллером домена.

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

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

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

Хозяин именования доменов

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

Примечание:
В большинстве сетей роли хозяина схемы и хозяина именования доменов используются настолько редко, что если эти контроллеры домена выходят из строя, их не нужно захватывать, передавая их другому серверу. Однако эти контроллеры домена обычно располагаются в корневом домене леса, а контроллеры домена корня леса имеют важное значение. Если у вас имеется только один контроллер домена корня леса и он выходит из строя, это, безусловно, окажет воздействие на сеть. Любой тип деятельности, охватывающий несколько доменов, такой как вход на другие домены, кроме вашего домашнего домена, или доступ к ресурсам, расположенным в другом домене, будет вызывать отказ, если отсутствуют другие корневые контроллеры домена (кроме тех случаев, когда существует другой путь через доверительные отношения между доменами). Таким образом, хотя хозяин схемы и хозяин именования доменов не обязательно должны быть всегда доступны, но в вашем корневом домене должен быть всегда доступен, по крайней мере, один контроллер домена.

Хозяин инфраструктуры

Роль хозяина инфраструктуры наименее существенна с точки зрения восстановления системы после сбоя. Хозяин инфраструктуры следит за изменением отображаемых имен для учетных записей пользователей и групп в среде, состоящей из нескольких доменов. Эта деятельность прозрачна для обычных пользователей, и может стать проблемой только тогда, когда администраторы рассматривают членство группы. Поэтому захват роли хозяина инфраструктуры должен иметь довольно низкий приоритет из-за того, что эта роль не оказывает влияния на какие-либо сетевые службы.

Если вы решите захватить роль хозяина инфраструктуры и передать ее на другой контроллер домена в среде, состоящей из нескольких доменов, вы должны гарантировать, что контроллер домена-адресата не является GC-сервером. Впоследствии можно восстановить первоначального хозяина инфраструктуры.

Хозяин RID

Хозяин RID — это хозяин операций уровня домена, который назначает RID-пулы другим контроллерам домена по мере создания новых участников безопасности. Если хозяин RID недоступен в течение длительного периода времени, то у контроллеров домена могут закончиться относительные идентификаторы RID, необходимые для назначения их новым участникам безопасности. Каждый раз, когда у контроллера домена заканчиваются свободные идентификаторы RID, он запрашивает дополнительные пулы идентификаторов RID у хозяина RID. Затем хозяин RID выдает дополнительный пул, состоящий из 512 идентификаторов RID. Если хозяин RID недоступен, то контроллер домена не разрешит создание новых участников безопасности, пока не получит дополнительные идентификаторы RID у хозяина RID. Хозяин RID важен и при перемещении участников безопасности между доменами. В этом случае, если хозяин RID недоступен, то перемещение учетных записей немедленно потерпит неудачу.

Если ваш контроллер домена, являющийся хозяином RID выходит из строя, вы должны решить, нужно ли вам захватывать эту роль, передавая ее другому серверу. Если вам требуется создать большое количество участников безопасности или перемещать пользователей между доменами, прежде чем восстановится хозяин RID, то вы должны захватить эту роль. Кроме того, если не планируется восстанавливать оригинального хозяина RID, вы также должны захватить эту роль. Если вы решите захватить роль хозяина RID, то оригинальный хозяин RID не должен возвращаться в интерактивный режим из-за потенциальной возможности выдачи дублирующих идентификаторов защиты (SID).

GC-серверы

Серверы глобального каталога (GC) требуют дополнительного планирования для восстановления при сбоях, хотя специальные требования для создания резервных копий отсутствуют. Главное, о чем стоит помнить: для многих доменов леса база данных каталога на GC-сервере будет больше по сравнению с другими контроллерах домена. При восстановлении GC-сервера путем восстановления базы данных на контроллере домена, сервер настроится как GC-сервер автоматически. Если же решено восстановить функции Active Directory, назначив другой сервер контроллером домена, этот сервер следует настроить как GC-сервер.

GC-сервер в сети критически важен для обслуживания входа клиентов в домен на функциональном уровне Windows 2000 native или выше, а также при использовании основных имен пользователя (UPN). Это особенно актуально при развертывании Microsoft Exchange Server 2000. В случае сбоя единственного GC-сервера в сайте с Exchange Server 2000, потребуется настроить другой контроллер домена на том же сайте как GC-сервер и быстро восстановить функциональность.

Источник

Обновлено 20.01.2019

Добрый день уважаемые читатели и гости блога Pyatilistnik.org, сегодня будет очень жизненная и на сто процентов практическая статья и посвящена она будет, трабшутингу Active Directory. Не так давно я вам рассказывал, как производится правильное удаление неисправного или недоступного контроллера домена, все хорошо, но может получиться ситуация, что именно он является носителем ролей FSMO, и перед его удалением вам нужно будет произвести принудительный захват ролей мастера-операций Active Directory.

Давайте выполним в командной строке вот такую команду:

Нужные мне три нижние роли принадлежат dc10. их и будем забирать. Для этого вы должны быть, как минимум администратором домена.

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

Не удается передать роль хозяина операций по следующей причине: Ошибка требуемой операции FSMO. Нет связи с текущим владельцем FSMO.

Это я увидел в оснастке Active Directory — Пользователи и компьютеры, при попытке по правильному передать роль RID.

Если попытаться получить роль PDC эмулятора с недоступных контроллером, то он даст вам это сделать в ADUC, но вы увидите предупреждение.

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

Говорим «Да»

Все роль PDC получена.

Тоже самое проделаем с мастером инфраструктуры. Выполнив опять запрос в командной строке, кто держит FSMO роли, видим, что это уже для двух нижних ролей, dc7, новый контроллер.

Теперь захватим роль RID, в этом нам поможет утилита ntdsutil. Открываем командную строку для принудительного захвата.

Вводим ntdsutil, попадем в исполняемую среду.
Далее пишем roles
в fsmo maintenance: пишем connections
в server connections: пишем connect to server имя сервера у меня это dc7
server connections: q
пишем в fsmo maintenance: seize RID master

Вам напишут: Попытка безопасной передачи RID FSMO перед захватом. Ошибка ldap_modify_sW, код ошибки 0x34<52 (Нет данных). Расширенное сообщение об ошибке LDAP 000020AF: SvcErr: DSID-03210F70, problem 5002, data 1722. Возвращенная ошибка Win32 0x20af (Ошибка требуемой операции FSMO. Нет связи с текущим владельцем FSMO).

У вас выскочит окно с подтверждением операции, нажимаем «Да.» В итоге роль все равно передастся, это можно увидеть сразу в ADUC.

Если нужно принудительно захватить с помощью ntdsutil оставшиеся роли, то их ключи для последней команды:

seize PDC
seize infrastructure master
seize domain naming master (Seize naming master )
seize schema master

Вот так вот по правильному происходит принудительная передача ролей мастер операций в Active Directory, если есть вопросы, то пишите их в комментариях.

Источник