Перенос контроллера домена windows server

Статью конечно надо было назвать немного по другому (ибо на гуру претендовать смысла нет), а именно «Как я мигрировал контроллер домена на Windows Server 2012», но всё же…

Начальная ситуация такова. В конторе есть контроллер домена на Windows Server 2012 Standart, используется в техподдержке и фактически только для того, чтобы операторы могли скакать с компа на комп без проблем. После нескольких лет работы, внезапно, появилось «Windows License is expired», всякие ломалки(KMS и прочие) почему-то не работают, он стал вырубаться каждые два часа. Это есть не удобно. Было решено поднять рядом новый сервер и перенести на него. Приступаем.

Домен называется: office.esteit.com
Старый контроллер: thetwo.office.esteit.com
Новый контроллер: dc01.office.esteit.com

1. Ставим Windows Server 2012 R2 Standart, активируем, настраиваем что надо и вводим сервер в существующий домен

2. Устанавливаем роль Active Directory Domain Services

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

4. Далее указываем, что этот сервер будет выполнять роль DNS сервера и глобального каталога (Global Catalog – GC) и задаём пароль для восстановления

5. На экране Additional Options нужно указать с какого контроллера домена будет выполнена репликация

6. Дальше можно ничё не менять без особой надобности. Next, Next, Next, Install

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

8. Подключаемся под учётной записью домена и проверяем в оснастке Active Directory Users and Computers, что в нашей сети есть два контроллера домена

После выполнения всех шагов, переходим к переносу Active Directory. Все действия проводим на новом контроллере домена в следующем порядке:

• Перенос роли FSMO (Flexible Single Master Operations)
• Изменение контроллера домена Active Directory
• Изменение Мастера схемы (Schema Master)
• Удаление старого контроллера домена из глобального каталога (Global Catalog)

Перенос роли FSMO (Flexible Single Master Operations)

Для переноса роли FSMO, открываем оснастку Active Directory Users and Computers, щёлкаем по нашему домену и в появившемся подменю выбираем Operations Masters

Переносим роль хозяина операций. Для этого на каждой вкладке во вновь появившемся окне нажимаем кнопку Change и переносим роль со старого сервера на новый

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

Изменение контроллера домена Active Directory

Переходим к изменению контроллера домена Active Directory. Открываем консоль Active Directory Domains and Trusts, щёлкаем по Active Directory Domain and Trusts и выбираем пункт Change Active Directory Domain Controller

В новом окне выбираем пункт This Domain Controller or AD LDS instance и указываем новый сервер

Теперь снова щёлкаем по Active Directory Domains and Trusts и выбираем пункт Operations Master

Переносим роль хозяина операций именования домена, нажав Change

Изменение Мастера схемы (Schema Master)

Теперь приступаем к изменению мастера схемы (Schema Master). Запускаем командную строку с правами Администратора и вводим команду regsvr32 schmmgmt.dll

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

После того, как команда выполнена, запускаем консоль MMC и добавляем оснастку Active Directory Schema (для этого выбираем File > Add/Remove Snap-in)

В этой же консоли MMC щёлкаем по Active Directory Schema и выбираем Change Active Directory Domain Controller

В новом окне выбираем пункт This Domain Controller or AD LDS instance и указываем новый сервер

Появится предупреждение о том, что оснастка схемы Active Directory не подключена. Нажимаем ОК

Теперь снова щёлкаем по Active Directory Domains and Trusts и выбираем пункт Operations Master

Для переноса роли хозяина схемы в новом окне нажимаем Change

Удаление контроллера домена под управление Windows Server 2003 из глобального каталога (Global Catalog)

Осталось удалить старый контроллер домена из глобального каталога. Для этого открываем Active Directory Sites and Services, разворачивает папку Sites, затем Default-First-Site-Name, затем Servers и, наконец, разворачиваем оба сервера

Щёлкаем по NTDS Settings для старого сервера, выбираем Properties. Во вновь появившемся окне убираем галочку с пункта Global Catalog и жмём ОК

В Active Directory Users and Computers контроллер домена на старом сервере теперь не является глобальным каталогом

Проверяем, что теперь роль FSMO запущена на новом сервере. Для этого в командной строке, открытой с правами Администратора запускаем команду netdom query fsmo

