Миграция домена с windows server 2008 на windows server 2008 r2

Введение

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

Тем не менее, целью данной статьи было объединить типовые действия, возникающие при миграции, поэтому приступим. Статья будет представлять собой пошаговый мануал, с наиболее распространенным случаем миграции с 2003 на 2008 R2 и с необходимыми отступлениями для других вариантов. Собственно шаги:

Исходные данные и техзадание.
Подготовительные работы.
Обновление схемы леса и домена.
Передача ролей FSMO.
Перенос глобального каталога.
Перенастройка интерфейсов, DNS и другие послеустановочные задачи.

Исходные данные и техзадание

Иходная ситуация — существует домен, testcompany.local. Для упрощения в нем будет один контроллер домена под Windows Server 2003, с именем dc01. DNS-сервер также на нем, основная зона интегрирована в Active Directory.

Сетевые настройки контроллера:

IP-адрес — 192.168.1.11
Маска — 255.255.255.0
Шлюз — 192.168.1.1
DNS-сервер — 192.168.1.11

Задача — установить контроллер домена на другом сервере, причем работающем под Windows Server 2008 R2, старый контроллер понизить до рядового сервера (а затем возможно, удалить вообще), а все функции старого контроллера передать новому.

Подготовительные работы

В качестве подготовительных работ следует запустить команды netdiag (эта команда существует только в 2003 Server, Support Tools) и dcdiag, убедиться в отсутствии ошибок, а при их наличии исправить эти ошибки.

В первую очередь определяем держателя FSMO-ролей в домене, командой:

netdom query fsmo

