- Восстановление Active Directory из резервной копии
- Восстановление контроллера домена AD через репликацию
- Типы восстановления Active Directory: полномочное и неполномочное
- Восстановление контроллера домена AD из system state бэкапа
- Восстановление отдельных объектов в AD
- Настройка аварийного восстановления для Active Directory и DNS Set up disaster recovery for Active Directory and DNS
- Предварительные требования Prerequisites
- Репликация контроллера домена Replicate the domain controller
- Включение защиты с помощью Site Recovery Enable protection with Site Recovery
- Защита виртуальной машины Protect the VM
- Настройка параметров сети виртуальной машины Configure VM network settings
- Защита Active Directory Protect Active Directory
- Защита «сайт-сайт» Site-to-site protection
- Защита «сайт-Azure» Site-to-Azure protection
- Защита «Azure — Azure» Azure-to-Azure protection
- Рекомендации по тестированию отработки отказа Test failover considerations
- Тестовая отработка отказа на дополнительный сайт Test failover to a secondary site
- Удаление ссылок на другие контроллеры домена Remove references to other domain controllers
- Вопросы, связанные с мерами по обеспечению безопасности виртуализации Issues caused by virtualization safeguards
- Признаки применения мер по обеспечению безопасности виртуализации Symptoms of virtualization safeguards
- Устранение неполадок контроллера домена при тестовой отработке отказа Troubleshoot domain controller issues during test failover
- Контроллер домена и DNS на разных компьютерах DNS and domain controller on different machines
- Дальнейшие действия Next steps
Восстановление Active Directory из резервной копии
В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State, созданной ранее (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.
Допустим у вас вышел из строя контроллер домена AD, и вы хотите восстановить его из созданной ранее резервной копии. Прежде чем приступить к восстановлению DC, нужно понять какой сценарий восстановления контроллера домена вам нужно использовать. Это зависит от того, есть ли у вас в сети другие DC и повреждена ли база Active Directory на них.
Восстановление контроллера домена AD через репликацию
Восстановление DC через репликацию – это не совсем процесс восстановления DC из бэкапа. Этот сценарий может использоваться, если у вас в сети есть несколько дополнительных контроллеров домена, и все они работоспособны. Этот сценарий предполагает установку нового сервера, повышение его до нового DC в этом же сайте. Старый контроллер нужно просто удалить из AD.
Это самый простой способ, который гарантирует что вы не внесете непоправимых изменений в AD. В этом сценарии база ntds.dit, объекты GPO и содержимое папки SYSVOL будут автоматически реплицированы на новый DC с DC-ов, оставшихся онлайн.
Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа.
Типы восстановления Active Directory: полномочное и неполномочное
Есть два типа восстановления Active Directory DS из резервной копии, в которых нужно четко разобраться перед началом восстановления:
- Authoritative Restore (полномочное или авторитативное восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Таким образом восстановленные объекты будут восприняты всеми DC как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно.
Восстановление контроллера домена AD из system state бэкапа
Итак, предположим, что у вас в домене только один DC. По какой-то причине вышел из строя физический сервер, на котором он запущен.
У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.
Чтобы приступить к восстановлению, вам нужно установить на новом сервер туже версию Windows Server, которая была установлена на неисправном DC. В чистой ОС на новом сервере нужно установить роль ADDS (не настраивая ее) и компонент Windows Server Backup.
Для восстановления Actve Directory вам нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите msconfig и на вкладе Boot выберите Safe Boot -> Active Directory repair.
Active Directory repair mode» srcset=»https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode-300×196.png 300w» sizes=»(max-width: 575px) 100vw, 575px»/>
Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.
В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).
Заметем выберите диск, на котором находится резервная копия старого контроллера AD, или укажите UNC путь к ней.
wbadmin get versions -backupTarget:D:
Выберите дату, на которую нужно восстановить резервную копию.
Укажите, что вы восстанавливаете состояние System State.
Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files).
Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.
Согласитесь с еще одним предупреждением:
После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет изменено на имя DC из бэкапа).
Загрузите сервер в обычном режиме (отключите загрузку в DSRM режиме)
Авторизуйтесь на сервере под учетной записью с правами администратора домена.
При первом запуске консоли ADUC я получил ошибку:
При этом на сервере нет сетевых папок SYSVOL and NETLOGON. Чтобы исправить ошибку:
- Запустите regedit.exe;
- Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
- Измените значение параметра SysvolReady с 0 на 1;
- Потом перезапустите службу NetLogon: net stop netlogon & net start netlogon
Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.
Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.
Если у вас остался единственный DC, проверьте что он является хозяином всех 5 FSMO ролей и выполните их захват, если нужно.
Восстановление отдельных объектов в AD
Если вам нужно восстановить отдельные объекты в AD, воспользуйтесь корзиной Active Directory. Если время захоронения уже просрочено, или ActiveDirectory RecycleBin не включена, вы можете восстановить отдельные объекты AD в режиме авторитаивного восстановления.
Вкратце процедура выглядит следующим образом:
- Загрузите DC в DSRM режиме;
- Выведите список доступных резервных копий: wbadmin get versions
- Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:[your_version]
- Подтвердите восстановление DC (в не полномочном режиме);
- После перезагрузки запустите: ntdsutil
- activate instance ntds
- authoritative restore
Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:
restore subtree ″OU=Users,DC=winitpro,DC=ru″
Или один объект:
restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”
Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.
Выйдите из ntdsutil: quit
Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.
Настройка аварийного восстановления для Active Directory и DNS Set up disaster recovery for Active Directory and DNS
Правильная работа корпоративных приложений, таких как SharePoint, Dynamics AX и SAP, зависит от Active Directory и инфраструктуры DNS. Enterprise applications such as SharePoint, Dynamics AX, and SAP depend on Active Directory and a DNS infrastructure to function correctly. При настройке аварийного восстановления для приложений часто требуется восстановить Active Directory и службу доменных имен (DNS) перед восстановлением других компонентов приложения, чтобы обеспечить правильную работу приложения. When you set up disaster recovery for applications, you often need to recover Active Directory and Domain Name System (DNS) before you recover other application components, to ensure correct application functionality.
С помощью Site Recovery можно создать план аварийного восстановления для Active Directory. You can use Site Recovery to create a disaster recovery plan for Active Directory. В случае нарушения работы вы можете инициировать отработку отказа. When a disruption occurs, you can initiate a failover. Active Directory можно настроить и подготовить к работе за несколько минут. You can have Active Directory up and running in a few minutes. Если вы развернули Active Directory для нескольких приложений на основном сайте, например для SharePoint и SAP, может потребоваться выполнить отработку отказа для всего сайта. If you have deployed Active Directory for multiple applications in your primary site, for example, for SharePoint and SAP, you might want to fail over the complete site. Сначала можно выполнить отработку отказа Active Directory с помощью Site Recovery. You can first fail over Active Directory using Site Recovery. Затем выполните отработку отказа других приложений с помощью планов восстановления для конкретных приложений. Then, fail over the other applications, using application-specific recovery plans.
Из этой статьи вы узнаете, как создать решение аварийного восстановления для Active Directory. This article explains how to create a disaster recovery solution for Active Directory. Здесь указаны предварительные требования и инструкции по отработке отказа. It includes prerequisites, and failover instructions. Перед началом работы необходимо ознакомиться с Active Directory и Site Recovery. You should be familiar with Active Directory and Site Recovery before you begin.
Предварительные требования Prerequisites
- Если выполняется репликация в Azure, подготовьте ресурсы Azure, включая подписку, виртуальную сеть Azure, учетную запись хранения и хранилище служб восстановления. If you’re replicating to Azure, prepare Azure resources, including a subscription, an Azure Virtual Network, a storage account, and a Recovery Services vault.
- Ознакомьтесь с требованиями поддержки для всех компонентов. Review the support requirements for all components.
Репликация контроллера домена Replicate the domain controller
- Необходимо настроить репликацию Site Recovery по крайней мере на одной виртуальной машине, где размещен контроллер домена или DNS. You must set up Site Recovery replication, on at least one virtual machine (VM) that hosts a domain controller or DNS.
- Если в вашей среде несколько контроллеров домена, на целевом сайте также необходимо настроить дополнительный контроллер домена. If you have multiple domain controllers in your environment, you also must set up an additional domain controller on the target site. Он может находиться в Azure или в дополнительном локальном центре обработки данных. The additional domain controller can be in Azure, or in a secondary on-premises datacenter.
- При наличии небольшого количества приложений и одного контроллера домена может потребоваться выполнить отработку отказа всего сайта. If you have only a few applications and one domain controller, you might want to fail over the entire site together. В этом случае рекомендуется использовать Site Recovery для репликации контроллера домена на целевой сайт в Azure или во вторичном локальном центре обработки данных. In this case, we recommend using Site Recovery to replicate the domain controller to the target site, either in Azure or in a secondary on-premises datacenter. Этот же реплицированный контроллер домена или виртуальную машину с DNS можно использовать для тестовой отработки отказа. You can use the same replicated domain controller or DNS virtual machine for test failover.
- Если в вашей среде много приложений и несколько контроллеров доменов и при этом вы планируете выполнять отработку отказа для нескольких приложений одновременно, мы рекомендуем в дополнение к репликации виртуальной машины с контроллером домена с помощью Site Recovery также настроить дополнительный контроллер домена на целевом сайте (сайте Azure или в дополнительном локальном центре обработки данных). If you have many applications and more than one domain controller in your environment, or if you plan to fail over a few applications at a time, in addition to replicating the domain controller virtual machine with Site Recovery, we recommend that you set up an additional domain controller on the target site (either in Azure or in a secondary on-premises datacenter). Для тестовой отработки отказаможно использовать контроллер домена, реплицированный с помощью Site Recovery. For test failover, you can use a domain controller that’s replicated by Site Recovery. Для отработки отказа можно использовать дополнительный контроллер домена на целевом сайте. For failover, you can use the additional domain controller on the target site.
Включение защиты с помощью Site Recovery Enable protection with Site Recovery
Site Recovery можно использовать для защиты виртуальной машины, на которой размещен контроллер домена или DNS. You can use Site Recovery to protect the virtual machine that hosts the domain controller or DNS.
Защита виртуальной машины Protect the VM
Контроллер домена, реплицированный с помощью Site Recovery, используется для тестовой отработки отказа. The domain controller that is replicated by using Site Recovery is used for test failover. Убедитесь, что он соответствует следующим требованиям. Ensure that it meets the following requirements:
- Контроллер домена должен быть сервером глобального каталога. The domain controller is a global catalog server.
- Контроллер домена должен быть владельцем роли FSMO для ролей, которые необходимы во время тестовой отработки отказа. The domain controller should be the Flexible Single Master Operations (FSMO) role owner for roles that are needed during a test failover. В противном случае эти роли должны быть заняты после отработки отказа. Otherwise, these roles will need to be seized after the failover.
Настройка параметров сети виртуальной машины Configure VM network settings
Для виртуальной машины, на которой размещен контроллер домена или DNS, в Site Recovery настройте параметры сети в разделе параметров Вычисления и сеть реплицированной виртуальной машины. For the virtual machine that hosts the domain controller or DNS, in Site Recovery, configure network settings under the Compute and Network settings of the replicated virtual machine. Это гарантирует, что виртуальная машина будет подключена к правильной сети после отработки отказа. This ensures that the virtual machine is attached to the correct network after failover.
Защита Active Directory Protect Active Directory
Защита «сайт-сайт» Site-to-site protection
Создайте контроллер домена на дополнительном сайте. Create a domain controller on the secondary site. При повышении уровня сервера до роли контроллера домена укажите имя того же домена, который используется на первичном сайте. When you promote the server to a domain controller role, specify the name of the same domain that’s being used on the primary site. Чтобы настроить параметры объекта связывания сайтов, в который добавляются сайты, можно использовать оснастку Active Directory — сайты и службы. You can use the Active Directory Sites and Services snap-in to configure settings on the site link object to which the sites are added. Настраивая параметры связи между сайтами, можно указать время и периодичность репликации между двумя или несколькими сайтами. By configuring settings on a site link, you can control when replication occurs between two or more sites, and how often it occurs. Дополнительные сведения см. в разделе планирование репликации между сайтами. For more information, see Scheduling replication between sites.
Защита «сайт-Azure» Site-to-Azure protection
Сначала создайте контроллер домена в виртуальной сети Azure. First, create a domain controller in an Azure virtual network. При повышении роли сервера до роли контроллера домена укажите имя домена, которое используется на основном сайте. When you promote the server to a domain controller role, specify the same domain name that’s used on the primary site.
Затем измените конфигурацию DNS-сервера для виртуальной сети так, чтобы использовался DNS-сервер в Azure. Then, reconfigure the DNS server for the virtual network to use the DNS server in Azure.
Защита «Azure — Azure» Azure-to-Azure protection
Сначала создайте контроллер домена в виртуальной сети Azure. First, create a domain controller in an Azure virtual network. При повышении роли сервера до роли контроллера домена укажите имя домена, которое используется на основном сайте. When you promote the server to a domain controller role, specify the same domain name that’s used on the primary site.
Затем измените конфигурацию DNS-сервера для виртуальной сети так, чтобы использовался DNS-сервер в Azure. Then, reconfigure the DNS server for the virtual network to use the DNS server in Azure.
Рекомендации по тестированию отработки отказа Test failover considerations
Чтобы избежать влияния на рабочие нагрузки, тестовая отработка отказа происходит в сети, изолированной от рабочей сети. To avoid impact on production workloads, the test failover occurs in a network that’s isolated from the production network.
Для работы большинства приложений требуется контроллер домена и DNS-сервер. Most applications require the presence of a domain controller or a DNS server. Таким образом, прежде чем выполнять отработку отказа для приложения, необходимо создать в изолированной сети контроллер домена, который будет использоваться при отработке отказа. Therefore, before the application fails over, you must create a domain controller in the isolated network to be used for test failover. Это проще всего сделать, реплицировав с помощью Site Recovery виртуальную машину с контроллером домена или DNS. The easiest way to do this is to use Site Recovery to replicate a virtual machine that hosts a domain controller or DNS. Запустите тестовую отработку отказа виртуальной машины с контроллером домена, прежде чем запускать тестовую отработку отказа плана восстановления для приложения. Then, run a test failover of the domain controller virtual machine before you run a test failover of the recovery plan for the application.
Site Recovery можно использовать для репликации виртуальной машины, на которой размещен контроллер домена или DNS. Use Site Recovery to replicate the virtual machine that hosts the domain controller or DNS.
Создайте изолированную сеть. Create an isolated network. Любая виртуальная сеть, созданная в Azure, по умолчанию изолируется от другой сети. Any virtual network that you create in Azure is isolated from other networks by default. Рекомендуем использовать для этой сети такой же диапазон IP-адресов, как у вашей рабочей сети. We recommend that you use the same IP address range for this network that you use in your production network. Не включайте для этой сети подключение между сайтами. Don’t enable site-to-site connectivity on this network.
Укажите IP-адрес DNS в изолированной сети. Provide a DNS IP address in the isolated network. Используйте IP-адрес, который должна получить виртуальная машина DNS. Use the IP address that you expect the DNS virtual machine to get. При репликации в Azure укажите IP-адрес для виртуальной машины, используемой при отработке отказа. If you’re replicating to Azure, provide the IP address for the virtual machine that’s used on failover. Чтобы ввести IP-адрес, в реплицированной виртуальной машине в разделе параметров Вычисления и сеть выберите параметры Целевой IP-адрес. To enter the IP address, in the replicated virtual machine, in the Compute and Network settings, select the Target IP settings.
Служба Site Recovery попытается создать тестовые виртуальные машины в подсети с таким же именем, используя тот же IP-адрес, который был указан в разделе параметров Вычисления и сеть виртуальной машины. Site Recovery attempts to create test virtual machines in a subnet of the same name and by using the same IP address that’s provided in the Compute and Network settings of the virtual machine. Если подсеть с таким же именем недоступна в виртуальной сети Azure, предоставленной для тестовой отработки отказа, тестовая виртуальная машина создается в первой по алфавиту подсети. If a subnet of the same name isn’t available in the Azure virtual network that’s provided for test failover, the test virtual machine is created in the alphabetically first subnet.
Если целевой IP-адрес является частью выбранной подсети, Site Recovery попытается создать виртуальную машину для тестовой обработки отказа с его использованием. If the target IP address is part of the selected subnet, Site Recovery tries to create the test failover virtual machine by using the target IP address. Если целевой IP-адрес не является частью выбранной подсети, виртуальная машина для тестовой отработки отказа создается с использованием следующего доступного IP-адреса в выбранной подсети. If the target IP isn’t part of the selected subnet, the test failover virtual machine is created by using the next available IP in the selected subnet.
Тестовая отработка отказа на дополнительный сайт Test failover to a secondary site
- Если выполняется репликация на другой локальный сайт и вы используете DHCP, настройте DNS и DHCP для тестовой отработки отказа. If you’re replicating to another on-premises site and you use DHCP, set up DNS and DHCP for test failover.
- Выполняйте тестовую отработку отказа на виртуальной машине с контроллером домена в изолированной сети. Do a test failover of the domain controller virtual machine that runs in the isolated network. Для выполнения тестовой отработки отказа используйте последнюю точку восстановления виртуальной машины контроллера домена, согласованную с приложениями. Use the latest available application consistent recovery point of the domain controller virtual machine to do the test failover.
- Запустите тестовую отработку отказа для плана восстановления, который содержит виртуальные машины приложения. Run a test failover for the recovery plan that contains virtual machines that the application runs on.
- После завершения тестирования очистите тестовую отработку отказа на виртуальной машине с контроллером домена. When testing is complete, clean up the test failover on the domain controller virtual machine. Этот шаг удаляет контроллер домена, который был создан для тестовой отработки отказа. This step deletes the domain controller that was created for test failover.
Удаление ссылок на другие контроллеры домена Remove references to other domain controllers
При запуске тестовой отработки отказа не нужно переносить все контроллеры домена в тестовую сеть. When you initiate a test failover, don’t include all the domain controllers in the test network. Чтобы удалить ссылки на другие контроллеры домена, которые существуют в рабочей среде, необходимо занять роли FSMO Active Directory и очистить метаданные для отсутствующих контроллеров домена. To remove references to other domain controllers that exist in your production environment, you might need to seize FSMO Active Directory roles and do metadata cleanup for missing domain controllers.
Вопросы, связанные с мерами по обеспечению безопасности виртуализации Issues caused by virtualization safeguards
Некоторые конфигурации, описанные в следующем разделе, не являются стандартными для контроллера домена. Some of the configurations described in this section are not standard or default domain controller configurations. Если вы не хотите вносить эти изменения в рабочий контроллер домена, вы можете создать отдельный контроллер домена для тестовой отработки отказа Site Recovery. If you don’t want to make these changes to a production domain controller, you can create a domain controller that’s dedicated for Site Recovery to use for test failover. Внесите эти изменения только в этот контроллер домена. Make these changes only to that domain controller.
Начиная с Windows Server 2012 в Active Directory Domain Services (AD DS) предусмотрены дополнительные меры безопасности. Beginning with Windows Server 2012, additional safeguards are built into Active Directory Domain Services (AD DS). Эти меры безопасности помогают защитить виртуализированные контроллеры домена от отката к последовательному номеру обновления (USN), если базовая платформа гипервизора поддерживает VM-GenerationID. These safeguards help protect virtualized domain controllers against update sequence number (USN) rollbacks if the underlying hypervisor platform supports VM-GenerationID. Azure поддерживает VM-GenerationID. Azure supports VM-GenerationID. А это значит, что контроллеры доменов, которые работают под управлением Windows Server 2012 или более поздних версий на виртуальных машинах Azure, будут защищены дополнительными мерами безопасности. Because of this, domain controllers that run Windows Server 2012 or later on Azure virtual machines have these additional safeguards.
Когда выполняется сброс VM-GenerationID, значение InvocationID базы данных AD DS также сбрасывается. When VM-GenerationID is reset, the InvocationID value of the AD DS database is also reset. Кроме того, пул относительных ИДЕНТИФИКАТОРов (RID) удаляется, а SYSVOL папка помечается как неполномочное. In addition, the relative ID (RID) pool is discarded, and SYSVOL folder is marked as non-authoritative. Дополнительные сведения см. в статьях Введение в виртуализацию домен Active Directory Services и безопасное виртуализация распределенная ФАЙЛОВАЯ система Replication (DFSR). For more information, see Introduction to Active Directory Domain Services virtualization and Safely virtualizing Distributed File System Replication (DFSR).
Отработка отказа в Azure может привести к сбросу VM-GenerationID. Failing over to Azure might cause VM-GenerationID to reset. Сброс VM-GenerationID запускает дополнительные меры безопасности при запуске виртуальной машины с контроллером домена в Azure. Resetting VM-GenerationID triggers additional safeguards when the domain controller virtual machine starts in Azure. Это может привести к значительной задержке при входе на виртуальную машину контроллера домена. This might result in a significant delay in being able to sign in to the domain controller virtual machine.
Так как этот контроллер домена будет использоваться только для тестовой отработки отказа, меры безопасности виртуализации не обязательны. Because this domain controller is used only in a test failover, virtualization safeguards aren’t necessary. Чтобы гарантировать, что значение VM-GenerationID для виртуальной машины контроллера домена не изменится, можно изменить значение следующего DWORD на 4 на локальном контроллере домена: To ensure that the VM-GenerationID value for the domain controller virtual machine doesn’t change, you can change the value of following DWORD to 4 in the on-premises domain controller:
Признаки применения мер по обеспечению безопасности виртуализации Symptoms of virtualization safeguards
Если меры безопасности виртуализации активированы после тестовой отработки отказа, вы увидите один или несколько следующих признаков. If virtualization safeguards are triggered after a test failover, you might see one or more of following symptoms:
Значение GenerationID изменяется: The GenerationID value changes:
Значение invocationID изменяется: The InvocationID value changes:
SYSVOL Папка и NETLOGON Общие папки недоступны. SYSVOL folder and NETLOGON shares aren’t available.
Базы данных DFSR удалены. DFSR databases are deleted.
Устранение неполадок контроллера домена при тестовой отработке отказа Troubleshoot domain controller issues during test failover
Некоторые конфигурации, описанные в следующем разделе, не являются стандартными для контроллера домена. Some of the configurations described in this section aren’t standard or default domain controller configurations. Если вы не хотите вносить эти изменения в рабочий контроллер домена, вы можете создать отдельный контроллер домена для тестовой отработки отказа Site Recovery. If you don’t want to make these changes to a production domain controller, you can create a domain controller that’s dedicated for Site Recovery test failover. Внесите эти изменения только в этот выделенный контроллер домена. Make the changes only to that dedicated domain controller.
В командной строке выполните следующую команду, чтобы проверить SYSVOL NETLOGON , являются ли общие папки и папки общими: At the command prompt, run the following command to check whether SYSVOL folder and NETLOGON folder are shared:
В командной строке выполните следующую команду, чтобы убедиться, что контроллер домена работает правильно: At the command prompt, run the following command to ensure that the domain controller is functioning properly:
dcdiag /v > dcdiag.txt
В журнале выходных данных найдите следующий текст. In the output log, look for the following text. Текст подтверждает, что контроллер домена работает правильно. The text confirms that the domain controller is functioning correctly.
- passed test Connectivity
- passed test Advertising
- passed test MachineAccount
Если эти условия выполняются, скорее всего контроллер домена будет работать правильно. If the preceding conditions are satisfied, it’s likely that the domain controller is functioning correctly. Если нет, сделайте следующее: If it’s not, complete the following steps:
Выполните заслуживающее доверия восстановление контроллера домена. Do an authoritative restore of the domain controller. Примите во внимание указанные ниже сведения. Keep the following information in mind:
Хотя мы не советуем использовать репликацию с помощью службы репликации файлов (FRS), если вы используете репликацию FRS, выполните действия для полномочного восстановления. Although we don’t recommend replication using the File Replication Service (FRS), if you use FRS replication, follow the steps for an authoritative restore. Процесс описан в статье об использовании раздела реестра BurFlags для повторной инициализации службы репликации файлов. The process is described in Using the BurFlags registry key to reinitialize File Replication Service.
Дополнительные сведения о BurFlags см. в этой записи блога. For more information about BurFlags, see the blog post D2 and D4: What is it for?.
Если используется репликация DFSR, выполните действия для заслуживающего доверия восстановления. If you use DFSR replication, complete the steps for an authoritative restore. Процесс описан в разделе Принудительная и неофициальная синхронизация для реплицированной папки SYSVOL (например, D4/D2 для FRS). The process is described in Force an authoritative and non-authoritative sync for DFSR-replicated SYSVOL folder (like «D4/D2» for FRS).
Вы можете также использовать функции PowerShell. You can also use the PowerShell functions. Дополнительные сведения см. в статье DFSR-SYSVOL Authoritative / Non-Authoritative Restore Powershell Functions (Функции PowerShell заслуживающие и не заслуживающего доверия восстановления DFSR SYSVOL). For more information, see DFSR-SYSVOL authoritative/non-authoritative restore PowerShell functions.
Пропустите требование начальной синхронизации, задав следующему разделу реестра значение 0 на локальном контроллере домена. Bypass the initial sync requirement by setting the following registry key to 0 in the on-premises domain controller. Если объект DWORD не существует, его можно создать в узле Параметры . If the DWORD doesn’t exist, you can create it under the Parameters node.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations
Дополнительные сведения см. в статье Troubleshoot DNS Event ID 4013: The DNS server was unable to load AD integrated DNS zones (Устранение события DNS с идентификатором 4013: DNS-серверу не удалось загрузить зоны DNS, интегрированные с AD). For more information, see Troubleshoot DNS Event ID 4013: The DNS server was unable to load AD integrated DNS zones.
Отключите требование, чтобы сервер глобального каталога был доступен для проверки входа пользователя. Disable the requirement that a global catalog server be available to validate the user login. Для этого в локальном контроллере домена присвойте следующему разделу реестра значение 1. To do this, in the on-premises domain controller, set the following registry key to 1. Если объект DWORD не существует, его можно создать в узле LSA . If the DWORD doesn’t exist, you can create it under the Lsa node.
Контроллер домена и DNS на разных компьютерах DNS and domain controller on different machines
Если вы запускаете контроллер домена и DNS на одной виртуальной машине, вы можете пропустить эту процедуру. If you’re running the domain controller and DNs on the same VM, you can skip this procedure.
Если DNS находится не на той же виртуальной машине, что и контроллер домена, необходимо создать виртуальную машину DNS для тестовой отработки отказа. If DNS isn’t on the same VM as the domain controller, you need to create a DNS VM for the test failover. Вы можете использовать новый DNS-сервер и создать все необходимые зоны. You can use a fresh DNS server, and create all the required zones. Например, если домен Active Directory — contoso.com , можно создать зону DNS с именем contoso.com . For example, if your Active Directory domain is contoso.com , you can create a DNS zone with the name contoso.com . Записи DNS, соответствующие Active Directory, необходимо обновить следующим образом: The entries that correspond to Active Directory must be updated in DNS as follows:
До включения любой другой виртуальной машины в план восстановления убедитесь, что настроены указанные ниже параметры: Ensure that these settings are in place before any other virtual machine in the recovery plan starts:
- Необходимо назвать зону именем корня леса. The zone must be named after the forest root name.
- Зона должна предусматривать файловую поддержку. The zone must be file-backed.
- Для зоны должна быть включена возможность установки безопасных и небезопасных обновлений. The zone must be enabled for secure and nonsecure updates.
- Сопоставитель виртуальной машины, на которой размещен контроллер домена, должен указывать на IP-адрес виртуальной машины DNS. The resolver of the virtual machine that hosts the domain controller should point to the IP address of the DNS virtual machine.
Выполните в виртуальной машине с контроллером домена следующую команду: Run the following command on the VM that hosts the domain controller:
Выполните следующие команды, чтобы добавить зону на DNS-сервер, разрешите небезопасные обновления и добавьте запись для зоны в DNS. Run the following commands to add a zone on the DNS server, allow nonsecure updates, and add an entry for the zone to DNS:
Дальнейшие действия Next steps
Дополнительные сведения о защите рабочих нагрузок предприятия с помощью Azure Site Recovery. Learn more about protecting enterprise workloads with Azure Site Recovery.