На этом миграция Active Directory завершена. Понижаем роль компьютера с контроллера домена на старом сервере. Если после этого посмотреть на консоль Active Directory Users and Computers, увидим, что остался только один(новый) контроллер домена – под управлением Windows Server 2012 R2

Migrate Domain Controller from Windows Server 2012 & R2 to Windows Server Server 2016

In this article, you can find the step by step migration process for migrating Server 2012 & R2 DCs to Windows Server 2016
DC.

The recommendation is the functional level needs to be least at Server 2008.

We start with Domain Controller health checks.

We should run “dcdiag” for check health status of a DC. If you find any health issue on current DCs,you should fix the issues
before migration process.

Again, we need to check the replication status of DC entire domain. Also the same if you find any replication issues between
your DCs, you should fix the replication problems before migration process. We can run “repadmin /replsum” for check the replication status of DCs. (Also you can check the replication status with AD replication status tool.)

And we need a account for migration process which is member of administrative groups (like Enterprise, domain and schema
admins group).

Also, we should be sure all FW already disabled on DCs, necessary ports accessible between DCs, the time settings are correct. Then
you should configure correct IP on Server 2016, same time new server 2016 needs to be fully patched.

When all these things done join Server 2016 to existing domain.

When join to domain, you can logon with your administrative account on Server 2016. Then select “Add Roles and Features” from Server
Manager.

You can see the information screen, click Next.

You should select Role-Based installation.

We should select the server to add role to it. (So we should select new server 2016 cause we add the role on it.)

Next screen you should select “Active Directory Domain Services”.

Incoming screen said that the necessary features will be add the role.

You can see information about ADDS, click Next.

We are on the Confirm installation screen. To start the installation, click “Install” button.

There is a screen that shows up about the add role and features installed successfully. As you see ADDS,GPM,RSAT already
added to our new server.

Then you can see an attention on Server Manager menu and you should select
“Promote this server to a domain controller”.

We need to add new Server 2016 as Additional Domain Controller to our existing domain that’s why we should select
”Add a domain controller to an existing domain”.

You should also select “DNS” and “GC” roles for redundancy.

Site name: Default site name become automatically.(default)

DSRM password: We must keep that password configure here, cause any of DC restore process we need it.

We can select the replication partner on this screen. If you select “Any domain controller” it will select the nearest replication
partner.

You can see the DB, Log Files, SYSVOL location on this screen. The recommendation from Microsoft is keeping it on default
location ( on C drive).

The new features come with Server 2012 update forest, schema and domain prep automatically also available with Server 2016.

You can check the settings so far. Click Next.

This screen verifying the system prerequisite check. If it is valid the you can click “Install”, but if any of issues find
the installation will not start until the issue is solved.

Forest preparation screen.

Domain preparation.

When this process is done, new Server 2016 add existing domain as an additional domain controller.

When you restart new 2016 DC and logon you can see new roles already added on DC.

So far, we could add server 2016 as additional domain to our existing domain. Now we should check the necessary control’s
on the domain.

 Start with replication status check. Run
“repadmin /replsum”, and see the replication’s status is OK.

We should check that the SYSVOL folder successfully created on new Server 2016 and this is also OK.

Last thing we need to check the new server 2016 DC Health status, run “dcdiag” and as you see this is also OK. The server 2016 DC is
healthy.

Now we are sure that the migration process is done successfully and it is time to transfer fsmo roles to new Server 2016 DC, then the
server 2016 DC will be PDC for your domain.

Open to “cmd “ console and run “netdom query fsmo” to check fsmo roles holder.

netdom query fsmo

In a lab environment all roles on a single DC. (testdc.random.com)

And we start to transfer fsmo roles to new server 2016 DC. Used “ntdsutil.exe” to transfer roles.

cmd > ntdsutil >roles> connections > connect to server dc2016.random.com
(You should configure your own server name here.)

When connect

server connections : q
for existing.

You should run belowing command in order to transfer fsmo roles

Fsmo maintenance:
Transfer infrastructure master

Fsmo maintenance:
Transfer naming master

Fsmo maintenance:
Transfer PDC

Fsmo maintenance:
Transfer RID master

Fsmo maintenance:
Transfer Schema master

You should select “Yes” all of transfer attention screens.

When done need to check the roles transfer successfully. Run “netdom query fsmo”. As you see all fsmo roles (a single domain and all
roles (5) on a single DC) successfully transfer on new server 2016 DC.

Finally, all migration steps done including transfer fsmo roles on new server 2016 DC. Recommend that you run old server 2012 DC and
server 2016 DC together for a while at this time so you can check the possible issues. Also there isn’t any known issue related with MS products running with Server 2016 DC, but third-party applications and software, you should contact to vendor to check Server
2016 compatibility before migration.

Last thing when you raise functional level to Server 2016, the older Server OS DCs become nonfunctional.(Server 2012, 2008, etc.) so
before raising functional level you should demote old DCs from domain.

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.

1. After the OS installation and Patching process is completed, go ahead and join the new Windows Server 2022 to the existing domain.
2. 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.
3. 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,

1. Log in to the server as an enterprise administrator.
2. Verify the static IP address allocation using ipconfig /all.
3. Launch the PowerShell 7 Console as an Administrator.
4. 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

1. 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.

1. 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.

1. 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.

1. 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,

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

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

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

1. 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.

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

1. 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 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

UPD: Создал видеоканал на youtube куда постепенно выкладываю обучающие видео по всем областям ИТ, в которых хорошо разбираюсь, подписывайтесь: http://www.youtube.com/user/itsemaev

UPD2: Микрософт традиционно меняет привычный синаксис в командной строке, поэтому роли в кажлый версии Windows Server могут звучать по-разному. Они вообще теперь не fsmo называются а operation masters. Так вот, для корректных команд в консоли после fsmo maintenance напишите просто ? и он вам покажет доступные команды.

У меня в апрельский журнал «Системный администратор» взяли статью на тему «Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server»

И даже сто долларов заплатили и дали пакет с мозгами)) Я теперь Онотоле.

Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server. (кому вдруг надо — картинки пришлю)

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

Практически каждый администратор, работающий с серверами на базе Windows, рано или поздно сталкивается с необходимостью замены полностью устаревшего основного контроллера домена, дальнейший апгрейд которого больше не имеет смысла, на новый и более соответствующий современным требованиям. Бывают ситуации и хуже – контроллер домена просто-напросто приходит в негодность из-за поломок на физическом уровне, а резервные копии и образы устарели, или потерялись
В принципе, описание процедуры замены одного контроллера домена на другой можно найти на разных форумах, но информация даётся отрывками и, как правило, применима только к конкретной ситуации, однако фактического решения не даёт. Кроме того, даже вдоволь начитавшись форумов [1], баз знаний [2, 3] и прочих ресурсов на английском языке – я смог грамотно провести процедуру замены контроллера домена без ошибок только с третьего или четвёртого раза.
Таким образом, я хочу привести поэтапную инструкцию замены контроллера домена вне зависимости от того работоспособен он или нет. Единственная разница заключается в том, что при «упавшем» контроллере эта статья поможет только если вы заранее позаботились и развернули резервный контроллер домена.

Подготовка серверов к повышению/понижению роли

Сама процедура создания резервного контроллера домена элементарна – мы просто запускаем на любом сервере сети мастер dcpromo. При помощи мастера dcpromo создаём контроллер домена в существующем домене. В результате проделанных манипуляций мы получаем развернутую службу каталогов AD на нашем дополнительном сервере (я буду называть его pserver, а основной контроллер — dcserver).
Дальше, если dcpromo сам не предложил – запускаем установку DNS сервера. Никаких настроек изменять не надо, зону создавать также не надо – она хранится в AD, и все записи автоматически реплицируются на резервный контроллер. Внимание – основная зона в DNS появится только после репликации, для ускорения которой сервер можно перезагрузить. В настройках TCP/IP сетевой карты резервного контроллера домена адресом первичного DNS сервера должен быть указан ip-адрес основного контроллер домена.
Теперь можно легко проверить работоспособность резервного контроллера домена pserver. Мы можем создать пользователя домена как на основном так и на резервном контроллере домена. Сразу после создания он появляется на дублирующем сервере, но где-то в течении минуты (пока происходит репликация) – он показан как отключенный, после чего начинает отображаться одинаково на обоих контроллерах.
На первый взгляд все действия по созданию исправной схемы взаимодействия нескольких контроллеров домена выполнены, и теперь, в случае выхода из строя «основного» контроллера домена, «резервные» контроллеры будут автоматически выполнять его функции. Однако, хотя разница между «основным» и «резервным» контроллерами домена чисто номинальная, «основной» контроллер домена имеет ряд особенностей (роли FSMO), о которых не стоит забывать. Таким образом, вышеприведенных операций для нормального функционирования службы каталогов при отказе «основного» контроллера домена не достаточно, и действия, которые надо произвести для грамотной передачи/захвата роли основного контроллера домена будут описаны ниже.

Немного теории

Нужно знать, что контроллеры домена Active Directory исполняют несколько видов ролей. Эти роли называются FSMO (Flexible single-master operations):
— Schema Master (Хозяин схемы) – роль отвечает за возможность изменения схемы – например разворачивания Exchange server или ISA server. Если владелец роли будет недоступен – схему существующего домена вы изменить не сможете;
— Domain Naming Master (Хозяин операции именования доменов) – роль необходима в том случае, если в вашем доменном лесу есть несколько доменов или поддоменов. Без неё не получится создавать и удалять домены в едином доменном лесу;
— Relative ID Master (Хозяин относительных идентификаторов) – отвечает за создание уникального ID для каждого объекта AD;
— Primary Domain Controller Emulator (Эмулятор основного контроллера домена) – именно он отвечает за работу с учётными записями пользователей и политику безопасности. Отсутствие связи с ним позволяет входить на рабочие станции со старым паролем, который нельзя сменить, если контроллер домена «упал»;
— Infrastructure Master (Хозяин Инфраструктуры) – роль отвечает за передачу информации об объектах AD прочим контроллерам домена в рамках всего леса.
Об этих ролях достаточно подробно написано во многих базах знаний, но основную роль практически всегда забывают – это роль Global Catalog (Глобального Каталога). По факту этот каталог просто запускает LDAP сервис на порту 3268, но именно его недоступность не позволит доменным пользователям входить в систему. Что примечательно – роль глобального каталога могут иметь все контроллеры домена одновременно.

Фактически можно сделать вывод – если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены — то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить. Кроме того, мне несколько раз попадались организации, работающие больше года вообще без контроллера домена, но в доменной инфраструктуре. То есть все права были розданы давно, при работающем контроллере домена, и не нуждались в изменении, пароли пользователи себе не меняли и спокойно работали.

Определение текущих владельцев ролей fsmo.

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

dsquery server –hasfsmo schema
dsquery server – hasfsmo name
dsquery server – hasfsmo rid
dsquery server – hasfsmo pdc
dsquery server – hasfsmo infr
dsquery server –forest -isgc

Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (рис.1). В нашем случае владелец всех ролей – основной контроллер домена dcserver.

Добровольная передача ролей fsmo при помощи консолей Active Directory.

Вся информация, необходимая для передачи роли основного контроллера домена у нас есть. Приступаем: для начала нужно убедиться в том, что наша учётная запись входит в группы «Администраторы домена», «Администраторы схемы» и «Администраторы предприятия», а затем приступить к традиционному методу передачи ролей fsmo – управлением доменом через консоли Active Directory.

Для передачи роли “хозяина именования домена” выполняем следующие шаги:
— открываем «Active Directory Домены и Доверие» на том контроллере домена, с которого мы хотим передать роль. Если мы работаем с AD на том контроллере домена, которому мы хотим передать роль, то следующий пункт пропускаем;
— щёлкаем правой кнопкой мыши на значке Active Directory — домены и доверие и выбираем команду Подключение к контроллеру домена. Выбираем тот контроллер домена, которому хотим передать роль;
— щелкаем правой кнопкой мыши компонент Active Directory — домены и доверие и выбираем команду Хозяева операций;
— в диалоговом окне Изменение хозяина операций нажимаем кнопку Изменить (рис. 2).
— после утвердительного ответа на всплывающий запрос получаем успешно переданную роль.

Аналогичным образом, при помощи консоли «Active Directory — пользователи и компьютеры» можно передать роли «хозяин RID», «основной контроллер домена» и «хозяин инфраструктуры».

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

regsvr32 schmmgmt.dll

Далее в консоль mmc необходимо добавить оснастку «Схема Active Directory», в которой, аналогично предыдущим пунктам, можно изменить владельца роли.

После того как все роли переданы остаётся разобраться с оставшейся опцией – хранителем глобального каталога. Заходим в Active Directory: «Сайты и Службы», сайт по умолчанию, сервера, находим контроллер домена, ставший основным, и в свойствах его NTDS settings ставим галочку напротив global catalog. (рис. 3)

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

Добровольная передача ролей fsmo при помощи консолей ntdsutil.exe.

На случай, если передача ролей fsmo при помощи консолей AD не удалась, Microsoft создал очень удобную утилиту – ntdsutil.exe – программа обслуживания каталога Active Directory. Этот инструмент позволяет выполнять чрезвычайно полезные действия – вплоть до восстановления всей базы данных AD из резервной копии, которую эта утилита сама создала во время последнего изменения в AD. Со всеми её возможностями можно ознакомиться в базе знаний Microsoft (Код статьи: 255504). В данном случае мы говорим о том, что утилита ntdsutil.exe позволяет как передавать роли, так и «отбирать» их.
Если мы хотим передать роль от существующего «основного» контроллера домена к «резервному» – мы заходим в систему на «основной» контроллер и начинаем передавать роли (команда transfer).
Если у нас по каким-то причинам отсутствует основной контролер домена, или мы не можем войти под административной учетной записью – мы входим в систему на резервный контроллер домена и начинаем «отбирать» роли (команда seize).

Итак первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:

ntdsutil.exe
roles
connections
connect to server имя_сервера (того кому хотим отдать роль)
q

Если выскакивают ошибки – нужно проверить связь с тем контроллером домена, к которому мы пытаемся подключиться. Если ошибок нет – значит мы успешно подключились к указанному контроллеру домена с правами того пользователя, от имени которого вводим команды.
Полный список команд доступен после запроса fsmo maintenance стандартным знаком ? . Пришла пора передавать роли. Я сходу, не задумываясь, решил передавать роли в том порядке, в каком они указаны в инструкции к ntdsutil и пришёл к тому, что не смог передать роль хозяина инфраструктуры. Мне, в ответ на запрос о передаче роли, возвращалась ошибка: «невозможно связаться с текущим владельцем роли fsmo». Я долго искал информацию в сети и обнаружил, что большинство людей дошедших до этапа передачи ролей сталкиваются с этой ошибкой. Часть из них пытается отобрать эту роль принудительно (не выходит), часть оставляет всё как есть – и благополучно живёт без этой роли.
Я же путём проб и ошибок выяснил, что при передаче ролей в данном порядке гарантируется корректное завершение всех шагов:
— хозяин идентификаторов;
— хозяин схемы;
— хозяин именования;
— хозяин инфраструктуры;
— контроллер домена;

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance), и можем начать передавать роли :
— transfer domain naming master
— transfer infrastructure master
— transfer rid master
— transfer schema master
— transfer pdc master

После выполнения каждой команды должен выходить запрос о том – действительно ли мы хотим передать указанную роль указанному серверу. Результат удачного выполнения команды показан на рис.4.

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

Принудительное присваивание ролей fsmo при помощи ntdsutil.exe.

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

seize domain naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc

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

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

Самое главное, о чём не следует забывать – новый основной контроллер домена сам себе настройки TCP/IP не исправит: ему адресом первичного DNS сервера теперь желательно (а если старый контроллер домена + DNS сервер будут отсутствовать, то обязательно) указать 127.0.0.1 .
При этом если у вас в сети есть DHCP сервер, то нужно заставить его выдавать адресом первичного DNS сервера ip вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же ip что был у старого.

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

Самым распространённым предупреждением, после передачи ролей fsmo, является сообщение о том, что «msdtc не может корректно обработать произошедшее повышение/понижение роли контроллера домена».
Исправляется просто: в меню «Администрирование» находим «Службы
компонентов». Там раскрываем «Службы компонентов», «Компьютеры», открываем свойства раздела «Мой компьютер», ищем там «MS DTC» и жмем там «Настройки безопасности». Там разрешаем «Доступ к сети DTC» и давим ОК. Служба будет перезапущена и предупреждение исчезнет.

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

dcdiag

Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами successfully passed. Если у вас выходит failed (чаще всего это тесты connection или systemlog) то ошибку можно попробовать вылечить в автоматическом режиме:

dcdiag /v /fix

Как правило, все ошибки, связанные с DNS должны пропасть. Если нет – пользуемся утилитой проверки состояния всех сетевых служб:

netdiag

И её полезным инструментом устранения ошибок:

netdiag /v /fix

Если и после этого остаются ошибки связанные с DNS – проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:

dcdiag /test:dns

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

Указанные ресурсы:

[1] http://technet.microsoft.com
[2] http://www.petri.co.il/
[3] http://support.microsoft.com