Утилита netdom.exe в состав Windows Server 2003 по умолчанию не входит, поэтому нужно установить Support Tools (http://support.microsoft.com/kb/926027). В рассматриваемом случае от нее смысла никакого нет, так как контроллер домена всего один и роли FSMO все равно все на нем. Тем же, у кого контроллеров домена больше одного, это будет полезно, чтобы знать, какие именно роли и откуда переносить. Результат команды будет примерно таким:

Далее, устанавливаем операционную систему Windows Server 2008 R2 на новый сервер, даем имя скажем dc02, задаем сетевые настройки:

IP-адрес — 192.168.1.12
Маска — 255.255.255.0
Шлюз — 192.168.1.1
DNS-сервер — 192.168.1.11

и вводим его в существующий домен, testcompany.local в нашем случае.

Обновление схемы леса и домена

Следующий этап — обновление схемы леса и домена до Windows Server 2008 R2, что мы будем делать с помощью утилиты adprep. Вставляем установочный диск с Windows Server 2008 R2 в сервер dc01. На диске нас интересует папка X:\support\adprep (X: — буква диска DVD-ROM). Если windows Server 2003 у вас 32-х битная, следует запускать запускать adprep32.exe, в случае 64-х битной — adprep.exe.

Для выполнения команды adprep /forestprep никаких требований к функциональному режиму леса нет. Для выполнения команды adprep /domainprep требуется, чтобы в домене использовался функциональный уровень домена не ниже Windows 2000 native.

Вводим команду:

X:\support\adprep>adprep32.exe /forestprep

После предупреждения о том, что все контроллеры домена Windows 2000 должны быть минимум с SP4 вводим С и нажимаем Enter:

Команда отрабатывает довольно долго, несколько минут и должна завершиться следующей фразой:

Adprep successfully updated the forest-wide information.

После этого вводим команду:

X:\support\adprep>adprep32.exe /domainprep /gpprep

Которая отработает не в пример быстрее:

Также стоит выполнить команду adprep /rodcprep. Даже если вы и не собираетесь использовать в вашей сети контроллеры домена только для чтения (Read Only Domain Controller — RODC), эта команда как минимум уберет ненужные сообщения об ошибках в журнале событий.

После завершения действия команд по обновлению схемы можно приступать к повышению роли нового сервера до контроллера домена.
На сервере dc02 заходим в Server Manager, добавляем роль Active Directory Domain Services. После установки роли, зайдя в Server Manager > Roles > Active Directory Domain Services, мы увидим желтую подсказку «Run the Active Directory Domain Services Installation Wizard (dcpromo.exe)». Ее и запускаем. Либо можно в командной строке набрать dcpromo, что будет равноценно вышеприведенному действию.

Так как освещение процесса установки контроллера домена в эту статью не входит, остановлюсь лишь на некоторых ключевых моментах. На шаге Additional Domain Controller Options поставьте обе галки, DNS Server и Global catalog.

Если галку Global Catalog и DNS Server не поставить, придется их переносить отдельно. А при миграции с 2003 на 2003 это придется делать в любом случае, так как в Windows 2003 такой возможности нет. О переносе глобального каталога и DNS-сервера будет немного ниже.

Завершаем установку контроллера домена, перезагружаем сервер. Теперь у нас есть два контроллера домена, работающих одновременно.

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

Передачу ролей FSMO можно производить как через графический интерфейс, так и с помощью утилиты ntdsutil.exe. В этой статье будет описан способ с использованием графического интерфейса, как более наглядный, кого интересует другой способ, он по этой ссылке: http://support.microsoft.com/kb/255504. Передача ролей FSMO будет состоять из следующих шагов:

Передача роли Schema Master.
Передача роли Domain Naming Master.
Передача ролей RID Master, PDC Emulator и Infrastructure Master.

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

Заходим на сервер dc02, на тот, на который будем передавать роли. Для того, чтобы получить доступ к оснастке Active Directory Schema, сначала необходимо зарегистрировать библиотеку schmmgmt.dll. Это делается с помощью команды:

regsvr32 schmmgmt.dll

Далее, Start > Run > вводим mmc > Enter. В окне оснастки находим и добавляем компонент Active Directory Schema.

В дереве оснастки нужно щелкнуть правой кнопкой мыши элемент Active Directory Schema и выбрать пункт Change Domain Controller. Там меняем контроллер на dc02.
Далее опять нажимаем правой кнопкой мыши элемент Active Directory Schema и выбираем пункт Operations Master. Появляется вот такое окно:

Нажимаем Change > Yes > OK и закрываем все эти окна.

Передача роли Domain Naming Master

Открываем оснастку Active Directory Domains and Trusts, щелкаем правой кнопкой мыши элемент Active Directory Domains and Trusts и выбираем команду Change Active Directory Domain Controller. Это действие необходимо, если работа ведется не с контроллера домена, которому передается роль. Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено. В открывшемся окне выбираем контроллер домена, которому присваивается роль (dc02 в нашем случае), в списке и нажимаем кнопку ОК.
В оснастке щелкаем правой кнопкой мыши элемент Active Directory Domains and Trusts и выбираем пункт Operations Master. В появившемся окне нажимаем кнопку Change.

Чтобы подтвердить передачу роли, нажимаем кнопку ОК, а затем — Close.

Передача ролей RID Master, PDC Emulator и Infrastructure Master

Открываем оснастку Active Directory Users and Computers. Щелкаем правой кнопкой мыши элемент Active Directory Users and Computers и выбираем команду Change Domain Controller. Пропустите его, если подключение к контроллеру домена, чья роль передается, уже установлено. В открывшемся окне выбираем контроллер домена, которому присваивается роль (dc02 в нашем случае), в списке и нажимаем кнопку ОК.

В оснастке щелкаем правой кнопкой мыши элемент Active Directory Users and Computers, выбираем пункт All Tasks, а затем Operations Master.

Выбираем вкладку, соответствующую передаваемой роли (RID, PDC или Infrastructure Master), и нажимаем кнопку Change.
Чтобы подтвердить передачу роли, нажимаем кнопку ОК, а затем — Close.

Перенос глобального каталога

Если мы делаем миграцию не на 2008, а на 2003, в котором при добавлении добавочного контроллера домена глобальный каталог не ставиться, либо вы не поставили галку Global Catalog в шаге 2, тогда нужно назначить роль глобального каталога новому контроллеру домена вручную. Для этого, заходим в оснастку Active Directory Sites and Services, ракрываем Sites > сайт Default-First-Site-Name > Servers > DC02 > щелкаем правой кнопкой мыши по NTDS Settings > Properties. В открывшемся окне ставим галку Global Catalog > OK.

Global Catalog» title=»Active Directory Sites and Services > Global Catalog» class=»aligncenter size-full wp-image-812″ width=»735″ height=»598″>

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

Event Type: Information
Event Source: NTDS General
Event Category: (18)
Event ID: 1110
Date: 12.07.2011
Time: 22:49:31
User: TESTCOMPANY\Administrator
Computer: dc02.testcompany.local
Description:
Promotion of this domain controller to a global catalog will be delayed for the following interval.

Interval (minutes):
5

This delay is necessary so that the required directory partitions can be prepared before the global catalog is advertised. In the registry, you can specify the number of seconds that the directory system agent will wait before promoting the local domain controller to a global catalog. For more information about the Global Catalog Delay Advertisement registry value, see the Resource Kit Distributed Systems Guide.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Ждем пять минут и дожидаемся события 1119 о том, что этот контроллер стал глобальным каталогом.

Event Type: Information
Event Source: NTDS General
Event Category: (18)
Event ID: 1119
Date: 12.07.2011
Time: 22:54:31
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: dc02.testcompany.local
Description:
This domain controller is now a global catalog.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Перенастройка интерфейсов, 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.

Использованные источники:

http://support.microsoft.com/kb/324801/
http://technet.microsoft.com/en-us/library/cc731728(WS.10).aspx
http://technet.microsoft.com/ru-ru/library/upgrade-domain-controllers-to-windows-server-2008-r2(WS.10).aspx#BKMK_FL

This entry was posted on 27.07.2011 в 21:32:02 and is filed under Microsoft.
Отмечено: Active Directory, DNS. You can follow any responses to this entry through the RSS 2.0 feed.

You can leave a response, или trackback from your own site.

Источник

Windows Server 2008 and Windows Server 2008 R2 Operating system reached the end of their support cycle on the 14th of January 2020. Because of this many organizations wanted to migrate away from these legacy operating systems. End-of-life operating systems have a direct impact on various industry compliances, IT audits, Penetration tests, and so on. Even business does not have a business requirement to upgrade, end of life operating system leaves no choice but to upgrade.

In the past, I did a similar blog post covering migration AD from Windows Server 2008 to Windows Server 2016. Microsoft released Windows Server 2022 recently (Aug 2021) and I thought it good to demonstrate how we can migrate AD from 2008 R2 to the newest. AD migrations from other operating systems (newer than Windows Server 2008R2) also follow a similar process.

What is New in Active Directory?

AD DS’ improvements are bond to its forest and domain functional levels. Upgrading the operating system or adding domain controllers that run Windows Server 2022 to an existing AD infrastructure isn’t going to upgrade the forest and domain functional levels automatically. We need to upgrade it manually once older domain controllers are decommissioned. There was a big difference with Windows Server 2019 when it comes to forest and domain functional levels. With each and every Windows Server release up to Windows Server 2016, had a new forest and domain functional level. But with Windows Server 2019 there were NO new forest or domain functional levels. It is the same with Windows Server 2022. The maximum forest and domain functional level we can choose still is Windows Server 2016.

Active Directory Domain Services was first introduced to the world with Windows Server 2000. For more than 21 years, AD DS helps organizations to manage digital identities. However, the modern access management requirements are complicated. Businesses are using more and more cloud services now. The majority of the workforce is still working from home and accessing sensitive corporate data via unsecured networks. Most software vendors are moving into SaaS model. Cybercrimes are skyrocketing and identity protection is at stake. To address these requirements, we need to go beyond legacy access management. Azure Active Directory is a cloud-based, managed, Identity as a Service (IDaaS) provider, which can provide world-class security, strong authentication, and seamless collaboration. So, it does make sense why there are no significant changes to on-premises AD anymore.

One of the key themes of Windows Server 2022 is «security». Advanced multi-layer security in Windows Server 2022 provides comprehensive protection against modern threats. This also adds an additional layer of security to roles run on Windows Server 2022 including Active Directory. For more details about these security features please refer to https://docs.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-2022

Active Directory Migration Check List

Migrating FSMO roles to a new server and upgrading forest and domain functional levels doesn’t take more than few minutes but when it comes to migration there are few other things we need to consider. Therefore, I have summarized the AD DS Migration process with the following checklist.

Evaluate the business requirements for Active Directory migration.
Perform an audit on the existing Active Directory infrastructure to verify its health.
Create a detailed implementation plan.
Prepare the physical/virtual resources for the domain controller.
Install Windows Server 2022 Standard/Datacenter.
Patch the servers with the latest Windows updates.
Assign a dedicated IP address to the domain controller.
Install the AD DS role.
Migrate the application and server roles from the existing domain controllers.
Migrate the FSMO roles to the new domain controllers.
Add new domain controllers to the existing monitoring system.
Add new domain controllers to the existing DR solution.
Decommission the old domain controllers (all).
Raise the domain and forest functional levels.
Perform ongoing maintenance (Group Policy review, new-feature implementations, identifying and fixing Active Directory infrastructure issues, and more)

Most Common Questions About Active Directory Migrations

Below I listed some of the most common questions I get about AD migration,

Can I keep the same IP address for the PDC? Yes, you can. Active Directory fully supports IP address changes. Once FSMO role migration is completed, you can swap the IP addresses of Domain Controllers.
Can I downgrade forest/domain functional levels? If you required you can do so but this is not a recommended approach. From Windows Server 2008 R2, we can downgrade forest/domain functional levels.
Do I need to migrate the DNS role? No, it is part of the AD. When you add a new domain controller, you can make it as a DNS server too.
Do I need to change SYSVOL replication from FRS to DFS? If your domain is built based on Windows server 2008 or Windows Server 2008 R2, you are already using DFS for SYSVOL replication. If you originally migrated from Windows server 2003, it’s more likely you are still using FRS. In that case, before migration, you need to change the SYSVOL replication method from FRS to DFS. I already have a blog post covering this topic https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distr…
Can I keep Windows 2008 R2 Domain Controllers and upgrade forest and domain functional level to Windows Server 2016? No, you can’t. Before forest and domain functional level upgrade, you need to decommission Windows server 2008 R2 domain controllers.

Design topology

As per the following diagram, the rebeladmin.net domain has two domain controllers:

As explained in the above illustration, The FSMO role holder DC08 is a Windows Server 2008 R2 Domain Controller. The domain and forest functional levels currently operate in Windows Server 2008 R2. A new domain controller with Windows Server 2022(DC22) will be introduced and will be the new FSMO role holder for the domain. Once the FSMO role migration is complete, the domain controller running Windows Server 2008 R2 will be decommissioned. After that, the forest and domain functional levels will be raised to Windows Server 2016.

When you introduce new domain controllers to existing infrastructure, it is recommended that you introduce the forest root level first and then go to the domain tree levels.

Prepare Windows Server 2022 Domain Controller

We need to do few things to prepare the new Windows Server 2022 before we migrate the FSMO roles.

After the OS installation and Patching process is completed, go ahead and join the new Windows Server 2022 to the existing domain.
In Windows Server 2022, it is recommended to use PowerShell 7 instead of native Windows PowerShell. Please go to https://aka.ms/PSWindows for more information. At the time this article was written, the latest version was 7.1.4.
In the previous section, I mentioned before migration we need to make sure SYSVOL is using DFSR instead of FRS. To verify that, Log in to the DC08 domain controller (Windows Server 2008 R2) as a Domain Admin. Then run dfsrmig /getmigrationstate command in Powershell. If the command returns state as «eliminated», it means DFSR is already in use for SYSVOL replication. If it is not, we must migrate SYSVOL replication to DFSR as Windows Server 2022 does not support FRS replication. FRS to DFSR migration steps are covered in a blog post I have written and it can access via https://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distr…

In this demo environment, the Domain controller already using DFSR.

Add Windows server 2022 Domain Controller

As the next part of the configuration, we need to make DC22 an Additional Domain Controller. To do that,

Log in to the server as an enterprise administrator.
Verify the static IP address allocation using ipconfig /all.
Launch the PowerShell 7 Console as an Administrator.
Before the configuration process, we need to install the AD DS Role in the given server. To do that we can use the following command.

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Configure the new server as an additional domain controller using,

Install-ADDSDomainController

-CreateDnsDelegation:$false

-InstallDns:$true

-DomainName «rebeladmin.net»

-SiteName «Default-First-Site-Name»

-ReplicationSourceDC «DC08.rebeladmin.net»

-DatabasePath «C:\Windows\NTDS»

-LogPath «C:\Windows\NTDS»

-SysvolPath «C:\Windows\SYSVOL»

-Force:$true

Note – There are no line breaks for the command and I have listed it as above to allow readers to focus on the parameters.

The following table explains the PowerShell arguments and what it will do.

Argument	Description
Install-ADDSDomainController	This cmdlet will install the domain controller in active directory infrastructure.
-CreateDnsDelegation	Using this parameter can define whether to create DNS delegation that reference active directory integrated DNS.
-InstallDns	Using this can specify whether DNS role need to install with active directory domain controller. For new forest, it is default requirement to set it to $true.
-DomainName	This parameter defines the FQDN for the active directory domain.
-SiteName	This Parameter can use to define the active directory site name. the default value is Default-First-Site-Name
-ReplicationSourceDC	Using this parameter can define the active directory replication source. By default, it will use any available domain controller. But if need we can be specific.
-DatabasePath	This parameter will use to define the folder path to store active directory database file (Ntds.dit)
-LogPath	Log path can use to specify the location to save domain log files.
-SysvolPath	This is to define the SYSVOL folder path. Default location for it will be C:\Windows
-Force	This parameter will force command to execute by ignoring the warning. It is typical for the system to pass the warning about best practices and recommendations.

Once execute the command it will ask for SafeModeAdministrator Password. Please use a complex password to proceed. This will be used for DSRM.

FSMO Role Migration

Now we have the new domain controller. The next step is to migrate FSMO roles from DC08 to the new domain controller.

After the server is rebooted, log back in as an administrator. and run the following commands to verify the current FSMO role holder.

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator

Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

As we can see all five FSMO roles currently belong to DC08 (Windows Server 2008 R2) Domain Controller.

Migrate all five FSMO roles to the new domain controller by running the following command in DC02 server:

Move-ADDirectoryServerOperationMasterRole -Identity DC22 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

In the preceding command, DC22 is the domain controller running Windows Server 2022.

Once we’re done, we can verify the new FSMO role holder using the following command:

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator

Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

As expected, Now FSMO roles are successfully moved to DC22 Domain Controller (Windows Server 2022)

Decommission Old Domain Controller

Before we upgrade forest and domain functional levels, first we need to decommission the old DC which is running with windows server 2008 R2.

To do that,

Log in to old DC as enterprise administrator
Go to Run | dcpromo
It will open up the dcpromo wizard. Click on Next to continue.

On the next page also click on Next as it is not the last domain controller.

In the Remove DNS Delegation page keep the default selection and click on Next.

Then the system will prompt for credentials. Provide Domain Admin credentials here.

On the next page, type a new password for the local administrator account.

In summary, page, click on Next to complete the process.

Once the process is completed, reboot the server.

If its Windows Server 2012 or above we can use Uninstall-ADDSDomainController -DemoteOperationMasterRole — RemoveApplicationPartition to uninstall AD DS

Raise Domain and Forest Functional level

After you demote your last domain controller running with windows server 2008 R2, we can raise Domain and Forest Functional level to windows server 2016 (Windows server 2022 is the same).

To upgrade the domain functional level, we can use the following PowerShell command in the Windows server 2022 domain controller.

Set-ADDomainMode -identity rebeladmin.net -DomainMode Windows2016Domain

To upgrade forest functional level, use the following command:

Set-ADForestMode -Identity rebeladmin.net -ForestMode Windows2016Forest

Now, we have completed the migration from AD DS 2008 R2 to AD DS 2022. The same steps apply when you’re migrating from Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019.

Verification

Although the migration is complete, we still need to verify whether it’s completed successfully. The following command will show the current domain functional level of the domain after the migration:

Get-ADDomain | fl Name,DomainMode

The following command will show the current forest functional level of the domain after migration:

Get-ADForest | fl Name,ForestMode

You can also use the following command to verify the forest & domain functional level updates:

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 2039 -or $_.eventID -eq 2040} | Format-List

The following screenshot shows events 2039 and 2040 in the Directory Service log, which verify the forest and domain functional level updates:

Event ID 1458 verifies the transfer of the FSMO roles:

Get-EventLog -LogName ‘Directory Service’ | where {$_.eventID -eq 1458} | Format-List

We can use the following command to verify the list of domain controllers and make sure that the old domain controller is gone:

Get-ADDomainController -Filter * | Format-Table Name, IPv4Address

This marks the end of this blog post. Hope now you know how to migrate Active Directory from Windows Server 2008 R2 to Windows Server 2022.

Источник

Вчера получил вопрос от одного из коллег по миграции домена на платформе Windows 2008R2. К сожалению (а скорей к радости) нам еще не довелось заниматься миграцией на платформе Windows 2008 (делали это на 2003 платформе с моим коллегой Александром, но не все прошло гладко, я писал об этом, где-то здесь), но вопрос не остался незамеченным, и я решил вдаться поглубже в тему. В процессе изучения мне понравился вот этот материал: http://sqrnotes.blogspot.com/2010/09/admt-32.html

с этого сайта я и добавлю себе в блог для информации:

Миграция домена ADMT 3.2

Небольшая инструкция по миграции домена с использованием Active Directory Migration Tool версии (ADMT) 3.2.
Статья ещё в разработке и постоянно пополняется.

Дано: 2 домена в разных лесах- source.local, target.local. Уровень работы обоих лесов 2003 native.
В целевом домене есть КД с win 2008R2. В исходном домене поднят Project Server, в целевом — SharePoint.
Необходимо: произвести миграцию пользователей из source.local в target.local. При этом должны сохраниться права доступа к ресурсам, права к записям SharePoint и ProjectServer. Так же по возможности должны быть перемещены профили (локальные) для прозрачности перехода в новый домен для пользователей. Так же должен использоваться DHCP сервер целевого домена.

Решение:
Миграция пользователей и групп будет осуществляться с помощью утилиты ADMT 3.2 — согласно рекомендациям компании Майкрасофт, в случае если в целевом домене используется КД на базе ОС win 2008 R2 следует использовать данную версию утилиты ADMT).
Из постановки задачи видно, что миграция должна осуществляться с использованием истории SID, для сохранения прав доступа.
Настройка доверительных отношений.

snap1

Прежде всего необходимо настроить доверие между доменами. Открываем оснастку «Active Directory Domains and trusts». Правой кнопкой по названию домена — свойства.
В открывшемся окошке переходим на вкладку «Trusts»
По нажатию кнопки внизу окна «New Trust» начинаем создание доверительных отношений между доменами.
В первом окошке указываем имя домена, с которым хотим наладить «дружбу». ….(требуется дописать)
Вносим учётную запись целевого домена, под которой будет осуществляться миграция, в группу администраторов домена источника.
Настройка DNS.
Так же необходимо настроить DNS сервера доменов. Один из вариантов — расположить вторичные зоны (secondary) перекрёстно друг к другу: зону source.local в DNS target.local, зону target.local — в DNS source.local. Мной использовался так же вариант — перекрёстных зон заглушек (stub zone).

Установка ADMT
Для начала выясним какая версия утилиты ADMT требуется, исходя из следующей таблицы:

Версия ADMT	Платформа для установки	Требования к домену-источнику (source domain)	Требования к целевому домену (target domain)	Поддерживаемые платформы для миграции
ADMT v3.0	Win Server 2003	Домен-источник может содержать КД под управлением Windows NT, Windows 2000 Server, или Windows Server 2003. Нет требования к уровню работы домена.	Минимальный уровень целевого домена Windows 2000 native.	Windows 2000 Professional, Windows XP, Windows NT 4, Windows 2000 Server, и Windows Server 2003.
ADMT v3.1	Windows Server 2008	Домен-источник может содержать КД под управлением Windows 2000 Server, Windows Server 2003, или Windows Server 2008. Нет требований к режиму работы домена, но ADMT v3.1 не может использоваться для миграции из Win NT4 домена.	Минимальный уровень работы целевого домена -Windows 2000 native. Если целевой домен содержит КД под управлением Windows Server 2008 R2, необходимо использовать ADMT v3.2. Для получения более полной информации ознакомьтесь с записью Базы Знаний Microsoft article 976659 .	Windows 2000 Professional, Windows XP, Windows Vista, Windows 2000 Server, Windows Server 2003, и Windows Server 2008.
ADMT v3.2	Windows Server 2008 R2	Минимальный уровень работы домена-источника-Windows Server 2003.	Минимальный уровень работы целевого домена-Windows Server 2003.	Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, и Windows Server 2008 R2.

Дальнейшее описание основывается на использовании версии 3.2, т.к. в целевом домене присутствует КД (контроллер домена) под управлением ОС Windows Server 2008R2.
Более подробно установка PES будет рассмотрена далее.
Active Directory Migration Tools версии 3.2, в отличи от предшествующих версий данной утилиты, требует установленного MSSQL сервера (может использовать издание Express). Подходят MSSQL 2005 SP3 и 2008 SP1, что примечательно с версией MSSQL 2008R2 утилита работать не может. Останавливаться подробно на развёртывании SQL сервера не буду, т.к. подходят параметры по-умолчанию. Дальнейшее описание основывается на использовании Win Server 2008R2 и MSSQL 2005 Std SP3 (просто был дистриб под рукой). Установка ADMT довольно простая, лишь пара вопросов мастера установки. Единственное что может вызвать сложность — указать базу для работы: не смотря на то что в текстовой подсказке указано «.\SQLExpress» по дефолту, у меня подключилось как просто «localhost», без указания инстанса.
Устанавливать утилиту необходимо в целевой домен.
Если в исходном домене присутствуют ПК, под управлением ОС Windows XP, Vista (до SP1), 2000, а КД целевого домена под управлением ОС Windows 2008 и выше, то необходимо на каждом контроллере целевого домена исправить (создать) ключ реестра:

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

ключ : AllowNT4Crypto

тип: REG_DWORD

значение: 1.

Включение политики аудита.
Так же необходимо настроить политику аудита в обоих доменах.
Для этого править групповую политику Default Domain Controller Policy: Computer Configuration-Polices-Windows settings-Security-Local-Audit
Устанавливаем политики «Audit account management» в Success и Failure, и «Audit directory service access» в Success.
Выключение фильтрации SID:
Выполняется в обоих доменах, во избежании возможных проблем при переносе истории SID.

Netdom trust TrustingDomainName /domain: TrustedDomainName /quarantine:No /userD:domainadministratorAcct/passwordD:domainadminpwd

Т.е. в нашем случае:

Netdom trust target.local /domain: source.local /quarantine:No /userD:administrator/passwordD:Pass

Более подробно о фильтрации SID можно посмотреть тут

Утилита Netdom входит штатно в windows 2008, для windows 2003 утилита входит в состав Windows 2003 Tools.

Установка PES
Для миграции паролей требуется утилита Password Export Server (PES) версии 3.1 (для всех версий утилиты ADMT). Скачать можно с офф.сайта Microsoft. Устанавливать в домене-источнике (source.local), используя при установке ключ, сгенерированный на компьютере целевого домена, на котором установлена утилита ADMT.
Генерируем ключ командой admt,

admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*

Получившийся файл переносим на КД в исходном домене. При установке PES указываем путь на этот файл, и пароль, если указывали его при генерации ключа. Появляется служба с ручным режимом запуска. Рекомендуется запускать её только при миграции.

Права и ограничения
Для миграции компьютеров и локальных профилей пользователей утилите ADMT необходимы права администратора в исходном домене. Проще всего распространить групповую политику на добавление группы Domain admins целевого домена в локальную группу администраторов:

Создаём групповую политику, в редакторе переходим к пункту Computer conf.-Windown Settings- Security Settings-Restricted Groups. Клик правой кнопкой — добавить группу — вносим Administrators. В члены данной группы заносим Domain admins обоих доменов. ВНИМАНИЕ: данная политика заменит содержимое локальной группы Администраторы на указанные в политике (в рассмотренном случае — source\Domain Admins; targer\Domain Admin) плюс локальная запись Администратор. Всё остальные пользователи из неё убираются.

snap2

Так же рекомендуется для Windows XP выключить брандмауэр (firewall). Сделать это можно так же через групповую политику.

Начало миграции
Теперь можно вплотную приступить к миграции домена. Первым делом — потестировать (вообще рекомендую подобные вещи вначале тестировать в виртуальной среде). Тестирование заключается в миграции специально подготовленной группы

В исходном домене создаём локальную группу source_domain$$ (в нашем случае группа будет называться source$$). Не добавляйте в неё пользователей! Эта группа нужна для инициализации миграции, и проверки миграции SID.
Открываем консоль ADMT. В открывшейся оснастке правой кнопкой на Active Directory Migration Tools — Group Account Migration Wizard.

