Перенос компьютеров active directory

Обновлено: 01.07.2024

Не секрет, что окончание поддержки Windows Server 2003 все ближе. День Х назначен на 17 июля 2015 года, а значит остается все меньше времени, чтобы успеть перевести свою инфраструктуру на более современные версии операционной системы. На Хабре мы уже делали несколько анонсов об окончании поддержки, на портале Microsoft Virtual Academy опубликован курс по материалам Jump Start, есть перевод статьи о переносе файлового сервера. В этой статье будет рассказано о миграции Active Directory и приведен пошаговый алгоритм, которым поможет вам при реализации переноса.

Перенос Active Directory с Windows Server 2003 на Windows Server 2012 R2 является одной из первоочередных задач, которые необходимо решить в процессе миграции.
На самом деле, перенос Active Directory не несет в себе каких-либо сложностей. Нужно выполнить лишь несколько шагов, о которых будет подробно рассказано далее.
Сначала выполним небольшую настройку на контроллере домена с установленной на нем Windows Server 2003. Обязательно проверьте, что для существующего домена и леса в качестве режима работы (functional level) выбран Windows Server 2003.
Для того, что изменить режим работы домена и леса необходимо запустить оснастку Active Directory Domains and Trust. Для изменения режима работы домена щёлкаем правой кнопкой мыши по домену, для режима работы леса – по Active Directory Domains and Trusts. Выбираем Raise Domain Functional Level и Raise Forest Functional Level соответственно.

В обоих случаях режим работы должен быть установлен на Windows Server 2003.

Следующим шагом нам нужно добавить к нашей сети второй контроллер домена под управлением Windows Server 2012 R2. Для этого на сервер с Windows Server 2012 R2 устанавливаем роль Active Directory Domain Services.

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

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

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

Для установки домена необходимо выполнить подготовку леса, домена и схемы. Если раньше для этого обязательно нужно было запустить команду adprep (причем сделать это надо было до начала конфигурации домена), то теперь эту задачу берет на себя мастер конфигурации ADDS, и подготовка может быть выполнена автоматически.

Далее нужно дождаться завершения установки и перезагрузить компьютер. В итоге, вы получите контроллер домена с установленной на нем Windows Server 2012 R2.
Теперь в оснастке Active Directory Users and Computers мы можем увидеть, что в нашей сети есть два контроллера домена.

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

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

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

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

Подтверждаем операцию переноса и дожидаемся ее благополучного завершения. Не забудьте проверить, что в итоге роль хозяина операций теперь находится на сервере под управлением Windows Server 2012 R2:

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

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

В новом окне выберите пункт This Domain Controller or AD LDS instance и укажите сервер под управлением Windows Server 2012 R2.

Теперь снова щёлкаем правой кнопкой мышки по лесу и выбираем пункт Operations Master.

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

