Перенос active directory windows server 2003 2008 r2 - Доктор Windows

Всем привет!
Как Вы все знаете, поддержка Windows Server 2003/R2 стремится к
официальной дате завершения
. Спланировать апгрейд данных ОС до новых версий ещё возможно и данная статья частично в этом Вам поможет. Рассматривается добавление новых контроллеров домена на базе 2008 R2 в текущую инфраструктуру 2003 R2
(x86)

Перед любым изменением топологии/конфигурации требуется:

Для подготовки исп-ся ADPREP.exe , который поставляется вместе с дистрибутивом/образом ОС
(D:Supportadprepadprep32.exe – для 32-разрядных ОС,
adprep.exe – для 64-разрядных)

и включает 4 этапа:

подготовка леса (/forestPrep)
подготовка домена (/domainPrep)
подготовка групповых политик
(/domainprep /gpprep), подготовка к Read-Only DC (/rodcPrep)

Поехали!

1. Подключитесь к Schema Owner (кто? >> netdom query fsmo)
2. Запустите adprep32.exe /forestprep для начала подготовки леса

3. Нажмите C , затем Enter и дождитесь завершения расширения схемы

4. Результат

5. На Infrastructure owner запустить
adprep.exe /domainprep

6. В этом же окне запустить
adprep.exe /domainprep /gpprep

7. Для возможности добавления RODC-контроллеров необходимо провести запуск
adprep /rodcprep , иначе на этапе добавления новых КД будет выдаваться предупреждение о недоступности исп-ся RODC

8. Добавьте новые КД , проверьте состояние репликации и результаты диагностики.

Начиная с Windows Server 2012, подобная процедура заметно упростилась, а именно:

adprep запускается автоматически на этапе добавления КД 2012/2012 R2 (adprep /rodcprep, ../forestprep, …/domainprep)
adprep автоматически опр-ет держателей FSMO и запускается удаленно. итого: процедура проходит только в рамках будущего КД
adprep /domainprep /gpprep автоматически НЕ выполняется =
запустить самостоятельно
adprep только для x64 и ОС от Windows Server 2008 и позже. Запустить Adprep (2012) в среде 2003 не получится (как правило, этого не требуется)

Смежные статьи:

Перенос FSMO на примере 2003 и 2008 R2
Понижаем КД, удаляем DNS, повышаем функ.уровень (2003
<> 2008R2)
Миграция
центра сертификации (2003, 2008R2)

Источник

Прочитано:
4 727

Для того, чтобы мигрировать контроллер домена на базе Windows Server 2003 R2 Enterpise на систему Windows Server 2008 R2 Enterprise и пойдет речь в данной заметке.

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

Мне понадобится:

Контроллер домена развернутый ранее (Windows Server 2003 R2)

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

И так у меня есть существующий домен, polygon.local. Сетевые настройки точно такие же, как и в моей предыдущей заметке, которая по сути и является основной, а текущая ее продолжением.

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

Проверим на dc1.polygon.local – кто же является обладателем всех FSMO—ролей.

FSMO – роли бывают:

Роль PDC Emulator – консоль Active Directory – Users and Computers

Роль RID Master – консоль Active Directory – Users and Computers (Хозяин относительных идентификаторов)

Роль Infrastructure Master – консоль Active Directory – консоль Users and Computers (Хозяин инфраструктуры )

Роль Domain Naming Master – консоль Active Directory – Domains and Trusts (Хозяин именования доменов)

Роль Schema Master (Хозяин схемы) — специальная консоль. Которая содержит оснастку Active Directory Schema (Схема Active Directory)

Win + R → cmd.exe → вызываем утилиту netdom (но есть одно, но данная утилита по умолчанию не установлена в системе, для ее установки потребуется пакет Support Tools, обычно он идет в комплекте с дистрибутивом, в данный пакет также входять такие необходимые подготовительные утилиты, как:

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

C:Documents and SettingsAdministrator>netdom query fsmo

Schema owner dc1.polygon.local

Domain role owner dc1.polygon.local

PDC role dc1.polygon.local

RID pool manager dc1.polygon.local

Infrastructure owner dc1.polygon.local

The command completed successfully.

, как видно все FSMO роли принадлежат контроллеру домена dc1.

Далее установленную систему Windows Server 2008 R2 Enterprise с именем dc2 вводим в домен, предварительно предопределив статический IP адрес, к примеру: 10.9.9.2

dc2: Win + R → cmd.exe →

C:UsersAdministrator>netsh interface show interface

Admin State State Type Interface Name

————————————————————————-

Enabled Connected Dedicated Local Area Connection

C:UsersAdministrator>netsh interface ipv4 set address «Local Area Connection» static 10.9.9.2 255.255.255.0

C:UsersAdministrator>netsh interface ipv4 set dns name=»Local Area Connection» static 10.9.9.1 primary

C:UsersAdministrator>netdom join %computername% /domain:polygon.local /userd:polygon.localekzorchik /passwordd:*

Type the password associated with the domain user:

вводим — 712mbddr@

The computer needs to be restarted in order to complete the operation.

The command completed successfully.

Перезагружаем систему, чтобы применились изменения и система стала полноправным членом домена: C:UsersAdministrator>shutdown /r /t 3

Следующий этап: — это обновление домена и леса, для этого нужно из установочного диска Windows Server 2008 R2 подмонтированного на логический диск D: — скопировать полностью папку («adrep”) и переместить ее на домен контроллер dc1:

Win + R → cmd.exe

C:UsersAdministrator>hostname

DC2

C:UsersAdministrator>mkdir \dc1c$support

C:UsersAdministrator>copy d:supportadprep \dc1c$support
44 file(s) copied.

На заметку: Если система dc1 у Вас 32—х битная то запускать следует исполняемый файл adprep32.exe, а если 64-х битная то adprep.exe

У меня dc1 – 64-х битный, поэтому и запускаем файл adprep.exe с ключами forestprep (как держатель мастер схемы) и после domainprep (как держателе инфраструктуры). Порой в небольшой организации (к примеру в которой я сейчас работаю) все эти роли обычно имеют место быть на одном из том же контроллере домена:

На заметку: при подготовке леса необходимо войти в мастер схемы в качестве члена группы Администраторов для схемы, предприятия и домена.

C:Documents and SettingsAdministrator>cd /d c:

C:>hostname

dc1

C:>cd support

C:support>adprep.exe /forestprep

если ничего не происходит, значит делаем по другому, а именно монтируем iso Образ дистрибутива Windows Server 2008 R2 к системе Windows Server 2003 R2 на логический диск D:

и через вызов командной строки: Win + R → cmd.exe

C:>d:supportadprepadprep.exe /forestprep

ADPREP WARNING:

Before running adprep, all Windows 2000 Active Directory Domain Controllers in t

he forest should be upgraded to Windows 2000 Service Pack 4 (SP4) or later.

[User Action]

If ALL your existing Windows 2000 Active Directory Domain Controllers meet this

requirement, type C and then press ENTER to continue. Otherwise, type any other

key and press ENTER to quit.

C — на предупреждение вводим «C” и нажимаем Enter, чтобы начать подготовку леса. (процесс отрабатывает довольно долго)

Opened Connection to DC1

SSPI Bind succeeded

Current Schema Version is 31

Upgrading schema to version 47

Connecting to «DC1»

Logging in as current user using SSPI

Importing directory from file «C:WINDOWSsystem32sch32.ldf»

Loading entries……………….

18 entries modified successfully.

И много всякой успешной информации которую я не буду здесь приводить.

……………………………………………………………………..

……

Adprep successfully updated the forest-wide information.

Результирующим завершения команды должна быть надпись: Adprep successfully updated the forest-wide information.

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

C:>d:supportadprepadprep.exe /domainprep /gpprep

Running domainprep …

Adprep detected that the domain is not in native mode

[Status/Consequence]

Adprep has stopped without making changes.

[User Action]

Configure the domain to run in native mode and re-run domainprep

поправить данное не выполнение команды можно так:

Start – Control Panel – Administrative Tools – Active Directory Users and Computers

выделяем домен polygon.local и через правый клик изменяем режим работы домена:

polygon.local – Raise Domain Functional Level

Привести к виду: выбрав вместо Windows 2000 native → Windows Server 2003 и нажать Raise (Изменить)

и после подтвердить нажав OK

(Перевод: Это изменение затрагивает весь домен. После повышения режима работы домена его невозможно отменить.)

После будет информативное окно, что:

(Перевод: Режим работы успешно повышен. Новый режим работы будет реплицирован на каждый контроллер домена в домене. Время, которое на это потребуется, зависит от топологии репликации.)

После этого снова запускаем командную строку и набираем:

C:>d:supportadprepadprep.exe /domainprep /gpprep

Adprep successfully updated the domain-wide information.

Adprep successfully updated the Group Policy Object (GPO) information.

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

C:>d:supportadprepadprep.exe /rodcprep

Вот основные шаги по обновления схемы завершены, приступим к повышению роли нового сервера (dc2) до контроллера домена.

На сервере Dc2: логинимся под доменной учетной запись обладающей правами «Domain Adminis”, в моем случае это учетная запись ekzorchik и вызываем утилиту dcpromo: Win +R > dcpromo

ставим галочку: Use advanced mode installation – Next – Next – Existing forest – Add a domain controller to an existing domain (добавить домен контроллер в существующий домен) — Next – проверяем настройки аутентификации: (должно быть так как указано на скриншоте ниже)

и нажимаем Next – выбираем домен polygon.local (forest root domain) – Next – выбираем текущий сайт (у меня он один) Default-First-Site-Name – Next – активируем установку (Ставим галки) следующих опций на вводимом в эксплуатацию контроллере домена, таких как:

DNS Server

Global catalog

Далее соглашаемся Yes – отмечаем пункт Replicate data over the network from an existing domain controller – Next – отмечаем пункт Use this specific and appropriate domain controller (выделяем dc1.polygon.local) – Next – местонахождение каталогов NTDS (Database), NTDS (Log), SYSVOL оставляем дефолтным — Next – задаем пароль для Административной учетной записи на случай восстановления: — я указываю 712mbddr@ — Next – Next – начнется процесс преобразования

и ставим в этом процессе галочку «Reboot on completion” — перезагрузить систему (dc2) когда процесс становления контроллера домена завершится успешно, дабы активировать изменения.

Теперь у меня есть два контроллера домена, работающих одновременно.

Дальше нужно передать роли FSMO с dc1 на dc2, сделать это можно двумя различными способами:

Первый способ: через графический интерфейс

Второй способ: через консольную утилиту ntdsutil.exe

У меня уже есть совмещенная заметка где описаны оба способа: (см заметку: http://www.ekzorchik.ru/2012/09/server-2008-fsmo-roles-move/)

Если же Вам нужно удалить неисправный контроллер домена (см. заметку:

http://www.ekzorchik.ru/2012/08/server2008-ntdsutil-dc2-delete/)

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

Источник

Главная » Прочие » Перенос контролера домена windows server 2003 на windows server 2008

На заметку:

Содержание

Исходные данные и техзадание
Подготовительные работы
Обновление схемы леса и домена
Передача ролей 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:supportadprep (X: — буква диска DVD-ROM). Если windows Server 2003 у вас 32-х битная, следует запускать запускать adprep32.exe, в случае 64-х битной — adprep.exe.

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

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

X:supportadprep>adprep32.exe /forestprep

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

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

Adprep successfully updated the forest-wide information.

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

X:supportadprep>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.

После этого, в логах 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: TESTCOMPANYAdministrator
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 AUTHORITYANONYMOUS 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.

Миграция роли Active Directory и перенос контроллера домена на другой сервер

Источник

Имеется: Домен с единственным КД на Windows Server 2003 R2 32bit, работающем на физическом сервере. Поскольку данный КД является единственным, то он соответственно выполняет все 5 ролей хозяина операций. Свежеустановленная виртуальная машина с Windows Server 2008 R2.
Необходимо: Перенести роль КД с 2003 на 2008, сервер с 2003 оставить в работе с сохранением всех остальных ролей, кроме КД. Повысить режим работы домена до 2008 R2.

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

Для удобства исходный физический сервер был также предварительно перенесён в виртуалку при помощи disk2vhd, что в принципе совсем не обязательно и было сделано лишь для излишней перестраховки. Однако, в случае переноса необходимо проверить точно ли всё с ним хорошо и нормально ли удался перенос: как минимум выполнить полную проверку всех дисков и запустить dcdiag. В моём случае dcdiag после переноса ругался на systemlog, в котором были события об ошибках от ntfs (особенности моего конкретного переноса диска в виртуалку, ибо он был частичным, вообще такого быть не должно). Исправление ситуации и очистка лога всё вылечили.

Подготовка:
1. Подключаем 2008 к центру обновлений и накатываем на него все доступные обновления, перезагружаемся столько раз, сколько просят
2. Создаём снимки всех виртуальных машин. В принципе делать их можно часто, хоть перед каждой операцией Но я собственно ограничился снимками на ключевых этапах

На исходном КД 2003:
3. Делаем общую проверку dcdiag, убеждаемся в отсутствии ошибок

4. Делаем тест DNS и убеждаемся что всё (или почти всё) хорошо. Он может быть довольно долгим.
dcdiag /test:dns /s:<имя сервера>
В моём случае, к примеру, поскольку интернетов на сервере не было, не прошёл тест Forw, что в принципе не смертельно и может быть проигнорировано.

5. Запускаем тест dnslint и смотрим потом html-файлик, чтобы там не было ошибок

dnslint /ad /s <ip сервера> /v

6. Проверим на всякий случай кто является хозяином операций, должен быть исходный сервер во всех 5 позициях:
netdom query /domain:<имя домена> fsmo

На новом КД 2008:
7. Вводим в домен новый сервер 2008 в качестве рядового сервера

Подготовка схемы для 2008R2 на старом КД 2003:

Подробно тут
8. Сменить режим работы домена на native, если он таковым не является

9. Запустить adprep и дождаться пока отработает:
adprep32 /forestprep

adprep32 /domainprep /gpprep
Здесь есть один момент. Майкрософт пишет дословно следующее:

Если нужно установить контроллер домена только для чтения в любом из доменов леса, введите следующую команду, а затем нажмите клавишу ВВОД:

adprep /rodcprep

т.е. вроде как ЕСЛИ НУЖНО, то бишь не обязательно. Однако лучше эту операцию всё же сделать в любом случае, т.к. после миграции dcdiag будет выдавать ошибку. Майкрософт пишуть тут что это всё как бы пофиг и можно забить, но тем не менее. А вдруг завтра приспичит парочку RODC замутить? %)

Поднимаем новый КД на 2008:

10. Запуск dcpromo, далее всё штатно по визарду. Воткнуть галки DNS сервер и глобальный каталог.

После успешного окончания процесса на старом 2003:

11. Посмотреть список разделов каталога

dnscmd /EnumDirectoryPartitions

12. Выполнить для каждого из разделов, полученных выше
dnscmd /EnlistDirectoryPartition <FQDN of partition>.
Командную строку запускать принудительно с правами админа!!! блять! блять! блять! Под юзером оно валится с ошибкой, естественно ))

Переносим DNS-сервер
На исходном 2003:

13. Погасить днс сервер
net stop «DNS-сервер» (трудности перевода, блеать!)

14. Экспортировать его параметры из реестра

reg export HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDNSParameters %Windir%System32DNSDns-Service.REG

reg export «HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDNS Server» %Windir%System32DNSDns-Software.REG
15. Скопировать на 2008 папку %windir%system32dns

16. Запустить днс сервер
net start «DNS-сервер» (трудности перевода, блеать!)

На 2008:

17. Погасить днс сервер. Там даже трудности перевода не помогли, загасил через гуёвую оснастку

18. Импортировать оба рег-файла из п.14

19. Скопировать все файлы из старого каталога DNS в каталог %windir%System32DNS на 2008. Я на всякий случай переместил предварительно всё содержимое этой папки на 2008 в другое место

20. Запустить днс сервер. Работать оно начинает не сразу. Сразу после старта службы зона отображается в оснастке с ошибкой, однако после весьма задумчивого выполнения п.21 у меня оно ожило: зона появилась и всё заработало

21. Убедиться что зона днс нормально отреплицировалась на новый сервер
DNSConvergeCheck.cmd <ip старого 2003> <ip нового 2008> <FQDN имя домена>

После переноса днс и проверки работоспособности оного:

22. Поправить настройки днс в сетевом подключении на старом и новом КД, прописав в качестве первичного днс новый КД.

23. Передать все 5 ролей хозяина операций новому КД. Это можно сделать либо через консольную утилю ntdsutil (подробнее тут), либо через ГУЙ (об этом, например, тут)
24. Проверить нормально ли всё функционирует. К примеру как советуют здесь

25. Если с новым КД всё нормально, то со старого роль КД теперь можно спокойно удалять. У меня роль удалилась со второго раза, подозреваю первый раз свалилось из-за того, что на исходном сервере не сменил в настройках ip dns сервера на новый.

26. По желанию. Повысить режим работы домена до 2008R2

з.ы. Теоретически не вижу проблем сделать всё также при наличии более чем одного КД.

Источник

Время прочтения
9 мин

Просмотры 24K

Я не умею писать вводное слово, потому сразу к делу.

Краткое описание методики миграции:
Миграция происходит side-by-side, те необходимо разворачивание параллельной инфраструктуры AD DSExchange и сопутствующих сервисов. Этапы:
1. Разворачивание целевой инфраструктуры.
2. Двустороннее доверие между доменами и установка ADMT.
3. Синхронизация глобальных адресных книг и настройка сосуществования почтовых организаций.
4. Собственно миграция, которая состоит из миграции почты, пользователей и компьютеров.

Подробнее под катом.

Для миграции пользователей и компьютеров — ADMT 3.2, для миграции почтовых ящиков — powershell, для синхронизации глобальной адресной книги — FIM, для синхронизации freebusy информации — Inter-Organization Replication Tool. Таким образом, все инструменты используемые при миграции являются бесплатными. Я производил миграции порядка 600 пользователей с помощью данных инструментов и каких-либо существенных проблем не встретил. Решение масштабируется без каких-либо проблем.

Успех миграции на 50% (минимум) зависит от стадии планирования, на этом этапе Вам необходимо продумать все заранее.
Больше всего внимания следует уделить сосуществованию почтовых организаций, так как этот сервис обычно очень критичен для организации и проблемы с этим сервисом крайне быстро «всплывают».

1. Пространство имен.
Вам нужно продумать стратегию пересылки почты между почтовыми организациями на время сосуществования почтовых организаций. Один из вариантов — маршрутизация всей почты через Exchange 2010 и relay (переадрессация) почты для «старой» почтовой организации. Для этого Вам необходимо добавить почтовый домен «старой» почтовой организации в «accepted domains» «новой» почтовой организации и сконфигурировать этот домен как «internal relay», после чего сконфигурировать новый Exchange Сервер на пересылку почты на старый Exchange (фактически указать куда пересылать, тк новый Exchange ничего не знает про старый). В этом случае почтовый сервер Exchange 2010 при получении письма для пользователя из этого домена будет искать у себя пользователя с данным адресом — в случае отсутствия данного пользователя письмо будет перенаправленно на почтовый сервер «старой» почтовой организации.

2. Публикация новой почтовой организации в старом домене (SCP запись) и запрет доступа к ней не мигрированным пользователям.
В командной строке Exchange новой почтовой организации необходимо выполнить команду «Export-AutoDiscoverConfig -TargetForestDomainController домен_контроллер_целевого_домена (те старого) -MultipleExchangeDeployments $true -TargetForestCredential $targetcredentials». Данная команда создает в старом домене SCP запись новой почтовой организации. Клиенты Outlook найдут её раньше чем SCP запись старой почтовой организации, тк она ближе к корню домена, для того чтоб не мигрированные пользователи старого домена не могли считать информацию с этой SCP записи необходимо создать группу безопасности, добавить туда мигрированных пользователей (и добавлять по мере миграции) и разрешить им доступ на чтение к данной SCP и убрать разрешение на чтение данной SCP у группы «Authenticated Users».
Troubleshooting:: Правой кнопкой мыши с зажатым ctrl на значок Outlook в панели задач и выбрать пункт «Test E-Mail Autoconfiguration». Так же можно включить дополнительное логгирование в Outlook.

3. Синхронизация GAL’ов и freebusy информации.
Для синхронизации GAL’ов будет использоваться FIM 2010 R2. Для синхронизации контактов необходимо убрать из всех организацицонных единиц контакты которые не нужно синхронизировать (можно, конечно, тоже самое сделать фильтрами FIM, но это, во-первых, сложнее, во-вторых, хуже).
Для синхронизации freebusy информации будет использоваться Inter-Organization Replication Tool (подробнее тут).

4. Стратегия миграции почты.
Вернемся к пространству имен, если вы мигрируете из домена xxx.company.com в домен company.com, Вам необходимо будет мигрировать через промежуточный домен (только почту) например firm.com. Это необходимо по той причине что Exchange сервер «думает» что это дочерний домен и будет возвращать ошибку даже не смотря на то что все сделанно правильно.
В общем и целом у Вас 2 варианта:
— Вначале Prepare-MoveRequest потом ADMT (порядок: Prepare-MoveRequest, ADMT, New-MoveRequest)
— Вначале ADMT потом Prepare-MoveRequest (порядок: ADMT, Enable-MailUser, Prepare-MoveRequest, New-MoveRequest)
Первый сценарий предпочтительей в случае если Вы мигрируете в новый доменлес и в нем нет копий этих пользователей. Подробнее дальше по тексту.

5. Стратегия миграции пользователей.
Миграция пользователей осуществляется после миграции почты (на самом деле это не совсем так, пользователь может быть членом нового доменалеса, а почту использовать из старого доменалеса. Просто этот вариант мне кажется наиболее логичным). Процесс очень прост и интуитивен. Все операции проделываются с помощью ADMT. Единственные советы которые тут можно дать — заранее придумать плансписки мигрирующих по дням и согласовать с бизнесом.

6. Стратегия миграции компьютеров.
Миграция компьютеров осуществляется в последнюю очередь, так как в этом случае мигрируются все профили пользователей которые когда-либо работали на комьютере. Поясню, если Вы мигрируете компьютер на котором работают 2 пользователя и только один из них мигрирован в новый доменлес, то после миграции компьютера «старый» профиль будет доступен (те скопирован в «новый» профиль, фактически) только этому пользователю. У второго пользователя будет пустой профиль.

Кратко (относительно) освещу каждый пункт кроме первого.
Доверие между доменами:
Данный этап важен не только потому что необходим для непосредственной миграции, но и потому что если Вы мигрируете количество пользователей отличное от 100 процесс миграции займет больше чем одни выходные и Вам необходимо чтобы пользователи из нового домена имели доступ к ресурсам и сервисам из старого домена. Данный момент довольно подробно описан в интернете и 99% тем на форумах и постов в блогах ссылаются на вот эту статью. Но карантин SID’ов запрещает администраторам из доверенного домена управлять доверяемым доменом, а не открывает доступ к ресурсам из старого домена. Для этого необходимо включить SID History для траста (возможно я тугой, но я потратил массу времени пока понял что карантин SID’ов делает не то что везде описано). Подробнее тут.
Для удобства: SID History — Netdom trust TrustingDomainName /domain:TrustedDomainName /enablesidhistory:Yes /userd:domainadministratorAcct /passwordd:domainadminpwd и карантин SID’ов — Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /userd:domainadministratorAcct /passwordd:domainadminpwd
Установка ADMT (на домен контроллер в новом домене) происходит путем нажимания на кнопку далее некое количество раз (на SQL Express 2008 оно не встало, на 2005 легко). Если необходим экспорт паролей нужно ставить Password Export Service на PDC Emulator старого домена (после установки нужно запустить службу или переставить её на авто запуск, по умолчанию она стоит в ручном режиме и выключена).
Кроме этого необходимо исправить ключ реестра на контроллере домена с ролью PDC в новом домене. HKLMSystemCurrentControlSetServicesNetlogonParametersAllowNT4Crypto для поддержки миграции рабочих станций под управлением ОС Windows XP, Vista (до SP1) и 2000. Гуглим по запросу AllowNT4Crypto.

3.Синхронизация глобальных адресных книг
Для этого нам потребуется SQL сервер 1 штука, FIM Synchronization Service 1 штука, консоль Exchange 2010 на сервере FIM 1 штука (необходима для павершела). Процесс установки сводится к нажиманию кнопки далее и указания вполне очевидных параметров (адрес SQL сервера и тд). Единственное — советую сделать отдельный сервисный аккаунт для FIM Synchronization Service.
Настройка FIM’а производится через графический интерфейс.
Вначале необходимо включить provisioning. Закладка Tools > Options > «Enable Provioning Rules Extension».
Далее необходимо создать 2 менеджмент агента, один будет синхронизировать контакты из старого домена в новый, а второй наоборот.
По умолчанию GALSync менеджмент агент не синхронизирует следующих пользователей: пользователей скрытых из глобальной адресной книги или с не заполненым параметром «legacyExchangeDN» или с не заполнеными параметрами (одновременно) «msExchangeHomeServerName» и «targetAddress» или в случае когда не заполнен параметр «proxyAddresses», кроме того, если это «Mailbox Plan», «Arbitration Mailbox» или «Discovery Mailbox».
Приступим к созданию менеджмент агентов для синхронизации адресных книг.
Необходимо создать 2 менеджмент агента (создаются идентично), на первом экране необходимо выбрать «Active Directory global address list (GAL)» и дать название агенту.
На следующем экране необходимо указать лесдомен и учетные данные для подключения к нему.
На следующем экране необходимо выбрать организационные единицы из которых FIM будет забирать данные и контейнер куда он будет складывать crossforest контакты (кнопка «Containers»).
Следующий экран самый интересный ;). Необходимо указать smtp суффиксы и самое главное, указать FIM’у куда класть контакты и откуда брать контакты. Для указания организационной единицы где будут создаваться контакты необходимо нажать кнопку «Target», Кнопка «Source» позволит Вам настроить организационные единицы содержащие пользователей которых необходимо синхронизировать. “Support cross-forest delegation (Exchange 2007 or 2010 only)” будет создавать параметры необходимые для делегации полномочий на Mail-enabled user objects (например чтение календарей).
Далее необходимо много раз нажать на кнопку далее На последнем экране необходимо указать версию сервера эксчендж (для нового домена) и адрес по которому расположен повершел Exchange’а 2010 (http://exchangeFQDN/powershell).
При настройке агента для старого домена Вы столкнетесь с проблемами Дело в том что в Active Directory просто нет некоторых параметров которые FIM по умолчанию ищет там, и в определенный момент Вы не сможете продолжить настройку агента из-за ошибки связанной с отсутствием параметра «msExchRecipientTypeDetails». Для исправления данного печального факта Вам необходимо на шаге «Configure Connection Filter» выбрать сущность user и удалить все упоминания «msExchRecipientTypeDetails». Но это только начало, на шаге «Configure Join and Projection Rules» необходимо выбрать параметр «Object Type: User» и в св-вах данной сущности найти и удалить «msExchRecipientTypeDetails», а для сущности «Object Type: contact» удалить «msExchRecipientDisplayType» и «msExchRecipientTypeDetails». Дальнейшая настройка идентична (кроме указания адреса повершела, этого делать не нужно). Ну или запустить в старом домене инсталлер Exchange сервера 2010 с ключем /PrepareAD
Далее необходимо запускать агенты каждый раз когда Вам необходимо синхронизировать глобальные адресные книги или настроить расписание. Очередность запуска агентов не принципиальна, вначале необходимо запустить полный импорт агентов, потом полную синхронизацию, потом экспорт. После чего необходимо сделать подтверждающий импорт, это необходимо чтобы FIM убедился что все изменения успешно внесены в целевые системы.
Для траблшутинга необходимо использовать «Журнал Событий». Но помните что если у Вас возникает проблема с конкретным пользователемконтактом лучше изменить информацию в целевой системе чем пытаться средствами FIM’а решить проблему.

4. Миграция
Я не буду освещать миграцию пользователей и компьютеров поскольку она делается через графический интерфейс и интуитивно понятна. Я относительно подробно освещу процесс миграции почты.
Для начала я рассмотрю принцип по которому скрипт «Prepare-MoveRequest» находит контакты в целевом домене. Так как Вы уже создали почтовые контакты FIM’ом этот процесс необходимо понимать, иначе если что-то пойдет не так у Вас будет 2 одинаковых сущности в домене и Вы не будете понимать почему это так.
— Параметр «proxyAddresses» контакта совпадает с хотя бы одним из значений параметра «proxyAddresses» исходного контакта.
— Контакт является «Mail Enabled User’ом» и у него заполнены все поля в Active Directory которые должны быть заполнены у «Mail Enabled User’а».
— Скрипт должен быть запущен с параметрами «-UseLocalObject» и «-OverwriteLocalObject».
Если эти условия выполняются скрипт будет использовать уже созданные контакты. В целом для контактов созданных FIM’ом это всегда правда (я не встречал проблем).
Соответственно если Вы будет вначале запускать ADMT, а потом скрипт ваши действия должны быть приблизительно такими:
— Удалить мейл контакты созданные FIM’ом (тех пользователей которых Вы собираетесь мигрировать).
— Мигрировать пользователей с помощью ADMT.
— Сделать мигрированных пользователей «Mail Enabled User’ами» и задать им параметр «-ExternalEmailAddress» таким чтобы он совпадал с одним из адресов исходных пользователей.
Теперь у Вас так или иначе есть пользователи которые могут принять себе почтовый ящик старого домена. Далее приведу Вам повершелл скрипты которыми можно произвести миграцию почты используя CSV файл.
Запускайте повершел эксченджа и… cd «C:Program FilesMicrosoftExchange ServerV14Scripts»
$c = (Get-Credential ВашСтарыйДоменАдминистраторПочтовойОрганизации)
Import-Csv c:_.csv | ForEach {.Prepare-MoveRequest.ps1 -Verbose -Identity $_.Identity -UseLocalObject -OverWriteLocalObject -RemoteForestDomainController имя_домен_контроллера_старого_домена -RemoteForestCredential $c}
Import-Csv c:_.csv | ForEach {New-MoveRequest -Identity $_.Identity -Verbose -TargetDeliveryDomain вашновыйдомен.com -TargetDatabase имя_базы_данных -RemoteLegacy -RemoteCredential $c}, так же рекомендую параметры «-BadItemLimit» и «-AcceptLargeDataLoss». Еще хотелось бы обратить Ваше внимание на свитч «-RemoteLegacy», дело в том что кроме него есть свитч «-Remote» и если Вы случайно вставите его, а не правильный свитч, эксчендж будет просить от Вас MRSProxy сервер, те фактически сервер с ролью CAS Exchange 2010.
Я использовал CSV файлы которые состояли только из списка ФИО, в моем случае этого было достаточно, в вашем может быть не достаточно.
Помните что почтовый ящик, который мигрирует в почтовую базу, должен отвечать требованиям базы (те размер ящика, к примеру).

На данный момент я не могу вспомнить других подводных камней, если появятся интересные вопросы и ответы я дополню статью. Вопросы приветствуются.
пс. полезные ссылки:
— Очень хорошая статья про FIM и сосуществование почтовых организаций
— Подробная статья про миграцию почты
— Полезная статья про автодисковер, scp и сосуществование почтовых организаций.
— Статья которая пригодится для понимания работы «Мув реквестов» и еще одна.

Данный пост является набором псевдослучайных данных.
4c74356b41

Источник

Доброго времени суток коллеги. Это моя очередная статья, которая посвящена Microsoft University Online. В этой прошлой статье мы говори об обслуживании Active Directory Domain Services и об обслуживании Group Policy. Данная статья посвящена миграции Active Directory Domain Services c Microsoft Windows Server 2003 и Microsoft Windows Server 2003 R2 на Microsoft Windows Server 2008 или Microsoft Windows Server 2008 R2

Перед тем как приступать к самой миграции необходимо её спланировать. В планирование миграции входят такие важные моменты: определения исходных серверов, какие роли они будут выполнять, принадлежность к сайту. После того как выполнены следующие шаги необходимо выбрать тип миграции по которому и будет проходить миграция. Оптимальным вариантом для начала миграции является использование продукта компании Microsoft, который называется Microsoft Assessment and Planning (MAP) Toolkit. Данный продукт предназначен для анализа инфраструктуры, и предоставления рекомендационной документации. Полученная документация будет в дальнейшем весьма полезна, так как предоставит исчерпывающую информацию которая будет необходима при миграции.

Есть несколько типов миграции, с помощью которых можно провести миграцию с Microsoft Windows Server 2003 на Microsoft Windows Server 2008. Миграцию с Microsoft Windows Server 2003 на Microsoft Windows Server 2008 можно провести с помощью обновления операционной системы, но в этом случае есть целый ряд недостатков. Провести миграцию с Microsoft Windows Server 2003 на Microsoft Windows Server 2008 с помощью обновления операционной системы можно только в том случае если разрядность операционной системы, с которой мы обновляемся, совпадает с разрядностью операционной системы, на которую мы будет обновлять наш сервер. Проще говоря, нельзя перейти с Microsoft Windows Server 2003 x86 на Microsoft Windows Server 2008 x64 и соответственно с Microsoft Windows Server 2003 х64 на Microsoft Windows Server 2008 х86. Если же мы планируем проводить переход на Microsoft Windows Server 2008 R2, то исходный сервер должен быть обязательно под управление Microsoft Windows Server 2003 х64, так как Microsoft Windows Server 2008 R2 существует только в 64 битной редакции. Также если мы будем проводить обновление, то на компьютере останется всё программное обеспечение, установленное на него, и нет никаких гарантий, что все приложения будут полностью совместимы с новой операционной системой, что как следствие может привести к нестабильной работе, или потребует дополнительных работ для окончательного обновления компьютера. Если всё же для вас это приемлемый вариант миграции на новую операционную систему, то я могу вам посоветовать вначале, проверить совместимость всего программного обеспечения с новой операционной системой, а также провести тестовую миграцию в виртуальной или реальной среде, но ни в коем случае не на «боевой» инфраструктуре. Также проблемой такого способа является то, что вернуться к предыдущей версии невозможно в случае неудачного обновления, что может привести к неработоспособности сервера или даже всей инфраструктуры. Я считаю, что данный способ миграции не приемлем и весьма опасен, но всё же решать вам.

Вторым способ обновления, это создание нового леса, и постепенное внесение всех ресурсов в новый лес. Данный способ является очень трудоёмким, и приводит к временной остановке работы инфраструктуры, что как следствие приведет к финансовым потерям и негативному отношению бизнеса к ИТ отделу. Но в данном способе есть и свои преимущества. Основным и единственным преимуществом это способа является то, что в домене не будет присутствовать никакой не нужной информации. Но данный способ обновления не всегда возможет. Как правило такой переход возможет только в очень маленьких компания в которой нету сформировавшейся инфраструктуру. Для таких компаний больше подходит Microsoft Windows Small Business Server. На данный момент существует Microsoft Windows Small Business Server 2011 Standard. Данный продукт предназначен для малого бизнеса, в него уже включен Exchange 2010 и SharePoint Foundation.

Самым оптимальным способом является способ миграции ролей Active Directory Domain Services. Данный способ является оптимальным так как, используя его, вы разворачиваете новые сервера и переносите на них необходимые роли, а старые сервера выводите из эксплуатации как домен контролеры, или используете по необходимости. Что делать с серверами вам может помочь документация, которая была полученная при начальном планировании с помощью Microsoft Assessment and Planning Toolkit.

Теперь давайте перейдем непосредственно. Первым шагом будет подготовка домена к обновлению. Для этого необходимо с установочного диска Microsoft Windows Server 2008 если будем обновлять до Microsoft Windows Server 2008, скопировать приложение ADprep на домен. Данное приложение находиться на диске в папке Support. Данное приложение предоставлено в двух версиях, одна для 32 битных операционных систем, а второе для 64 битных операционных систем соответственно. После чего необходимо подготовить лес нашей организации, для этого необходимо выполнить «ADPrep.exe /forestprep» на 64 битной операционной системы, если же у вас 32 битная система вам необходимо выполнить «ADPrep32.exe /forestprep», данная команда должна быть выполнена на сервере, который выполняет роль мастера схемы. Хочу обратить ваше внимание что для того чтобы провести подготовку леса, его уровень должен быть не ниже «Windows 2000 Native». Данный процесс может занять некоторое время, поэтому пока идет подготовка домена, вы можете спокойно сходить попить чай. После того когда лес подготовиться необходимо подготовить домен и все групповые политики для миграции. Для этого необходимо выполнить «ADPrep.exe /domainprep /gpprep» на 64 битной операционной системы, если же у вас 32 битная система вам необходимо выполнить «ADPrep32.exe /domainprep /gpprep», данная команда должна быть выполнена на сервере, который выполняет роль мастера инфраструктуры. После того как домен подготовлен, мы можем смело начинать установку нашего нового домен контролера. После установки операционной системы, наш сервер необходимо включить в домен. После чего установить на нем роль Active Directory Domain Services и поднять уровень сервера до домен контроллера. Для того чтобы поднять уровень сервера до домен контроллера необходимо запустить команду dcpromo. Хочу обратить ваше внимание на то что в данном примере подразумевается то что у нас всего один домен контроллер, но даже если он не один, общая схема нечем не отличается кроме количества новых домен контролеров. Во время поднятия сервера до уровня домен контролера необходимо обязательно указать, что данный сервер будет являться сервером глобального каталога. После того когда поднятие сервера до уровня домен контролера закончено, необходимо на новый сервер перенести все базы DNS сервера. Для начала необходимо остановить роль DNS сервера, для этого в командной строке необходимо выполнить «net stop dns», после чего необходимо выполнить экспорт реестра для этого необходимо выполнить «reg export HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDNSParameters %Windir%System32DNSDns-Service.REG

reg export “HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDNS Server” %Windir%System32DNSDns-Software.REG». После экспорта реестра необходимо скопировать базу DNS сервера, база DNS сервера находиться по адресу %windir%System32DNS. Когда база скопирована необходимо включить DNS сервис, для этого выполним «net start dns». После этого необходимо остановить службу DNS сервера на конечном сервере, для этого в командной строке необходимо выполнить «net stop dns». После остановки DNS сервиса необходимо заменить базы нового DNS сервера, на базы которые были скопированы с исходного DNS сервера, и импортировать реестр. После этого необходимо включить DNS сервис, для этого выполним «net start dns». Теперь необходимо синхронизировать оба сервера, для этого нужно воспользоваться стандартными средствами Active Directory. Когда синхронизация закончилась необходимо проверить схождение исходного и конечного DNS серверов. Для этого существует скрипт разработанный компанией Microsoft, который находиться по следующей ссылке http://go.microsoft.com/fwlink/?LinkId=135502. Для того чтобы выполнить этого необходимо запустить этот скрипт выполнив следующую команду «DNSConvergeCheck <исходный DNS> <конечный DNS server> <fqdn домена>». Данный процесс может занять продолжительный промежуток времени, поэтому не пытайтесь его прервать, а дождись его завершения. После завершения проверки схождения исходного и конечного DNS серверов, необходимо передать все FSMO на новый домен контролер.

Существует несколько действий, при которых недопустимы конфликты. Например, создание нового домена в лесу. Допустим? два администратора решили в одно время создать по домену new в лесу comany.com.ua, то система сама никогда не сможет определить какой из них нужно оставить. Поэтому и существуют роли, которые называются FSMO. Их задача не допускать конфликтов в Microsoft Active Directory Domain Services. Существует всего пять FSMO ролей, это Хозяин именования домена (Domain naming master), Хозяин схемы (Schema master), Хозяин инфраструктуры (Infrastructure Master),Эмулятор PDC (PDC emulator), Хозяин RID (RID Master). Две первые из них в лесу уникальны и существуют в одном экземпляре, и соответственно три присутствуют в каждом домене.

Роль хозяин именования домена (Domain naming master) — отвечает за изменение пространства доменных имен каталога в рамках леса. Только контроллер с этой ролью имеет право удалять и добавлять домены в каталог. Кроме того, он добавляет и удаляет перекрестные ссылки на домены во внешних каталогах.

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

Хозяин инфраструктуры (Infrastructure Master). Контроллер домена, выполняющий роль хозяина инфраструктуры, отвечает за обновление идентификаторов защиты (GUID и SID для участников безопасности) и различие имен объектов.

Эмулятор PDC (PDC emulator). Эмулятор основного контроллера домена необходим для синхронизации времени в рамках компании. В состав Windows входит служба времени W32Time, используемая протоколом проверки Kerberos. Все компьютеры под управлением Windows в рамках одной компании должны иметь одинаково настроенные часы. Эмулятор PDC домена выступает в роли главного эмулятора домена. Эмулятор PDC в корне леса становится главным эмулятором в пределах предприятия. Его следует настроить на получение значения времени от внутреннего источника. При выборе источника времени обладатели роли FSMO эмулятора основного контроллера домена следуют иерархии доменов.

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

Для передачи роли необходимо выполни следующие команды. Вначале запустить утилиту NTDSUtil. После чего выполнить подключение к серверу, которому вы хотите передать одну из ролей FSMO. Для этого в командной строке NTDSUtil пишем «roles» чтобы перейти в меню управления ролями, а потом «connections», этой командой мы переходим в меню управления соединениями. После выполнить команду подключения к серверу, для этого выполняем «connect to server <имя конечного сервера>». Теперь необходимо перейти в основное меню, для этого пишем «quit». И теперь можно передавать роль, для этого пишем «Transfer <имя роли>». По окончанию передачи ролей, выполняем команду выхода, выполнив «quit». Таким же образом происходит и захват роли, только вместо «Transfer <имя роли>», выполняем «SEIZ <имя роли>». Захват ролей необходим для тех случаев, когда домен контроллер, которому принадлежала роль вышел из строя, и по этой причине нельзя её перенести.

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

Источник

В этой статье мы покажем, как перенести базу данных и транзакционные логи Active Directory из одного каталога в другой. Данный мануал может пригодится, когда нужно перенести базу AD на другой диск (в ситуациях, когда на первоначальном диске закончилось свободное место или при недостаточной производительности дисковой подсистемы), либо перенести файлы AD в другой каталог (например, в рамках приведения к стандартному виду путей к БД AD на всех контроллерах домена предприятия).

Перенос файлов базы данных Active Directory возможен только при остановленных службах Active Directory Domain Services. Для переноса мы воспользуемся утилитой ntdsutil.

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

Важно! Для хранения базы данных Active Directory нельзя использовать съемный диск. Диск должен быть отформатирован в файловой системе NTFS. Файловые системы FAT/FAT32/ReFS/ExFAT не поддерживаются.

Операция переноса должна выполняться из-под учетной записи администратора домена / предприятия (группы Domain Admins/Enterprise Admins).

Перенос базы и журналов транзакций Active Directory на контроллере домена во всех поддерживаемых на данный момент серверных ОС Microsoft практически идентичен за исключением пары моментов.

Содержание:

Перенос NTFS разрешений каталога NTDS
Перенос БД AD в Windows Server 2008/2008 R2
Перенос БД AD в Windows Server 2012/2012 R2
Перенос базы AD в Windows Server 2003

Перенос NTFS разрешений каталога NTDS

Очень важно при переносе файлов базы и журналов AD, чтобы на новый каталог действовали те же самые разрешения, что и на исходный. NTFS разрешения на новый каталог можно назначить вручную или скопировать такой командой Powershell:

get-acl C:WindowsNTDS | set-acl E:NTDS

где, C:WindowsNTDS – первоначальный каталог с базой AD

E:NTDS – каталог, в который производится перенос

Перенос БД AD в Windows Server 2008/2008 R2

В Windows Server 2008 / 2008 R2 роль Active Directory является отдельной службой (ADDS), которую можно остановить, без необходимости перезагружать сервер в режиме восстановления каталога (DSRM). Чтобы остановить службу Active Directory Domain Services, откройте командную строку с правами администратора и выполните команду:

net stop ntds

И подтвердить остановку службы нажав Y и Enter.

Далее в этой же командной строке запускаем утилиту ntdsutil:

ntdsutil

Выберем активный экземпляр базы AD:

activate instance NTDS

Перейдем в контекст files, в котором возможно выполнение операция с файлами базы AD, набрав к командной строке:

files

Перенесем базу AD в новый каталог:

move DB to E:ADDB

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

info

Далее переместим в тот же каталог файлы с журналами транзакций:

move logs to E:ADDB

Удостоверимся, что все перенесено корректно, открыв целевой каталог в проводнике.

Осталось в контексте ntdsutil дважды набрать quit.

Запустим службу Active Directory Domain Services командой:

net start NTDS

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

Перенос БД AD в Windows Server 2012/2012 R2

В Windows Server 2012/ 2012 R2 процедура переноса базы аналогична описанной в предыдущем разделе для Windows Server 2008/2008 R2 и также не требует входа в DSRM режим.

Останавливаем службу Active Directory Domain Services:

net stop ntds

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

ntdsutil
activate instance NTDS
files
move DB to E:ADDB
move logs to E:ADDB
quit
quit

Запустим службу ADDS:

net start NTDS

Перенос базы AD в Windows Server 2003

В отличии от более новых платформ, служба каталога Directory Service в Windows Server 2003 / 2003 R2 использует файлы БД Active Directory в монопольном режиме. Это означает, что при работе сервера в роли контроллера домена доступ к этим файлам получить нельзя. Выполнить перенос файлов базы AD можно только в режиме восстановления Directory Services Restore Mode.

Чтобы попасть в DSRM режим, нужно перезагрузить DC и, нажав во время загрузки F8, выбрать в меню пункт Directory Services Restore Mode (Windows domain controllers only).

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

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

Источник

How Do I Migrate or Transfer Active Directory (AD) to Another Server

«Does anyone know how to transfer Active Directory to another Windows Server computer? For example, I purchased a new Windows Server 2022, and I want to move AD from my old Windows Server 2016 to Server 2022. How do I do it?»

Are you looking for a reliable way to migrate the Active Directory database from a Windows Server computer to a new Server machine? Relax, and don’t worry if you are a new Server manager. Here on this page, we’ll show you the complete procedure of successfully migrating AD from Server to Server. First, let’s see the details:

In this article, you’ll learn:

What Is Active Directory and Why Need to Move It to a New Server
Method 1. Backup Active Directory and Restore It to Another Server
Method 2. Use Active Directory Migration Tool

Before migrating AD to a new Server, let’s see what Active Directory is and why it’s so important that Windows Server users want to transfer it from Server to Server.

What Is Active Directory and Why Need to Move It to a New Server

Active Directory stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store as the basics for a logical, hierarchical organization of directory information.

— By Microsoft Active Directory Overview

According to the above description, an Active Directory can be regarded as a database called AD, which connects users to network resources to accomplish their tasks. So what does Active Directory includes? Check this out:

Information objects — shared resources such as servers, volumes, printers, network users, and computer accounts.
A set of rules — schema defines the classes of objects and attributes contained in the Directory.
A global catalog — information about every object in the Directory.
A query and index mechanism — make sure objects, and their properties can be published and found by network users or applications.
A replication service — distribute directory data across a network.

While switching Server computers, one of the key steps is to transfer Active Directory to a New Server. Here following, we’ve collected two methods that you can follow to successfully migrate the AD database to a new server on your own.

Both methods work to transfer Active Directory from one Server to another Server on Windows Server 2022/2019/2016/2012 r2/2012/2008 r2/2008/2003, etc.

Method 1. Backup Active Directory and Restore It to Another Server

Tool: PowerShell
Difficulty Level: high

Suppose you’ve got two Windows Server computers, and now you are about to transfer the active directory database from one Server to another Server computer. Here are the manual steps that you can follow:

Step 1. Introduce a new domain controller with the target Server to be the new FSMO role holder for the domain.

To migrate the FSMO role, you can refer to this post in the Microsoft community for help: Transfer FSMO Roles in Active Directory.

Step 2. Introduce new domain controllers to the forest root and domain tree levels.

Open PowerShell and type the following two command lines and hit Enter each time:

hostname
netdom query fsmo

Step 3. Login into the target Server computer as a member of the local administrator group. And add Server to the existing domain as a member.

Step 4. Restart Windows Server and logo into the Server as Enterprise Administrator.

And assign the static IP address to the Server.

Step 5. Right-click the Windows icon and select «Windows PowerShell (Admin)».

Step 6. Type Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools in PowerShell and hit enter.

This will install the Active Directory Domain Service Role in the given Server.

Step 7. Type the following syntax command lines one by one and hit Enter each time in PowerShell. This will configure the new Server as an additional domain controller:

Install-ADDSDomainController
-CreateDnsDelegation:$false
-InstallDns:$true
-DomainName «rebeladmin.net»
-SiteName «Default-First-Site-Name»
-ReplicationSourceDC «DC08.rebeladmin.net»
-DatabasePath «C:WindowsNTDS»
-LogPath «C:WindowsNTDS»
-SysvolPath «C:WindowsSYSVOL»
-Force:$true

There are no line breaks for the command listed above. So what are the meanings of these syntax? Check this out:

Syntax Content	Description
Install-ADDSDomainController	This cmdlet will install the domain controller in the 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. The default location for it will be C:Windows
-Force	This parameter will force the command to execute by ignoring the warning. For example, it is typical for the system to pass the warning about best practices and recommendations.

Step 8. Enter a new complex password if the command requests for SafeModeAdministrator Password.

After this, restart the Server system and log in as administrator.

Step 9. Open PowerShell again, type Get-Service adws,kdc,netlogon,dns and hit Enter to check the AD DS status.

Step 10. Type Get-ADDomainController -Filter * | Format-Table Name, IPv4Address, Site in PowerShell, and hit Enter.

Step 11. Migrate all FSMO roles to the new domain controller by typing Move-ADDirectoryServerOperationMasterRole -Identity REBEL-DC2019 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster in PowerShell and hit Enter.

Note: Replace REBEL_DC2019 with your new running Windows Server.

Step 12. Type Netdom query fsmo in PowerShell to verify the new FSMO role holder.

Step 13. Type Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition to decomission the old Windows domain controller.

Step 14. Type Set-ADDomainMode –identity therebeladmin.com -DomainMode Windows2016Domain in PowerShell and hit Enter to upgrade the functional domain levels.

Step 15. Type Set-ADForestMode -Identity therebeladmin.com -ForestMode Windows2016Forest in PowerShell and hit Enter to upgrade forest functional levels.

Wait for the process to complete. After this, the Server AD migration process completes. You can then verify if it completes successfully by typing the next two command lines in PowerShell and hitting Enter each time:

Get-ADDomain | fl Name,DomainMode
Get-ADForest | fl Name,ForestMode

As shown above, if you see the result, you’ve successfully transferred Active Directory to a new Server machine.

Method 2. Use Active Directory Migration Tool

Aside from the above manual method, the other tool you can try is applying an Active Directory migration tool. EaseUS Todo PCTrans Technician with its PC to PC File Transfer feature can fulfill this task for you.

EaseUS Todo PCTrans Technician

 ☆ Deploy & install Todo PCTrans on multiple PCs.

 Transfer unlimited files, programs, apps between Servers.

 Transfer account, domain account, and settings.

 Data rescue, find product key of installed programs.

 One license for multiple PCs.

Here is the complete process that you can apply to migrate and transfer the Active Directory database from one Server to another Server with ease.

Note that you just need to select the AD database folder for file transferring between Server computers during the procedure.

Step 1. Open EaseUS Todo PCTrans on both of your server computers. Choose «PC to PC» to go to the next step.

Step 2. Choose the transfer direction — New PC or Old PC.

«New» — Transfer files from old Server to current new Server.

«Old» — Transfer files from current old Server to a new Server.

Step 3. Connect the current PC to the target PC by entering the target computer’s account password or its verification code. You can turn on the «Connection Verification»on the right top of the «PC to PC» mainscreen on the target computer.

Step 4. Click «Files» > «Transfer» to check all the files you want to transfer to another Server computer. Then click «Transfer» to migrate specific data you have chosen.

Step 5. Wait for the process finishes. PCTrans will transfer files at a fast speed. It won’t take too long.

Once done, you can then reboot the target Windows Server computer and log in as administrator.

Bonus Tips for Server to Server Migration

Aside from transferring Active Directory from one Server to another Server, you may still have much other content that needs to be moved, for example, user data, user accounts, domain accounts and settings, applications, etc.,

How do you completely transfer Sever data to another Server? Check this out:

#1. Transfer User Data and Accounts to New Server

EaseUS Todo PCTrans, with its account settings transfer feature, can help you fully migrate user data and accounts to a new Server in simple clicks.

Step 1. Install and launch EaseUS Todo PCTrans on both two devices. On the source PC, select «PC to PC» to continue.

Step 2. Select the transfer direction — as an Old PC or a New PC.

Make sure the two PCs are on the same LAN. Connect to the target PC via its IP address or adding it manually. Enter the login account and password of the target PC and link two PCs by clicking «Connect».

Step 3. Click at the «Accounts» section to specify User Accounts and Settings for transferring.

Step 4. Enter the user account and password of the source computer, select the User Account Settings, User Data and other settings that you want to transfer.

Step 5. After selection, click «Transfer» to start to transfer user accounts and settings.

#2. Migrate Essential Applications to New Server

Aside from Server data, files, and accounts, you may also want to move some essential applications to a new Server, for example, the Windows Server Manager, SQL installer, Exchange, Quickbooks, Office, Adobe, etc.

You can simply manage this task and accomplish it on your own with the help of reliable Windows Server file transfer software. Here is how to do so:

Step 1. Run EaseUS Todo PCTrans on both PCs

On the source PC, select «PC to PC» on the main screen of EaseUS Todo PCTrans and move on.

Step 2. Choose transfer direction — Old or New Computer

«New» — Transfer all data from remote old computer to current new computer.

«Old» — Transfer all data from current old device to a new computer.

Step 3. Connect two computers

1. Select your target PC to connect via its IP address or device name and click «Connect».

2. Enter the login password of your target PC and click «OK» to confirm.

If you didn’t see the target PC in the listed devices, you can also click «Add PC» to manually connect the target PC by inputting its IP address or device name.

Step 4. Select apps, programs, and software and transfer to the target computer

1. You can select and choose what you want to transfer from the current computer to the target PC.

2. After selecting desired applications and programs, click «Transfer» to start the transferring process.

Moving AD from Server to a New Server Is Complex, Be Careful and Patient

This tutorial page tells what Active Directory is and why it is so important for Server administrators to migrate AD to a new Server.

We also introduced two methods that help to successfully migrate Active Directory to a new Server on Windows Server 2022/2019/2016/2012/2008/2003, etc.

Note that the procedure is a bit complex. So be sure that you are careful and patient while typing the command lines in PowerShell to execute the task.

Источник

How Do I Migrate or Transfer Active Directory (AD) to Another Server

In this article, you’ll learn:

What Is Active Directory and Why Need to Move It to a New Server
Method 1. Backup Active Directory and Restore It to Another Server
Method 2. Use Active Directory Migration Tool

Before migrating AD to a new Server, let’s see what Active Directory is and why it’s so important that Windows Server users want to transfer it from Server to Server.

What Is Active Directory and Why Need to Move It to a New Server

— By Microsoft Active Directory Overview

Information objects — shared resources such as servers, volumes, printers, network users, and computer accounts.
A set of rules — schema defines the classes of objects and attributes contained in the Directory.
A global catalog — information about every object in the Directory.
A query and index mechanism — make sure objects, and their properties can be published and found by network users or applications.
A replication service — distribute directory data across a network.

Both methods work to transfer Active Directory from one Server to another Server on Windows Server 2022/2019/2016/2012 r2/2012/2008 r2/2008/2003, etc.

Method 1. Backup Active Directory and Restore It to Another Server

Tool: PowerShell
Difficulty Level: high

Step 1. Introduce a new domain controller with the target Server to be the new FSMO role holder for the domain.

To migrate the FSMO role, you can refer to this post in the Microsoft community for help: Transfer FSMO Roles in Active Directory.

Step 2. Introduce new domain controllers to the forest root and domain tree levels.

Open PowerShell and type the following two command lines and hit Enter each time:

hostname
netdom query fsmo

Step 3. Login into the target Server computer as a member of the local administrator group. And add Server to the existing domain as a member.

Step 4. Restart Windows Server and logo into the Server as Enterprise Administrator.

And assign the static IP address to the Server.

Step 5. Right-click the Windows icon and select «Windows PowerShell (Admin)».

Step 6. Type Install-WindowsFeature –Name AD-Domain-Services -IncludeManagementTools in PowerShell and hit enter.

This will install the Active Directory Domain Service Role in the given Server.

Step 7. Type the following syntax command lines one by one and hit Enter each time in PowerShell. This will configure the new Server as an additional domain controller:

Install-ADDSDomainController
-CreateDnsDelegation:$false
-InstallDns:$true
-DomainName «rebeladmin.net»
-SiteName «Default-First-Site-Name»
-ReplicationSourceDC «DC08.rebeladmin.net»
-DatabasePath «C:WindowsNTDS»
-LogPath «C:WindowsNTDS»
-SysvolPath «C:WindowsSYSVOL»
-Force:$true

There are no line breaks for the command listed above. So what are the meanings of these syntax? Check this out:

Syntax Content	Description
Install-ADDSDomainController	This cmdlet will install the domain controller in the 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. The default location for it will be C:Windows
-Force	This parameter will force the command to execute by ignoring the warning. For example, it is typical for the system to pass the warning about best practices and recommendations.