Wizard page	Action
Domain Selection	Выбираем домены. В Source domain соотв. исходный, в target — целевой.
Group Selection	Выбираем «выбрать группы из домена» (Select groups from domain). В следующем пункте выбираем созданную группу source$$$.
Organizational Unit Selection	Выбираем подразделение в целевом домене, куда будет помещен объект миграции. Рекомендую создать отдельное подразделение, и все перенесённые объекты складывать в него.
Group Options	Отмечаем пункт «Migrate Group SIDs to target domain» С остальных пунктов пометку выбора снимаем.
User Account	Вводим логин-пароль учётной записи с правами администратора в исходном домене.
Conflict Management	Выбираем «Do not migrate source object if a conflict is detected in the target domain».

После миграции просматриваем лог на предмет ошибок и предупреждений (не ленимся). Проверяем пункт «Migrate Security Identifiers» — должен стоять yes.

В логах может встретиться предупреждение о несовпадении схем доменов, и то что некоторые атрибуты не перенесутся. Это получается из-за несовпадений схемы 🙂 в моём случае схема одного из доменов была расширена Exchange сервером. Вообщем не критично, но лучше сразу убедиться что вызывает данное предупреждение.

Миграция служебных учётных записей
Мастер миграции служебных записей (Service Account Migration Wizard) проверяет серевера, указанные администратором, на наличие служб, работающих под доменным учётными записями. Пароли таких записей не мигрируют. Для миграции: в оснастке ADMT выбираем пункт Service Account Migration Wizard. Далее выполняем следующую последовательность действий:

Wizard page	Action
Domain Selection	Выбираем домены. В Source domain соотв. исходный, в target — целевой.
Update Information	Выбираем Yes, update the information.
Computer Selection Option	Выбираем Select computers from domain. В пункте Service Account Selection, добавляем учётные записи из исходного домена, которые хотим мигрировать.
Agent Dialog	В открывшемся окне Agent Actions, выбираем пункт Run pre-check and agent operation, и запускаем Start. После окончания обязательно просмотреть лог миграции и Agent Detail на наличие ошибок и предупреждений.
Service Account Information	Выбираем любые учётные записи, которые не были отмечены как служебные, и жмём Skip/Include
Completing the Service Account Migration Wizard	Завершаем миграцию, нажатием Finish.

Миграция групп
Следующим этапом идёт миграция глобальных групп. (стоит сразу отметить, что встроенные группы не мигрируют). При дальнейшей миграции пользователей, членство в группах будет восстановлено автоматически.
Для миграции так же, как и в прошлых пункатх, открываем ADMT, выбираем «Group Account Migration Wizard». Далее действуем согласно таблице:

Wizard page	Action
Domain Selection	Выбираем домены. В Source domain соотв. исходный, в target — целевой.
Group Selection	Выбираем «Select groups from domain». Добавляем группы для миграции
Organizational Unit Selection	Выбираем подразделение в целевом домене, куда будут помещены группы после миграции.
Group Options	Выбираем «Migrate Group SIDs to target domain», с остальных пунктов необходимо снять галочки выбора.
User Account	Указываем учётные данные пользователя, имеющего права администратора в исходном домене.
Conflict Management	Выбираем пункт «Do not migrate source object if a conflict is detected in the target domain» (не мигрировать, в случае обнаружения конфликтов с объектами целевого домена).

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

Миграция учётных записей пользователей
Для миграции пользователей с переносом истории SID необходимо предварительно мигрировать все учётные записи. При этой миграции, учётные записи переносятся отключенными, со сгенерированным паролем. Пользователи продолжают использовать учётные записи в исходном домене. В дальнейшем будет произведена повторная миграция пользователей, но уже с необходимыми атрибутами.
Открываем консоль ADMT, выбираем пункт «User Account Migration Wizard». Далее, согласно таблице:

Wizard page	Action
User Selection	Выбираем «Select users from domain», далее добавляем пользователей. На следующей странице выбираем подразделение, куда разместить учётные записи после миграци.
Password Options	Выбираем пункт «Do not update passwords for existing users» и «Generate complex passwords», для генерации пароля.
Account Transition Options	В «Target Account State» отмечаем «Disable target accounts», для отключения перенесенных записей в целевом домене. Включаем опцию «Migrate user SIDs to target domains»
User Options	Отмечаем пункты «Translate roaming profiles» и «Fix users’ group memberships», с остальных пунктов галочку снимаем.
Object Property Exclusion и Conflict Management	Снимаем галочку «Exclude specific object properties from migration».
Conflict Management	Выбираем пункт «Do not migrate source object if a conflict is detected in the target domain.»

Перенос локальных профилей
Перед миграцией ПК, необходимо перенести локальные профили пользователей. На данном этапе целесообразно выделить группы пользователей, отражающих порядок миграции. Дальнейшие этапы мигарции проводить не над всем списком пользователей, а над этими группами.
На момент переноса профилей, и миграции ПК не должно быть активных пользовательских сессий. Для переноса (трансляции) профилей: в оснастке ADMT, выбираем пункт «Security Translation Wizard»

Wizard page	Action
Computer Selection	Выбираем пункт «Select from domain», и добавляем необходимые ПК, согласно группе миграции.
Translate Objects	Отмечаем пункт «User Profiles»
Security Translation Options	Отмечаем пункт «Replace»
Заканчиваем wizard	Заканчиваем wizard, жмём Готово. После закрытия мастера откроется окно Агента ADMT
ADMT Agent Dialog	Выбираем пункт «Run pre-check and agent operation» и запускаем
Настройки ADMT Agent	При необходимости, можно предварительно запустить проверку Precheck, если нет уверенности в доступности ПК.

После завершения работы мастера и агента, просматриваем логи Агента на наличие ошибок.

Миграция ПК

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

Открываем ADMT, выбираем пункт Computer Migration Wizard

Wizard page	Action
Computer Selection и Organization Unit	Выбираем пункт «Select from domain», и добавляем необходимые ПК, согласно группы миграции. (те же пк, что и в прошлом пункте). Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
Translate Objects и Security Translation Options	Выбираем Локальные группы, и Права пользователей. В следующем пункте выбираем «Add»
Computer Options	В данном пункте выбираем, через какое время, после работы мастера, ПК будет перезагружен. По-умолчанию 5 минут.
Object Property Exclusion	В данном пункте можно выбрать, какие параметры схемы исключить из миграции.
Conflict Management	Выбираем пункт «Do not migrate source object if a conflict is detected in the target domain», дабы исключить перезапись объектов, если они уже существуют.
ADMT Agent Dialog	Выбираем пункт «Run pre-check and agent operation» и запускаем

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

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

Wizard page	Action
Выбор пользователей и OU для миграции	Выбираем пункт «Select from domain», и добавляем необходимые учётные записи, согласно группы миграции. (те же пк, что и в прошлых пунктах). Переходим на следующий пункт и выбираем подразделение, куда будут помещены компьютеры.
Параметры пароля	Отмечаем пункт Migrate Password. Указываем сервер PES (настраивали в прошлых пунктах)
Account Transition Options	На данном пункте оставляем целевую учётную запись включенной (Target Account), исходную учётную запись выключаем (Source), либо указываем через сколько дней её отключить. Отмечаем пукнт «Migrate user SIDs to target domain», для копирования истории SID в целевой домен.
Параметры пользователя	Указываем учётную запись, из под которой будет осуществляться доступ в исходный домен. Переходим на следующий пункт «User options», отмечаем пункты «Translate roaming profiles» (перенос перемещаемых профилей), «Update user rights» (обновление прав пользователей), «Fix users’ group memberships» (исправить членство в группах). Убрать галочку с пункта «Migrate associated user groups».
Object Property Exclusion	Убрать галочку «Exclude specific object properties from migration»
Conflict Management	Отмечаем пункт Migrate and merge conflicting objects. (мигрировать и объединить конфликтующие объекты) Убираем галочки с пунктов «Before merging remove user rights for existing target accounts» (перед объединением (слиянием) — очистить матрицу прав пользователя), и «Move merged objects to specified target Organizational Unit» (переместить объект после объединения в указанное организационное подразделение).

Миграция серверов

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

Всем удачной работы !!!

12.07.2012 —

Posted by |
ms windows server 2008

Sorry, the comment form is closed at this time.

Источник

В этой статье мы поговорим о процедуре обновления домена с версии Windows Server 2008 R2 до Windows Server 2012 с последующим понижением роли старого контроллера домена до рядового сервера AD.

Итак, что имеется:

Домен Active Directory как минимум с одним контроллером домена на Windows Server 2008 R2
Уровень леса и домена AD должен быть как минимум Windows Server 2003
Дополнительный рядовой сервер домена с Windows Server 2012 , который в дальнейшем станет контроллером домена (как включить сервер в домен подробно описано в статье Как включить Windows в домен).
Учетная запись с правами администратора домена, схемы и леса.

Прежде чем добавлять новый контроллер домена на Windows 2012 необходимо обновить схему домена и леса. Классически подготовка и повышение уровня домена осуществлялась вручную с помощью утилиты Adprep.exe. В документации новой серверной платформы от Microsoft указано, что при повышении первого сервера с Windows Server 2012 до уровня контроллера домена, повышение уровня домена происходит автоматически при установке роли AD DS на первый сервер Windows 2012 в домене. Так что, теоретически, для подготовки домена ничего делать не нужно.

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

Обновление схемы AD до Windows Server 2012 с помощью adprep

Для обновления схемы нам понадобится утилита adprep.exe, взять которую можно в каталоге \support\adprep\ на диске с дистрибутивом Windows Server 2012. Данная утилита бывает только 64-разрадной (утилиты adprep32.exe больше не существует), соответственно, запустить ее можно будет только на 64 разрядном контроллере домена.

Необходимо скопировать утилиту на текущий DC с ролью Schema Master (Хозяин схемы) и в командной строке с правами администратора выполнить команду подготовки леса к установке нового DC на Windows Server 2012:

adprep /forestprep

Версия схемы Active Directory в Windows Server 2012 — 56.

Далее обновим схему домена:

adprep /domainprep

Далее осталось дожидаться окончания репликации изменений в схеме по всему лесу и проверить существующие контроллеры домена на наличие ошибок. Если все прошло хорошо – продолжаем. Пришла пора развернуть контроллер домена на Windows Server 2012.

Установка контроллер домена на Windows Server 2012

Первой интересной новостью является тот факт, что знакомой администраторам утилиты DCPROMO, позволяющей добавить или удалить контроллер домена в AD больше не существует. При ее запуске появляется окно, в котором сообщается, что мастер установки Active Directory Domain Services перемещен в консоль Server Manager.

Что ж, откроем консоль Server Manager и установим роль Active Directory Domain Services (Внимание! Установка роли автоматически не означает тот факт, что сервер стал контроллером домена, роль нужно сначала настроить)

После окончания установки роли появится окно, в котором сообщается, что сервер готов стать контроллером домена, для чего нужно нажать на ссылку “Promote this server to domain controller” (далее мы рассмотрим только значимые шаги мастера создания нового контроллера домена).

Затем нужно указать, что данный контроллер домена будет добавлен в уже существующий домен (Add a domain controller to an existing domain), указать имя домен и учетную запись из-под которой будет проводится операция.

Затем укажите, что данный контроллер домена будет содержать роли GC (Global Catalog) и DNS сервера. Также укажите пароль восстановления DSRM (Directory Services Restore Mode) и, если необходимо имя сайта, к которому будет относиться данный контроллер домена.

В разделе “Paths” указываются пути к базе Active Directory (NTDS), файлам логов и каталогу SYSVOL. Учтите, что данные каталоги должны находиться на разделе с файловой системой NTFS, тома с новой файловой системой Windows Server 2012 — Resilient File System (ReFS) – использовать для этих целей нельзя!

По окончании работы мастера установки роли AD DS, сервер нужно перезагрузить. После перезагрузки вы получаете новый контроллер домена с ОС Windows Server 2012.

Удаление старого контроллера домена на Windows Server 2008 R2

Прежде, чем понизить роль старого контроллера домена с Windows Server 2008 R2 до рядового сервера, нужно перенести все FSMO роли на новый контроллер домена .

Процедура переноса ролей FSMO с одного контролера домена на другой нами уже рассматривалась, подробнее с ней можно познакомится в статье Передача ролей FSMO в Active Directory. Процедуру можно осуществить через графический GUI (проще) или из командной строки с помощью утилиты ntdsutil

После передачи роли FSMO PDC Emulator, необходимо настроить синхронизацию времени на новом контроллере домена с внешним сервером (с которым время синхронизировалось ранее). Подробно процедура настройки синхронизации времени на PDC описана в статье: Синхронизация времени с внешним NTP сервером в Windows 2008 R2 . Формат команды примерно такой (ntp_server_adress – адрес NTP сервера):

w32tm /config /manualpeerlist:ntp_server_adress /syncfromflags:manual /reliable:yes /update

После того, как все роли FSMO перенесены на новый DC Windows Server 2012, убедитесь, что домен работает корректно: проверьте прохождение репликации AD, журналы DNS и AD на наличие ошибки. Не забудьте в настройках сетевой карты на новом сервере в качестве предпочтительного DNS сервера указать собственный адрес.

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

Источник

Прочитано:
16 210

Задача: Нужно проработать процесс миграции домена на базе Windows Server 2008 R2 на Windows Server 2016

От моего коллеги по работе поступила задумка, а реально ли смигрировать текущий домен контроллер на базе Windows Server 2008 R2 Enterprise на систему с осью Windows Server 2016 Standard, в итоге новый контроллер домена будет обладать повышенными возможностями по управлению инфраструктурой. Да и пора уже избавиться от железной составляющей текущего домена на переход под Hyper-V система виртуализации которой используется в организации где я сейчас работаю.

Данная задача прорабатывается под Virtulbox основной системы Ubuntu 18.04 Desktop amd64 ноутбука Lenovo E555

Исходные данные:

srv-dc1.polygon.local (на базе Windows Server 2008 R2 Enterprise) с ролями: AD DC,DHCP,DNS
IP address: 10.90.90.2/24

C:\Users\Administrator>netsh firewall set icmpsetting 8 enable

Login: ekzorchik
Pass: 712mbddr@
Group: Domain Admins, Schema Admins, Enterprise Admins

C:\Windows\system32>netdom query fsmo

Schema master srv-dc1.polygon.local
Domain naming master srv-dc1.polygon.local
PDC srv-dc1.polygon.local
RID pool manager srv-dc1.polygon.local
Infrastructure master srv-dc1.polygon.local
The command completed successfully.

srv-dc2.polygon.local (на базе Windows Server 2016) пока без ролей

IP address: 10.90.90.3/24

C:\Users\Администратор>netsh firewall set icmpsetting 8 enable

Шаг №1: Авторизуюсь под локальной учетной записью «Администратор» на srv-dc2. Ввожу данную систему в домен polygon.local.

Win + R → control.exe → Система — «Изменить параметры» — вкладка «Имя компьютера» окна «Свойства системы» нажимаю «Изменить«, отмечаю галочкой «Является членом«: Домена и указываю домен: polygon.local, затем нажимаю кнопку «ОК«.

[stextbox id=’alert’]

На заметку: Не забудьте в настройках сетевой карты хоста srv-dc2 указать DNS сервер системы srv-dc1 иначе получите ошибку: «При запросе DNS записи ресурса размещения службы (SRV), используемой для нахождения контроллера домена Active Directory для домена «polygon.local«, произошла ошибка:

Произошла ошибка: «Для локальной системы не настроено ни одного DNS-сервера.»»

[/stextbox]

Итак, DNS-сервер прописан в свойствах сетевого адаптера, при попытке ввода системы в домен понадобится знание учетных данных обладающих правами «Администраторы Домена (Domain Admins) или обладающих правами делегированных. Авторизую систему для присоединения к домену

Имя пользователя: ekzorchik
Пароль: 712mbddr@

и нажимаю «ОК» окна «Безопасность Windows«, обязательно Вы должны увидеть окно: «Добро пожаловать в домен polygon.local«. Перезагружаю систему для активации изменений, затем нажимаю сочетание клавиш «Ctrl + Alt + Del» и авторизуюсь в системе также под учетной записью входящей в группы которые есть в учетной записи ezkorchik если у Вас она отличается.

Шаг №2: Делаю систему srv-dc2 контроллером домена:

Win + R → control.exe или Win + X → «Панель управления» — «Администрирование» — «Диспетчер серверов» — «Панель мониторинга» — «Добавить роли и компоненты» — «Установка ролей или компонентов» — Выберите сервер из пула серверов: srv-dc1.polygon.local — отмечаю галочкой роль «Доменные службы Active Directory» — нажимаю «Добавить компоненты» — «Далее» — «Далее» — отмечаю галочкой «Автоматический перезапуск конечного сервера, если требуется» и нажимаю «Установить«.

Теперь настройка устанавливаемых компонент:

Win + R → control.exe или Win + X → «Панель управления» — «Администрирование» — «Диспетчер серверов» — «AD DS«:

«Доменные службы Active Directory — требуется настройка на srv-dc2» → нажимаю «Подробнее» — «Повысить роль этого сервера до уровня контроллера домена«. Операцию развертывания выбираю:

«Добавить контроллер домена в существующий домен»

Домен: «polygon.local«

Для выполнения этой операции введите учетные данные: нажимаю «Изменить«, т. к. сейчас подставлены svr-dc2\Администратор (текущий пользователь) и указываю:

Логин: ekzorchik
Пароль: 712mbddr@

и нажимаю «ОК«, потом «Далее» окна «Мастер настройки доменных служб Active Directory«. Параметры контроллера домена оставляю дефолтными (это отмеченные галочкой DNS-сервер, Глобальный каталог (GC)), но обязательно нужно указать пароль для режима восстановления служб каталогов (DSRM):

Пароль: 712bmddr@
Подтверждение пароля: 712mbddr@

и нажимаю «Далее» — «Далее«, указываю откуда отреплицировать данные:

Источник репликации: srv-dc1.polygon.local

и нажимаю «Далее» — «Далее» — «Далее» — «Далее«, обязательно следует убедиться в появлении надписи «Все проверки готовности к установке выполнены успешно» и только тогда нажимаем «установить«. В процесс система будет перезагружена. Авторизуюсь с использованием учетных данных login: ekzorchik

Шаг №3: Проверяю количество домен контроллеров и отсутствие ошибок в домена с использованием команд:

Win + X — Командная строка (администратор)

C:\Windows\system32>netdom query dc

Список контроллеров домена с учетными записями в домене:

SRV-DC1
SRV-DC2

Команда выполнена успешно.

Отобразить текущий функциональный уровень леса:

C:\Windows\system32>dsquery * "CN=Partitions,CN=Configuration,DC=polygon,DC=local" -scope base -attr msDS-Behavior-Version

msDS-Behavior-Version

4 → где данное число расшифровывается, как Windows Server 2008 R2 operating system and later

Отобразить текущий функциональный уровень домена:

C:\Windows\system32>dsquery * "dc=polygon,dc=local" -scope base -attr msDS-Behavior-Version ntMixedDomain

msDS-Behavior-Version ntMixedDomain

4 0 → Windows Server 2008 operating system or later DCs in the domain

Шаг №4: Захватываю все роли с srv-dc1 на srv-dc2:

C:\Windows\system32>ntdsutil

ntdsutil: roles
fsmo maintenance: connection
server connections: connect to server srv-dc1.polygon.local

Привязка к srv-dc1.polygon.local …

Подключен к srv-dc1.polygon.local с помощью учетных данных локального пользователя.

server connections: quit

Затем применительно к каждой роли FSMO производим захват/миграцию:

fsmo maintenance: seize schema master

fsmo maintenance: seize naming master

fsmo maintenance: seize pdc

fsmo maintenance: seize rid master

fsmo maintenance: seize infrastructure master

[stextbox id=’alert’]На заметку: На все вопросы по захвату ролей нажимаю «Да«[/stextbox]

После не забываем выйти из консоли команды ntdsutil вводом quit.

fsmo maintenance: quit

ntdsutil: quit

C:\Windows\system32>

Проверяю кто сейчас держит роли FSMO:

C:\Windows\system32>netdom query fsmo

Хозяин схемы srv-dc2.polygon.local
Хозяин именования доменов srv-dc2.polygon.local
PDC srv-dc2.polygon.local
Диспетчер пула RID srv-dc2.polygon.local
Хозяин инфраструктуры srv-dc2.polygon.local

Команда выполнена успешно.

Так осталось перевести роль «Хозяина схемы» и «Хозяина именования доменов«:

C:\Windows\system32>powershell

PS C:\Windows\system32> Move-ADDirectoryServerOperationMasterRole -Identity "srv-dc2" -OperationMasterRole 4

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

Вы хотите переместить роль «DomainNamingMaster» на сервер «srv-dc2.polygon.local«?

[Y] Да - Y [A] Да для всех - A [N] Нет - N [L] Нет для всех - L [S] Приостановить - S [?] Справка

(значением по умолчанию является "Y"):A

PS C:\Windows\system32> Move-ADDirectoryServerOperationMasterRole -Identity "srv-dc2" -OperationMasterRole 3 -force

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

Вы хотите переместить роль «SchemaMaster» на сервер «srv-dc2.polygon.local«?

[Y] Да - Y [A] Да для всех - A [N] Нет - N [L] Нет для всех - L [S] Приостановить - S [?] Справка

(значением по умолчанию является "Y"):A

PS C:\Windows\system32> exit

Чтобы отобразить какой теперь функциональный уровень домена:

C:\Windows\system32>dsquery * "dc=polygon,dc=local" -scope base -attr msDS-Behavior-Version ntMixedDomain

msDS-Behavior-Version ntMixedDomain

4 0 — где данное значение расшифровывается, как Windows Server 2012 R2

Чтобы отобразить версию схемы Active Directory Schema:

C:\Windows\system32>dsquery * "CN=Schema,CN=Configuration,dc=polygon,dc=local" -scope base -attr objectVersion

objectVersion

87 — где данное значение расшифровывается, как Windows Server 2016, а все из-за того, что я в текущем домене сделал контроллером домена новую систему, а значит и могу поднять функциональный уровень домена и уровень леса.

Шаг №5: Удаляю контроллер домена под управлением Windows Server 2008 R2 из глобального каталога. На Server 2016 (srv-dc2) открываю оснастку:

Win + X — Панель управления — Администрирование — «Active Directory Сайты и Службы» и выделяю левой кнопкой мыши сервере srv-dc1 который являлся контроллером домена ранее в текущей сайте «Default-First-Site-Name» на NTDS Settings снимаю в свойствах галочку с настройки «Глобальный каталог»

Шаг №6: Опираясь на заметку по «Удалению неисправного домена контроллера из Active Directory в Server 2008 R2»

проделываю все указанные там действия. Выключаю srv-dc1

C:\Windows\system32>ntdsutil

ntdsutil: metadata cleanup
metadata cleanup: connections
server connections: connect to server srv-dc2

Привязка к srv-dc2 …

Подключен к srv-dc2 с помощью учетных данных локального пользователя.

server connections: quit
metadata cleanup: select operation target
select operation target: list sites

Найдено сайтов: 1

0 — CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

select operation target: select site 0

Сайт — CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

Нет текущего домена

Нет текущего сервера

Нет текущего контекста именования

select operation target:

select operation target: list servers in site

Найдено серверов: 2

0 — CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

1 — CN=SRV-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

select operation target:

select operation target: select server 0
select operation target: list domains

Найдено доменов: 1

0 — DC=polygon,DC=local

select operation target: select domain 0

Сайт — CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

Домен — DC=polygon,DC=local

Сервер — CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

Объект DSA — CN=NTDS Settings,CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local

Имя DNS-узла — srv-dc1.polygon.local

Объект-компьютер — CN=SRV-DC1,OU=Domain Controllers,DC=polygon,DC=local

Нет текущего контекста именования

metadata cleanup: remove selected server

Передача или захват ролей FSMO от выбранного сервера.

Удаление метаданных FRS для выбранного сервера.

Поиск членов FRS в «CN=SRV-DC1,OU=Domain Controllers,DC=polygon,DC=local».

Удаление поддерева в «CN=SRV-DC1,OU=Domain Controllers,DC=polygon,DC=local».

Ошибка при попытке удалить параметры FRS на CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local: «Элемент не найден.»;

очистка метаданных продолжается.

«CN=SRV-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=polygon,DC=local» удалена с сервера «srv-dc2»

Из оснастки DNS сервера svr-dc2 удаляем все упоминания об srv-dc1. И переопределяем DNS-сервер в настройках сетевого адаптера хоста srv-dc2 с 10.90.90.2 на 10.90.90.3

Шаг №7: Проверяю текущий домен контроллер на наличие ошибок: dcdiag & repadmin

PS C:\Windows\system32> repadmin /syncall

СООБЩЕНИЕ ОБРАТНОГО ВЫЗОВА: Завершена операция SyncAll.

Команда SyncAll завершена без ошибок.

PS C:\Windows\system32> repadmin /showrepl

Repadmin: выполнение команды /showrepl контроллере домена localhost с полным доступом

Default-First-Site-Name\SRV-DC2

Параметры DSA: IS_GC

Параметры сайта: (none)

DSA — GUID объекта: 401b3342-854f-4eb4-8261-ff6ce3848354

DSA — код вызова: 20507c04-d7a4-4a88-9eae-7a6dbd015321

Шаг №8: Изменяю режим работы леса с Windows Server 2008 R2 на Windows Server 2016 через оснастку «Active Directory — домены и доверие» щелкнув правой кнопкой мыши по надписи «Active Directory — домены и доверие» открытой оснастки, затем выбрав элемент меню «Изменение режима работы леса» и изменяю режим работы леса на «Windows Server 2016» и нажимаю «Изменить» — «ОК» окна «Повышение режима работы леса«. Или можно через консоль командной строки powershell проделать это:

C:\Windows\system32>powershell

Windows PowerShell

PS C:\Windows\system32> Set-ADDomainMode -identity polygon.local -DomainMode Windows2016Domain

PS C:\Windows\system32> Set-ADForestMode -identity polygon.local -ForestMode Windows2016Forest

Проверить, что команды выше отработали как надо можно так:

PS C:\Windows\system32> get-addomain | fl Name,DomainMode ;get-adforest | fl Name,ForestMode

Name : polygon
DomainMode : Windows2016Domain
Name : polygon.local
ForestMode : Windows2016Forest

Результат положителен. Я успешно оформил как заметка, как повысить домен до уровня Windows2016 путем захвата всех ролей на новом домен контроллере под управлением Windows Server 2016 Standard.

Шаг №9: Не забываем, раз на srv-dc1 был DHCP сервер, то его стоило забекапить, а потом импортировать на srv-dc2, либо же если настроек не много и Вы все помните, то установить роль DHCP сервиса и настроить область выдачи IP—адресов.

[stextbox id=’alert’]На заметку: Не обязательно иметь в локальной сети DHCP сервис на базе Windows, можно чтобы он был и на сетевом оборудовании, к примеру Mikrotik. У меня так.[/stextbox]

Может так случить, что служба работает, но развернутая область не активна. В логах есть ошибки на этот счет: Event ID 1056

Служба DHCP обнаружила, что она запущена на контроллере домена (DC) и не имеет учетных данных, настроенных для использования с динамическими DNS-регистрациями, производимыми службой DHCP. Подобная конфигурация безопасности не рекомендуется. Учетные данные динамических DNS-регистраций можно настроить с помощью утилиты командной строки «netsh dhcp server set dnscredentials» или с помощью программы администрирования DHCP.

C:\Windows\system32> netsh dhcp server set dnscredentials ekzorchik poligon.local 712mbddr@

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

Шаг №10: Проверяю, что рабочая станция может стать членом текущего домена и авторизоваться в нем.

C:\Users\alektest>hostname

system

C:\Users\alektest>ipconfig

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

Ethernet adapter Подключение по локальной сети:

DNS-суффикс подключения . . . . . : polygon.local

IPv4-адрес. . . . . . . . . . . . : 10.90.90.10

Маска подсети . . . . . . . . . . : 255.255.255.0

Основной шлюз. . . . . . . . . : 10.90.90.1

а на srv-dc2:

C:\Users\ekzorchik>dsquery computer

"CN=SRV-DC2,OU=Domain Controllers,DC=polygon,DC=local"

"CN=SYSTEM,CN=Computers,DC=polygon,DC=local" → ну вот и рабочая станция успешно авторизованная в домене.

Итого, заметка работоспособна. Раз получилось сделать в тестовой конфигурации, то как показывает моя практика сделать это можно будет и на боевой инфраструктуре. На этом у меня всё, с уважением автор блога Олло Александр aka ekzorchik.

Источник