Главная > Active Directory > Microsoft University Online 2011 – Active Directory (Миграция AD с Windows Server 2003 на Windows Server 2008 R2)

Microsoft University Online 2011 – Active Directory (Миграция AD с Windows Server 2003 на Windows Server 2008 R2)

Доброго времени суток коллеги. Это моя очередная статья, которая посвящена 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_MACHINE\System\CurrentControlSet\Services\DNS\Parameters %Windir%\System32\DNS\Dns-Service.REG

reg export “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server” %Windir%\System32\DNS\Dns-Software.REG». После экспорта реестра необходимо скопировать базу DNS сервера, база DNS сервера находиться по адресу %windir%\System32\DNS. Когда база скопирована необходимо включить 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 <имя роли>». Захват ролей необходим для тех случаев, когда домен контроллер, которому принадлежала роль вышел из строя, и по этой причине нельзя её перенести.

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

  1. Комментариев нет.
  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: