Передача ролей fsmo

Перенастройка интерфейсов, DNS и другие послеустановочные задачи

Далее, так как DNS-сервер на dc02 мы установили, теперь нужно в свойствах сетевого интерфейса первичным DNS-сервером указать самого себя, т. е. адрес 192.168.1.12. И на dc01 соответственно поменять на 192.168.1.12.

В свойствах DNS-сервера на dc02 проверьте вкладку Forwarders, на 2003, в отличие от 2008, она не реплицируется. После этого можно понижать контроллер домена dc01 до рядового сервера.

Если вам необходимо у нового контроллера оставить старое имя и IP-адрес, то это также делается без проблем. Имя меняется как для обычного компьютера, либо командой netdom renamecomputer.

После смены IP-адреса выполните команды ipconfig /registerdns и dcdiag /fix.

Просмотр и передача ролей FSMO в Windows Server

2007-03-08 · Posted in Active Directory, Windows Server 2003, Windows Server 2008, Windows Server 2012, Windows Server 2016/2019

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

Хозяин схемы. Контроллер домена, являющийся хозяином схемы, управляет всеми обновлениями и изменениями схемы. Обновление схемы леса невозможно без доступа к хозяину схемы. В лесу может быть только один хозяин схемы.
Хозяин именования доменов. Контроллер домена, исполняющий роль хозяина именования, управляет добавлением и удалением доменов из леса. В лесу может быть только один хозяин именования доменов.
Хозяин инфраструктуры. Хозяин инфраструктуры отвечает за обновление ссылок объектов домена на объекты других доменов. Одновременно в домене может существовать только один хозяин инфраструктуры.
Хозяин относительных идентификаторов (RID). Хозяин RID отвечает за обработку запросов на относительные идентификаторы от всех контроллеров в данном домене. Одновременно в домене может существовать только один хозяин RID.
Эмулятор основного контроллера домена (PDC). Эмулятор PDC — это контроллер, объявляющий себя основным контроллером домена по отношению к рабочим станциям, серверам и контроллерам домена под управлением Windows более ранних версий. Например, если не все компьютеры в домене находятся под управлением Windows XP Professional и Windows 2000 или в нем имеются резервные контроллеры домена под управлением Windows NT, эмулятор PDC принимает роль основного контроллера домена Windows NT. Кроме того, он становится основным обозревателем домена и обрабатывает расхождения паролей. Одновременно в каждом домене леса может существовать только один эмулятор PDC.

Передача ролей FSMO выполняется с помощью программы Ntdsutil.exe (запускается из командной строки) или оснасток консоли MMC. В зависимости от передаваемой роли используются:

оснастка «Схема Active Directory»;
оснастка «Active Directory — домены и доверие»;
оснастка «Active Directory — пользователи и компьютеры».

Если компьютер больше не существует, роль необходимо присвоить с помощью программы Ntdsutil.exe.
Посмотреть текущие роли:

netdom query fsmo
repadmin /showrepl

1 2	netdom query fsmo repadmin/showrepl

Для передачи роли хозяина схемы используется оснастка «Схема Active Directory». Перед ее запуском необходимо зарегистрировать файл Schmmgmt.dll.

1) Регистрация файла Schmmgmt.dll

Нажмите кнопку Пуск и выберите пункт Выполнить.
Введите в поле Открыть команду

regsvr32 schmmgmt.dll

1 regsvr32 schmmgmt.dll

(с правами администратора) и нажмите кнопку OK.
Получив сообщение об успешном завершении операции, нажмите кнопку ОК.

2) Передача роли хозяина схемы

Нажмите кнопку Пуск, выберите пункт Выполнить, введите в поле Открыть команду mmc и нажмите кнопку ОК.
В меню Файл выберите команду Добавить или удалить оснастку.
Нажмите кнопку Добавить.
Выберите в списке оснастку Схема Active Directory, нажмите кнопку Добавить, а затем — Закрыть и ОК.
В дереве консоли щелкните правой кнопкой мыши элемент Схема Active Directory и выберите пункт Изменение контроллера домена.
В поле Укажите имя введите имя контроллера домена, которому передается роль, и нажмите кнопку ОК.
В дереве консоли щелкните правой кнопкой мыши элемент Схема Active Directory и выберите пункт Хозяин операций.
Нажмите кнопку Изменить.
Чтобы подтвердить передачу роли, нажмите кнопку ОК, а затем — Закрыть.

3) Передача роли хозяина именования доменов

Нажмите кнопку Пуск, выберите пункт Администрирование, а затем — Active Directory — домены и доверие.
Щелкните правой кнопкой мыши элемент Active Directory — домены и доверие и выберите команду Подключение к контроллеру домена.Примечание. Это действие необходимо, если работа ведется не с контроллера домена, которому передается роль. Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено.
Выполните одно из следующих действий.
- Укажите имя контроллера домена, которому присваивается роль, в поле Введите имя другого контроллера домена и нажмите кнопку ОК.или
- Выберите контроллер домена, которому присваивается роль, в списке Или выберите доступный контроллер домена и нажмите кнопку ОК.
В дереве консоли щелкните правой кнопкой мыши элемент Active Directory — домены и доверие и выберите пункт Хозяин операций.
Нажмите кнопку Изменить.
Чтобы подтвердить передачу роли, нажмите кнопку ОК, а затем — Закрыть.

4) Передача ролей хозяина RID, эмулятора основного контроллера домена и хозяина инфраструктуры

Передача FSMO ролей с помощью PowerShell

Самый простой и быстрый способ передачи FSMO ролей в домене – PowerShell командлет Move-ADDirectoryServerOperationMasterRole.

Вы можете передать на указанный DC одну или несколько FSMO ролей за раз. Следующая команда выполнит передачу двух ролей на DC02:

В аргументе OperationMasterRole можно указать как имя FSMO роли, так и ее индекс в соответствии с таблицей:https://yastatic.net/safeframe-bundles/0.83/1-1-0/protected/render.htmlРЕКЛАМА

PDCEmulator
RIDMaster	1
InfrastructureMaster	2
SchemaMaster	3
DomainNamingMaster	4

Предыдущая команда в более коротком виде выглядит так:

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

Moving FSMO roles between domain controllers

By default AD assigns all operations master roles to the first DC created in a forest. To provide fault tolerance, there should be multiple domain controllers available within each domain of the Forest. If new domains are created in the forest, the first DC in a new domain holds all of the domain-wide FSMO roles. This is not a satisfactory position if the domain has a large number of domain controllers. Microsoft recommends the careful division of FSMO roles, with standby DCs ready to take over each role. The PDC emulator and the RID master should be on the same DC, if possible. The Schema Master and Domain Naming Master should also be on the same DC.

When a FSMO role is transferred to a different DC, the original FSMO holder and the new FSMO holder communicate to ensure no data is lost during the transfer. If the original FSMO holder experienced an unrecoverable failure, another DC can be made to seize the lost roles; however, there is a risk of data loss because of the lack of communications. Seizing roles from a domain controller instead of transferring it prevents that domain controller from hosting that FSMO role again, except for the PDC Emulator and Infrastructure Master Operation roles. Corruption can occur within Active Directory. FSMO roles can be easily moved between DCs using the AD snap-ins to the MMC or using , which is a command line-based tool.

Методы клонирования объекта групповой политики

Существует несколько методов, позволяющих вам произвести полное копирование GPO:

Через оснастку управление групповыми политиками GPMC
Это использование моего любимого сильного языка, PowerShell

Открываем оснастку «Управление групповой политикой (gpmc.msc)». Находим нужный объект GPO который вам необходимо скопировать. В моем примере, это будет «Управление UIPI».

Посмотрим на вкладке «Параметры», что делает данная политика. Я ее использовал для отключения User Interface Privilege Isolation.

Далее переходим в контейнер «Объекты групповой политики», который содержит все ваши объекты GPO присутствующие в данном домене Active Directory. Щелкаем правым кликом по нужному и из контекстного меню выбираем пункт «Копировать».

Вот вы нажали скопировать и ничего не произошло, на мой взгляд, что Microsoft сделала очень не очевидно, что нужно делать дальше, особенно если вы делаете, это впервые. Парадокс заключается в том, что скопировать объект GPO вы можете только в контейнере «Объекты групповой политики» и нигде более. Вот почему бы сразу сюда не вставлять? Чтобы вы могли теперь создать скопированный объект GPO, кликните правым кликом по данному контейнеру и из контекстного меню выберите «Вставить».

У вас появится дополнительное окно с выбором действий «Копирование объекта групповой политики»:

Использовать разрешения по умолчанию для новых объектов групповой политики
Сохранить существующие разрешения

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

В итоге у вас появится новый объект GPO. у которого в начале названия будет слово «Копия»

Обратите внимание, что все разрешения я сохранил, это видно по списку в фильтре безопасности и примененному WMI фильтру. Так же стоит отметить, что у новой политики, будет новый GUID, можете проверить на вкладке «Сведения»

Для вашего удобства советую вам переименовать новую политику, через клавишу F2 или контекстное меню.

Теперь посмотрим на сколько удобнее, это сделать через PowerShell. Для начала откройте PowerShell от имени администратора. Первым делом я вам предлагаю посмотреть вашу текущую политику, для этого есть командлет Get-GPO и вот такая конструкция.

get-gpo -Name «Управление UIPI»

Убедившись, как называется объект GPO и удостоверившись, что он вообще есть мы приступаем к его копированию. Для этого воспользуемся командлетом Gopy-GPO (https://docs.microsoft.com/en-us/powershell/module/grouppolicy/copy-gpo?view=win10-ps)

Copy-GPO -SourceName «Управление UIPI» -TargetName «Copy_Управление UIPI» -CopyAcl

SourceName — Имя копируемой политики
TargetName — Имя новой политики
-CopyAcl — Копирует все разрешения на политику GPO.

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

Так же вы можете проводить копирование между доменами. Между исходным доменом и доменом назначения должны существовать доверительные отношения.

Copy-GPO -SourceName «Gpo01» -SourceDomain «root.pyatilistnik.org» TargetName «Gpo01» -TargetDomain «sales.pyatilistnik.org»

Для переименовывания политики, через PowerShell можно применить командлет Rename-GPO.

Rename-GPO -Name «Copy_Управление UIPI» -TargetName «Update_Управление UIPI»

На этом у меня все и надеюсь, что вам было интересно и полезно получить новые знания. С вами был Иван Семин, автор и создатель IT блога Pyatilistnik.org.

Дополнительная информация

В лесу доменных служб Active Directory (AD DS) существуют определенные задачи, которые должен выполнять только один контроллер домена (DC). Контроллеры домена, которым назначены эти уникальные операции, называются владельцами ролей «Хозяин операций». В следующей таблице перечислены роли хозяина операций и их размещение в Active Directory.

Роль	Область	Контекст именования (раздел Active Directory)
Хозяин схемы.	На уровне леса	CN=Schema,CN=configuration,DC=<корневой домен леса>
Хозяин именования доменов	На уровне леса	CN=configuration,DC=<корневой домен леса>
Эмулятор PDC	На уровне домена	DC=<domain>
Хозяин RID	На уровне домена	DC=<domain>
Хозяин инфраструктуры	На уровне домена	DC=<domain>

Дополнительные сведения о владельцах ролей «Хозяин операций» и рекомендации по размещению ролей см. в разделе Размещение и оптимизация FSMO на контроллерах домена Active Directory.

Примечание.

Разделы приложений Active Directory, включающие разделы приложений DNS, имеют ссылки на роль «Хозяин операций». Если раздел приложения DNS определяет владельца роли хозяина инфраструктуры ( IM), вы не можете использовать Ntdsutil, DCPromo или другие средства для удаления этой секции приложения. Дополнительные сведения см. в разделе Сбой при понижении роли DCPROMO, если не удается связаться с хозяином инфраструктуры DNS.

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

Сведения, которые контроллеры домена передают в рамках репликации Active Directory, включают удостоверения текущих владельцев ролей «Хозяин операций». Когда только что запущенный контроллер домена получает сведения о входящей репликации, он проверяет, является ли он по-прежнему владельцем роли. Если это так, он возобновляет обычные операции. Если сведения о репликации указывают, что в качестве владельца роли выступает другой контроллер домена, недавно запущенный контроллер домена освобождает владение своей ролью. Такое поведение снижает вероятность того, что в домене или лесе будут дублироваться владельцы ролей хозяина операций.

Важно!

Операции AD FS завершаются сбоем, если им требуется владелец роли и если только что запущенный владелец роли фактически является владельцем роли и не получает входящую репликацию.
Результирующее поведение похоже на то, что произошло бы, если бы владелец роли находился в автономном режиме.

FSMO roles

Per-domain roles

These roles are applicable at the domain level (i.e., there is one of each for every domain in a forest):

The PDC Emulator (Primary Domain Controller) — This role is the most used of all FSMO roles and has the widest range of functions. The domain controller that holds the PDC Emulator role is crucial in a mixed environment where Windows NT 4.0 BDCs are still present. This is because the PDC Emulator role emulates the functions of a Windows NT 4.0 PDC. Even if all Windows NT 4.0 domain controllers have been migrated to Windows 2000 or later, the domain controller that holds the PDC Emulator role still does a lot. The PDC Emulator is the domain source for time synchronization for all other domain controllers; in a multi-domain forest, the PDC Emulator in each domain synchronizes to the forest root PDC Emulator. All other domain member computers synchronize to their respective domain controllers. It is critically important that computer clocks are synchronized across the forest because excessive clock skew causes Kerberos authentication to fail. In addition, all password changes occur on the PDC Emulator and receive priority replication.
The RID Master — (Relative ID) This FSMO role owner is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for moving an object from one domain to another during an interdomain object move. When a DC creates a security principal object such as a user or group, it attaches a unique SID to the object. This SID consists of a domain SID (the same for all SIDs created in a domain) and a relative ID (RID) that is unique for each security principal SID created in a domain. Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC’s allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain’s RID Master FSMO role owner, the RID Master FSMO role owner responds to the request by retrieving RIDs from the domain’s unallocated RID pool and assigns them to the pool of the requesting DC.
The Infrastructure Master — The purpose of this role is to ensure that cross-domain object references are correctly handled. For example, if a user from one domain is added to a security group from a different domain, the Infrastructure Master makes sure this is done properly. However, if the Active Directory deployment has only a single domain, then the Infrastructure Master role does no work at all, and even in a multi-domain environment it is rarely used except when complex user administration tasks are performed. This applies to the domain partition (default naming context) only. netdom query fsmo and ntdsutil will only query the domain partition. However, every application partition, including Forest and Domain-level DNS domain zones has its own Infrastructure Master. The holder of this role is stored in the fSMORoleOwner attribute of the Infrastructure object in the root of the partition, it can be modified with ADSIEdit, for example one can modify the fSMORoleOwner attribute of the CN=Infrastructure,DC=DomainDnsZones,DC=yourdomain,DC=tld object to CN=NTDSSettings,CN=Name_of_DC,CN=Servers,CN=DRSite,CN=Sites,CN=Configuration,DC=Yourdomain,DC=TLD.

per-forest roles

These roles are unique at the forest level (both are located in the forest root domain):

The Schema Master — The purpose of this role is to replicate schema changes to all other domain controllers in the forest. Since the schema of Active Directory is rarely changed, however, the Schema Master role will rarely do any work. This role is typically involved in the deployment of Exchange Server and Skype for Business Server, as well as domain controllers from one version to another version, as all of these situations involve making changes to the Active Directory schema.
The Domain Naming Master — The other forest-specific FSMO role is the Domain Naming Master, and this role also resides in the forest root domain. The Domain Naming Master role processes all changes to the namespace, for example adding the child domain vancouver.mycompany.com to the forest root domain mycompany.com requires that this role be available. Failure of this role to function correctly can prevent the addition of a new child domain or new domain tree.

Захват и передача роли

Все роли могут быть переданы от одного контроллера домена другому при условии работоспособности обоих серверов. В случае, когда один из серверов не может продолжать работу, используется процедура захвата (англ. seize) роли другим сервером, выполняемая системным администратором вручную. В этом случае не производится обращений к прежнему владельцу роли. Новый контроллер домена просто «приступает к исполнению обязанностей». Необходимо помнить, что появление в сети прежнего владельца роли после её захвата новым не допустимо для трёх из пяти ролей (владелец схемы, владелец доменных имен, владелец относительных идентификаторов).

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

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

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

Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом

Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:

The trust relationship between this workstation and the primary domain failed.

1	The trust relationship between this workstation and the primary domain failed.

Не удалось восстановить доверительные отношения между рабочей станцией и доменом.

1	Не удалось восстановить доверительные отношения между рабочей станцией и доменом.

Также ошибка может выглядеть так:

The security database on the server does not have a computer account for this workstation trust relationship.

1	The security database on the server does not have a computer account for this workstation trust relationship.

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

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

Лучшие практики

Сервер глобального каталога хранит у себя полную реплику данных своего домена, а также частичную реплику каждого домена леса. Частичная реплика включает в себя данные об объектах, состоящие из GUID, SID, а также различающегося имени объекта. То есть хранит все те же данные, что и фантомные записи хозяина инфраструктуры. Таким образом, если Infrastructure Master располагается на сервере Глобального каталога, то новые фантомные объекты создаваться/изменяться/удаляться не будут, поскольку глобальный каталог и так хранит подобные записи у себя. Следствием этого будет неактуальная информация о междоменных объектах (cross-domain object) у других контроллеров этого домена, ведь они по-прежнему обращаются к хозяину инфраструктуры для получения информации об объектах других доменов. Из этого следует один вывод :

Не размещайте хозяина инфраструктуры на сервере глобального каталога, если не все DC в лесу являются серверами глобального каталога.

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

Сделайте все контроллеры домена в лесу серверами глобального каталога.

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

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

Хозяин инфраструктуры не нужен, когда:

Лес AD состоит из одного домена;
В многодоменном лесу каждый контроллер домена является сервером глобального каталога.

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

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

Пожалуй на этом все.

Тяни за ярлык:

about windows 7;ca and outlook;dns and ca;english togetherESX или ESXi?;Exchange 2010exchange 2019forest exchangeinfo about firewalls 2009install DHCP в win2008linux and unix serversms project;Office2010;Outlook and RPC/HTTP;PGP;public_mail on isa2004;RPC/HTTP-прокси на Exchange;setup exchange 2007;setup exchange 2010;setup isa2004;SMTP на Exchange;symantec and exchange;trendmicroUpgrade Esxi 3.5 до Esxi 4.0;vmware 6.7VMWare Vsphere 4;win 2008windows 8windows 2016Ваш первый Exchange;Корпоративный файл-сервер;Мое первое знакомство с VMWare;Настройка IIS 6.0;Настройка коннектора;Ручная установка Win 2008Установка DC;Установка Exchange 2003 sp2как я отдыхал…синематограф

Перенос ролей FSMO

Контролер домена может использовать следующие 5 ролей:

Владелец схемы (Schema master) — один сервер с этой ролью на весь лес. Роль нужна для расширения схемы леса Active Directory, обычно эта операция выполняется командой adprep /forestprep
Владелец доменных имён (Domain naming master) — один на весь лес. Сервер с данной ролью должен обеспечить уникальность имен для всех создаваемых доменов и разделов приложений в лесу AD.
Владелец относительных идентификаторов (PDC emulator) — один сервер на каждый домен. Выполняет несколько функций: является основным обозревателем в сети Windows, отслеживает блокировки пользователей при неправильно введенном пароле, являетсяглавным NTP сервером в домене, предназначен для поддержки клиентов с ОС предшествующим Windows 2000.
Эмулятор основного контроллера домена (Infrastructure Master) — один сервер на каждый домен. Сервер с такой ролью нужен для успешного выполнения команды adprep /domainprep. Отвечает за обновление идентификаторов защиты (GUID, SID)и различающихся имен объектов в междоменных объектных ссылках.
Владелец инфраструктуры домена (RID Master) — один сервер на каждый домен. Сервер раздает другим контроллерам домена идентификаторы RID (по 500 штук) для создания уникальных SID.
Для управления ролью Schema master необходимо быть в группе «Schema admins».

Для управления ролью Domain naming master необходимо состоять в группе «Enterprise admins».
Для управления ролями PDC emulator, Infrastructure Master и RID Master необходимо иметь права администратора домена «Domain Admins»

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

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

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

Это особенно важно при отключении эмулятора PDC. Временное отключение остальных хозяев операций в меньшей степени сказывается на работе AD.

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

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

Итак первое что нам понадобится это узнать какой сервер является хозяином FSMO. Проще всего это сделать с помощью утилиты netdom. Набрав в консоли:

netdom query fsmo

Мы получим список всех пяти ролей с указанием FQDN хозяев.

Передача роли

Перед тем как производить дальнейшие операции, следует позаботиться о резервной копии AD, мало ли что пойдет не так. Как и в случае с Win-системой, роли хозяина операций с одного КД (PDC) можно передать на другой КД (BDC) или принудительно забрать роли с PDC на BDC. Первый способ описан в документации MS, проще для этого использовать GUI-средства — MMC-консоль «Схема Active Directory» (если ее нет, в окне выбора MMC нужно ввести regsvr32 schmmgmt.dll), консоли «Active Directory — домены и доверие» и «Active Directory — пользователи и компьютеры». Другой вариант — использовать командную утилиту ntdsutil.

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

Иногда приходится добавлять параметр . Можно забрать конкретную роль, для чего ее указываем вместо all: rid, schema, naming, pdc и infrastructure. Проверяем:

Команда transfer позволяет передать роли другому контроллеру домена:

Для управления доменом, работающим под Samba, используем стандартные утилиты администрирования серверной Win или для клиентских ОС Win — Administration Tools Pack/RSAT. Некоторые операции можем производить и при помощи samba-tool. Например, поднимем функциональный уровень леса до Win 2008 R2:

Также в контексте domain можем просмотреть и изменить установки паролей:

Установим минимальную длину пароля в десять символов:

Просмотр установок паролей

Заключение

Неужели бэкап контроллера домена — это так просто? Да и нет. Успешный бэкап — это хорошее начало, но далеко не все. В Veeam говорят: «Резервная копия ничего не стоит, если из нее нельзя восстановить данные».

Следующие статьи в этой серии будут посвящены различным сценариям восстановления Active Directory, включая восстановление контроллера домена, а также восстановление отдельных удаленных и измененных объектов с помощью собственных инструментов Microsoft и Veeam Explorer для Active Directory.

Также вас может заинтересовать:

Статья Восстановление объектов Active Directory
Подробная информация о Veeam Explorer для Microsoft Active Directory