3. Изменение Мастера схемы (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. Аналогично действиям, которые мы выполняли в пункте 2, в новом окне выберите пункт This Domain Controller or AD LDS instance и укажите сервер под управлением Windows Server 2012 R2 и нажмите ОК. Появится предупреждение о том, что оснастка схемы Active Directory не подключена. Нажмите ОК для продолжения.
Теперь снова щёлкаем правой кнопкой мышки по лесу и выбираем пункт Operations Master. Для переноса роли хозяина схемы в новом окне нажмите Change.
Теперь можно закрыть MMC консоль, открыть оснастку Active Directory Users and Computers и убедиться, что данные успешно реплицированы на ваш новый сервер под управлением Windows Server 2012 R2. Имейте ввиду, что процесс репликации может занять некоторое время (все зависит от количества объектов Active Directory, которые нужно реплицировать).

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

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

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

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

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

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

По определённым причинам появилась необходимость в переносе пользователей из одного домена в другой. Это возможно сделать штатными средствами операционной системы Microsoft. И в этом нам поможет утилита ldifde.exe. Она предназначена для экспорта/импорта пользователей Active Directory в файл с расширением .ldf. При необходимости его можно редактировать любым текстовым редактором (как в моём случае). Но программа переносит только пользователей, без групп и паролей. Пароли будут сброшены на пустые и при следующем входе в систему будет предложено сменить пароль.

На контроллере домена запускаем командную строку CMD и для удобства переходим в корень диска С c:, так как при выполнении команды вся информация будет выгружена в файл Exportuser.ldf.

Где SRVDC1 — это имя контроллера домена, а dc=DOMAIN,dc=NAME — это текущее доменное имя вашего контроллера. На выходе мы получаем файл Exportuser.ldf в корне диска С.

Так как доменное имя нового домена отличается от текущего, то в файле необходимо заменить все строчки dc=DOMAIN,dc=NAME на необходимые, с указанием нового имени. Сохраняемся, перекидываем файл на новый сервер и выполняем импорт следующей командой

Где NEWSRVDC1 — это имя нового контроллера домена.

Перенос групповых политик

Для нормальной работы моего сервера также необходимо было перенести настройки групповых политик (GPO). На старом домене запускаем консоль gpmc.msc. Раскрываем домен, выбираем Объекты групповой политики, в содержимом отмечаем те политики, что собираемся переносить и правой кнопкой мыши вызываем меню. Выбираем Архивировать. .

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

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

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

Чаще всего переезд на новый домен Active Directory может потребоваться в случаях, когда на старом домене были допущены критические ошибки на этапе планирования или домен имеет фатальные повреждения.

Во втором случае все относительно понятно, а вот границы наступления первого для многих очень размыты. Это может быть например миграция с одноуровневого домена (single-label domain) или что-то другое. Ниже в статье постараюсь пролить свет на эти окутанные туманом рассуждения.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Переезд на новый домен Active Directory

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

Объективные причины

А может оставить все как есть?

Справедливости ради надо отдать должное тем людям, которые стремятся сделать что-то лучше, но в случае переезда на другой домен AD можно пойти другим путем. А именно допилить существующий домен до приемлемого состояния.

Именно об этом варианте я и собираюсь рассказать на примере доведения до ума старого домена, который был поднят ещё на Windows Server 2000.

Задачи

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

Начнем разбор с самого начала.

Резервное копирование

Как правильно бэкапить виртуальные КД и КД вообще можно написать очень много статей и сценарии будут разными для разных версий ОС. Чтобы кратко ознакомиться с ситуацией, советую почитать статью в блоге 1 .

Выполняйте контрольное резервное копирование между важными изменениями в ядре инфраструктуры;
Сохраняйте резервные копии до тех пор, пока вы не убедитесь в нормальном функционировании всех КД;
Резервное копирование выполняйте поддерживаемыми средствами (например VSS);
Обязательно убедитесь, что вы имеете восстанавливаемые резервные копии! Да, забэкапить мало, надо ещё и проверить а восстанавливаются ли бэкапы нормально или нет.

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

Диагностика AD

Обязательно пройдитесь по всем КД и проверьте состояние их здоровья:

Проанализируйте ошибки AD DS, DNS и др. служб в просмотре осбытий;
Проверьте репликацию 2 и состояние КД командами repadmin и dcdiag;
Установите все обновления ОС.

Только при отсутствии проблем приступайте ко всем изменениям.

Имя домена

Теперь суть вопроса: чтобы пользоваться красивыми именами и логиниться во все доменные сервисы по адресу электронной почты достаточно создать дополнительный UPN-суффикс и назначить его всем нужным учеткам. При этом неважно какое у вас имя домена. Для переезда в облако доп. суффиксов достаточно (если у кого сомнения, читайте Локальная инфраструктура и Azure AD)

Перенос DNS-зоны _msdcs.ForestName

Это первое, с чего я начал. Почему? Нужно привести DNS в нормальное состояние, ведь от этого сервиса зависит здоровье AD в целом.

Для доменов, созданных на Windows Server 2000, зона _msdcs.ForestName располагается на уровне домена и желательно её перетащить на уровень леса, как это по умолчанию сделано на новых доменах AD на Windows Server 2003 и старше:

Сам процесс подробно расписан в официальной документации и на моем блоге в статье DNS-зона _msdcs.ForestName отсутствует.

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

Настройка защищенных динамических обновлений DNS

Вероятнее всего большинство разрешают незащищенные обновления DNS 3 . Тем не менее, согласно лучшим практикам рекомендуется разрешать динамические обновления только для авторизованных клиентов 4 .

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

Не забывайте, что вы можете настроить обновление клиентских DNS-записей на стороне DHCP-сервера, если он развернут на Windows Server. Изменения можно проводить в рабочее время (я бы даже сказал рекомендуется проводить в рабочее время), будет возможность оперативно отлавливать проблемы пользователей.

Настройка зон обратного просмотра

Изменения можно проводить в рабочее время.

Обновление уровней леса и домена

Нет никаких причин сидеть на старых уровнях леса и домена 5 и лишь ограничивать себя в функциональности AD. Например пользуйтесь корзиной AD 6 , повысив уровень леса до 2008 R2 и активировав соответствующую функцию.

Повысьте до максимально возможных значений уровни леса и домена (зависит от того на каких версиях ОС у вас работают КД) 7 . Задача относительно безболезненная, можно выполнять её в рабочее время.

Переезд с FRS на DFS-R

Уже с Windows Server 2008 FRS не считается надежной и устарела, а на дворе 2017 год. Смело переезжайте на DFS-R, к тому же последние на сегодняшний момент версии ОС уже перестали поддерживать FRS вообще (то есть даже новые КД на Windows Server 2016 в домен вам не запилить).

Процесс миграции очень хорошо документирован и на некоторых шагах есть возможность откатиться назад, читайте мою статью Заметки: Миграция репликации SYSVOL с FRS на DFS.

Процесс миграции вполне возможно проводить в рабочее время.

Настройка межсайтовой топологии (если актуально)

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

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

Best practice

Если вы прошли путь, который я расписал выше и который проходил сам и хотите сделать ещё лучше, то предлагаю посмотреть в сторону лучших практик администрирования AD DS. Читайте дальше.

Удаление лишних ролей

Идея в том, чтобы построить ядро инфраструктуры из абсолютно идентичных друг другу контроллеров домена (кроме ip и ролей fsmo разумеется). В случае утери любого из них не надо заморачиваться с его восстановлением, просто вычистите его остатки из AD и заведите новый с нуля.

Все поворачивается к вам совсем другим местом, если у потерянного КД имелись какие-то важные данных (многие организации держат и файловые помойки, и терминальные серверы и многое другое на одиночных КД). Таким образом вы лишаете себя той гибкости, которая изначально была заложена в архитектуру AD DS.

Вот пример списка установленных ролей и компонентов с полностью чистого контроллера домена:

Одна и та же версия ОС

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

Выполняйте плановый вывод контроллеров домена на устаревших ОС.

Active Directory - от теории к практике. Часть 4 - перенос учетных записей в домен.

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

Очень редко когда структура Active Directory создается с нуля, гораздо чаще службы каталогов разворачиваются уже на базе существующей сети, где каждый пользователь имеет свою, настроенную согласно его потребностям, учетную запись, свой набор ярлыков, папок, программ, настроек. При переходе от локальной учетной записи к учетной записи Active Directiory все эти настройки окажутся потерянными и учетную запись пользователя нужно настраивать заново.

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

К сожалению не одни только ученые записи способны вызвать затруднения при переходе на Active Directory, поэтому самое время вспомнить о том, что такое SID. SID компьютера - это уникальный идентификатор безопасности, который генерируется при установке системы и используется в качестве основы при создании прочих идентификаторов (для пользователей, групп и т.п.). Хотя в настоящее время многие специалисты считают проблему дублирующегося SID преувеличенной, например см. статью М. Руссиновича "Миф о дублировании SID компьютера", мы не рекомендуем рисковать и включать в домен машины с одинаковыми SID.

Когда может возникнуть такая ситуация? При клонировании уже установленной системы на несколько ПК, например столь любимыми многими утилитами Norton Ghost или Acronis. Появление в сети подобным машин может привести к неправильному применению групповых политик и некорректной работе некоторых сетевых служб, например WSUS. Мы не будем однозначно утверждать, что данные проблемы возникают именно от дублирующегося SID, но лучше предупредить возможные проблемы, чем потом заниматься их решением. Поэтому лучше позаботиться об уникальности SID до включения машин в домен и появления возможных проблем.

Для обеспечения уникальности SID следует использовать утилиту sysprep, о использовании которой мы рассказывали в данной статье, в Windows 7 данная утилита входит в состав системы и расположена в C:\Windows\System32\sysprep.

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

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

Для серверов, которые должны иметь статические сетевые параметры укажите необходимые значения вручную, особое внимание следует уделить DNS-серверам, это должны быть адреса двух любых контроллеров домена (которые совмещают роль DNS-сервера), в противном случае у вас не получится ввести такой компьютер в домен.

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

Теперь самое время включить наш компьютер в домен. Для этого перейдите в Свойства системы - Имя компьютера и нажмите кнопку Изменить. В открывшемся окне выберите Является членом домена и укажите имя домена в который мы хотим войти, затем нажмите OK, затем укажите имя и пароль пользователя имеющего право на включение компьютера в домен (по умолчанию администратор домена).

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

После перезагрузки можно попробовать войти под доменной учетной записью, которую нужно предварительно создать на любом из контроллеров домена. Для этого откройте оснастку Active Directory - пользователи и компьютеры, перейдите в папку User и создайте там нового пользователя.

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

Поэтому самое время заняться переносом профиля локальной учетной записи в доменную. Для этого следует воспользоваться инструментом User State Migration Tool, который входит в состав Пакета автоматической установки Windows (AIK), скачать его можно здесь.

Данный пакет нет необходимости устанавливать на всех ПК, вполне достаточно будет установки на компьютер администратора или один из серверов. Искомый набор утилит находится в папке C:\Program Files\Windows AIK\Tools\USMT нам нужно будет скопировать их на целевую систему или сделать доступными по сети.

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

Внимание! Вы можете перенести профиль из 32-х разрядной системы в 64-х разрядную, однако обратный перенос из 64-х разрядной в 32-х разрядную не поддерживается!

Для создания файла переноса используется утилита ScanState с синтаксисом которой можно ознакомиться здесь. В нашем случае мы будем переносить локальный профиль пользователя WWW в профиль доменного пользователя ivanov. Для создания файла переноса войдите в систему под учетной записью администратора домена, перейдите в папку с нужной версией USMT (32 или 64 бит) и выполните следующую команду:

Синтаксис команды на первый взгляд довольно сложен, но это не так. Первый аргумент указывает расположение файла переноса, ключ /i: указывает какие правила переноса следует использовать, ключ /v: задает необходимый уровень детализации лога, сочетание ключей /ue: и /ui: исключает из переноса всех пользователей кроме WWW, а ключ /l: определяет расположение лога.

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

Итак, файл переноса создан, но не спешите переходить ко второму этапу. Если вы уже входили в систему под целевым пользователем, то необходимо удалить или переименовать папку с профилем в каталоге C:\Users и удалить соответствующий профилю раздел в ветке реестра:

В противном случае при попытке восстановления профиля вы получите ошибку с кодом 71: LoadState return code: 71.

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

Структура команды во многом похожа на предыдущую, одноименные ключи имеют аналогичное значение, ключ /mu: указывает исходный профиль и профиль назначения, доменные учетные записи указываются как Domain\User. В нашем случае профиль локального пользователя WWW будет восстановлен в профиль пользователя interface31.lab\ivanov.

Теперь, выполнив вход под доменной учетной записью пользователь Иванов обнаружит привычное рабочее окружение, как видно на скриншоте ниже, перенеслось даже содержимое корзины.

Данный метод можно использовать для операционных систем Windows Vista/7, для переноса профилей в среде Windows XP также можно использовать USMT несколько изменив синтаксис команд, но лучше воспользоваться утилитой moveuser, которая входит в состав Windows Server 2003 Resource Kit Tools (скачать). Точно также, как и в предыдущем случае, нет необходимости устанавливать пакет на каждую машину, достаточно скопировать утилиту moveuser которая находится в папке C:\Program Files\Windows Resource Kits\Tools.

Для переноса профиля также войдите на целевой ПК как администратор домена и выполните команду:

Синтаксис данной утилиты гораздо проще и его можно изучить запустив ее без аргументов. Ключ /y разрешает перезаписать профиль назначения если он существует, т.е. вы можете предварительно выполнить вход доменным пользователем на эту машину, это никак не помешает переносу, после переноса вход под локальным пользователем будет невозможен, если вы хотите продолжать использовать локальный профиль укажите дополнительно ключ /k.

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

Как видим, использование специализированных утилит для переноса пользовательских профилей не вызывает затруднений и способно значительно облегчить работу системного администратора и свести к минимуму неудобства пользователей в процессе внедрения Active Directory.

10.11.2014

Active Directory

Комментариев пока нет

В этой статье мы покажем, как перенести базу данных и транзакционные логи 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, чтобы на новый каталог действовали те же самые разрешения, что и на исходный. NTFS разрешения на новый каталог можно назначить вручную или скопировать такой командой Powershell:

$Копирование и перенос NTFS разрешений на каталог C:\Windows\NTDS с помощью$

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

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

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

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

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

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

Совет. Ранее мы уже писали, как с помощью ntdsutil можно выполнить различные операции по обслуживанию и управлению метаданными в базе AD. Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перенос базы 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.

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

Читайте также: