Дополнение А. Техническое руководство переименования домена

Данное руководство является переводом материалов Domain Rename Technical Reference с обновлениями от 19 ноября 2014.

Применимо к Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 с SP1, Windows Server 2003 с SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2.

Операционные системы Microsoft Windows Server 2008 R2, Windows Server 2008 и Windows Server 2003 предоставляют возможности переименования домена в некотором лесу служб домена AD DS (Active Directory Domain Services) после размещения данной структуры леса на своём месте. Такие возможности переименования домена доступны в некотором лесу, который имеет уровень функционирования Windows Server 2003 или выше. Эти возможности не доступны в операционных системах Windows Server 2000.

Вы можете применять данный процесс переименования домена для изменения всех имён своих доменов, а также вы можете применять его для изменения всей структуры своих деревьев домена в вашем лесу. Данный процесс влечёт за собой обновления DNS (Domain Name System) и доверительных структур, а также Групповой политики и SPN (service principal names, Основных имён служб).

Вся структура некоторого леса Active Directory является результатом того порядка, в котором вы создаёте домены и все иерархические имена таких доменов. Начиная с самого первого корневого домена леса, все дочерние домены выводят свои отличительные имена и имена DNS по умолчанию начиная с самого имени такого корневого домена леса. В точности то же самое верно и для кждого дополнительного дерева в таком лесу. Елинственный способ изменения такой иерархической структуры некоторого имеющегося дерева домена состоит в переименовании всех доменов. Например, вы можете переименовать некоторый дочерний домен чтобы он имел другого родителя или переименовать какой- то дочерний домен, чтобы он стал неким новым доменом корня дерева. В каждом из этих случаев вы изменяете положение некоторого имеющегося домена для созания некоторой другой структуры дерева домена.

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

Предмет данного технического руководства не предоставляет информацию о процедуре, которую вам необходимо выполнить для операции переименования некоторого домена. Вместо этого оно предоставляет существенную информацию, которая лежит в основе и которую вам следует досконально понимать прежде чем вы предпримете некоторые действия по переименованию в каой бы то ни было промышленной среде. Предмет данного технического руководства не содержит информации о том как получить такие инструменты и процедуры для действий по переименованию некоторого домена. {Прим. пер.: см. ниже приводится перевод примера такой пошаговой последовательности для Windows Server 2012 R2.}

В данном материале обсуждается:

---

Данный раздел является переводом What Is Domain Rename? с обновлениями от 19 ноября 2014.

Применимо к Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 с SP1, Windows Server 2003 с SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2.

В данном разделе:

Вы можете применять обсуждаемый процесс переименования домена для изменения всех имён своих доменов, кроме того использовать его для изменения имеющейся структуры всех деревьев домена в своём лесу. Этот процесс влечёт за собой изменение DNS (Domain Name System) и доверительной инфраструктуры, а также Групповой политики и SPN (service principal names, Основных имён служб).

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

В Windows Server® 2003 и Microsoft Windows® 2000 Server служба каталога имеет название Active Directory. В Windows Server 2008 R2 и Windows Server 2008 служба каталога именуется Active Directory Domain Services (AD DS). Оставшаяся часть данной статьи применяет термин AD DS, однако вся приводимая информация также применима и к Active Directory.

Для получения информации о методах слияния лесов ознакомьтесь с "Windows 2000/2003: Multiple Forests Considerations White Paper" на веб сайта Microsoft.

 

Ограничения и возможности переименования домена

Имеющиеся возможности переименования домена предоставляют решения для некоторых задач, которые не имеют адресом Windows 2000 Server. В лесу Windows Server 2000 у вас нет возможности переименования доменов после того, как структура данного леса находится на своём месте без перемещения содержимого домена или повторного его создания.

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

 

Ограничения переименования домена в Windows 2000 Server

Те ограничения, которые связаны с изменением имён домена или перестройкой деревьев домена в Active Directory Windows 2000 Server являются запретительными.

В каком бы то ни было лесу restructuring Windows 2000 Server вы не можете:

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

 

Ограничения переименования домена в Windows Server 2003 и последующих версиях

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

В нектором лесу контроллеров домена, которые исполняются под управлением Windows Server 2003 или последующих версий вы не можете:

 

Возможности переименования домена в Windows Server 2003 и последующих версиях

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

Рассматриваемый процесс переименования влечёт за собой внесение основных изменений независимо от всех контроллеров домена в некотором лесу. Вы устанавливаете некий административный компьютер, с которого вы выполняете команды, котрые исполняются удалённо в каждом из контроллеров домена. Эти команды индивидуально обновляют имеющуюся в каждом контроллере домена базу данных каталога применяя те изменения, которые необходимы для переименования данных доменов; то есть, все обновления, которые переименовывают необходимые домены не разносятся по имеющемуся лесу посредством репликации AD DS.

Для осуществления приводимых ниже множественных шагов в обсуждаемом процессе переименования домена вы применяете инструмент Rendom:

Другой инструмент, Gpfixup предоставляется для восстановления Групповой политики из ваших первоначальных доменов во вновь создаваемых доменах в данном лесу.

Инструменты Rendom, Gpfixup и все инструкции для применения их доступны на CD операционной системы Windows Server 2003. Эти инструменты также встроены в контроллеры домена, которые работают под управлением Windows Server 2008 R2 или Windows Server 2008, а также они доступны в RSAT (Remote Server Administration Tools, Инструментах Администрирования Удалённых серверов). Также вы можете загрузить этот инструментарий и инструкции из Инструментов переименования домена Windows Server 2003 c веб сайта Microsoft.

 

Ключевой сценарий для переименования домена

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

 

Переименование домена без перестроения

Вы можете переименовывать домены без перестроения имеющегося леса в терминах текущих взаимосвязей родитель- наследник между имеющимися доменами. Например, предположим что некий имеющийся лес cohovineyard.com для компании Coho Vineyard имеет четыре домена со следуюшими названиями:

Данная компания приняла решение для расширения на бутелирование вина и его рсапространение и желает изменить своё название с Coho Vinetard на Coho Winery. Все имеющиеся имена домена AD DS теперь должны отображать новое имеющееся название. Как показано на приведённом ниже рисунке, окончательный лес всё ещё имет четыре домена со следующими названиями:

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

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

 

Переименование домена c перестроением в том же самом дереве

Вы можете изменять имеющуюся структуру некоторого дерева домена переименовывая некий дочерний домен чтобы он появлялся в новом местоположении в таком дереве. Например, в имеющемся лесу cohowinery.com домен products.sales.cohowinery.com в настоящее время является потомком cohowinery.com домена sales.cohowinery.com, что помещает его на два уровня ниже корневого домена данного леса. Если отделение Product в результате внутренней реорганизации более не является подразделением организации Sales, такая компания может пожелать изменить имеющуюся структуру домена чтобы поместить организацию Product на тот же самый уровень, что и огранизация Sales. Приводимый далее рисунок отображает как изменение предка products.sales.cohowinery.com приводит в результате к некоторому перестроению дерева домена.

 

Переименование домена c созданием некоторого нового корня дерева

Когда вы перестраиваете некоторый лес, вы можете переместить некий домен (за исключением самого первого корневого домена леса) в любое место в данном лесу, в котором расположится данный домен. Вы даже можете переместить домен таким образом, что он станет самим корнем своего собственного дерева домена. Например, в имеющемся лесу cohowinery.com домен для европейского подразделения данной компании с названием eu.cohowinery.com является потомком самого первого корневого домена леса. Управление компании определяет, что название внутреннего домена данного европейского подразделения должно лучше отражать его название в DNS Интернета, cohovineyardandwinery.com. В целевом структуре леса отображённой на следующем рисунке нащ домен домена eu.cohowinery.com перемещается таким образом, чтобы он стал собственным доменом корня дерева и именовался cohovineyardandwinery.com.

 

Переименование домена c перемещением в некоторое другое дерево

Переименовывая домен вы можете фактически перемещать некий дочерний домен к каким- то различным родителям, даже если такой родитель находится в некотором ином дереве.Например, в имеющейся в настоящее время структуре леса домен для кадров (hr, Human Resources) данной организации является неким потомком cohowinery.com. Этот домен имеет контроллеры домена в Соединённых Штатах. Однако, изменения в данной компании пригласили Кадры данной организации изменить своё местоположение на европейское. Управление компании желает переместить hr.cohowinery.com таким образом, чтобы оно стало дочерним подразделением в имеющемся домене cohovineyardandwinery.com, которое расположено в другом дереве домена. Как это отображено на приводимом далее рисунке, имеющийся домен hr.cohowinery.com переименовывается в hr.cohovineyardandwinery.com.

 

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

Как уже объяснялось в Ограничениях переименования домена в Windows Server 2003 и последующих версиях, обсуждаемая операция переименования домена не может переименовывать два или более домена таким образом, чтобы один домен давал своё название и прочие обязательства домена того же самого имени в некоторой отдельной операции перестройки леса. Например, настройках текущего леса на предыдущем рисунке вы не можете воспользоваться единственной опреацией переименования домена чтобы перестроить имеющийся в настоящее время лес с тем, чтобы домен cohovineyardandwinery.com именовал что- то ещё и домен hr.cohowinery.com получил название cohovineyardandwinery.com.

Однако вы можете получить желаемый результат вначале выполнив операцию переименования и сменить название домена cohovineyardandwinery.com на какое- то ещё. Когда вы будете абсолютно уверены что данная первая операция переименования завершена, вы затем можете осуществить операцию переименования домена вновь с тем, чтобы домен hr.cohovineyardandwinery.com получил название cohovineyardandwinery.com.

 

Зависимости переименования домена и взаимосвязи с другими технологиями

Поскольку они могут взаимодействовать с некоторой структурой леса, домены AD DS требуют надлежащих настройки и работы следующих технологий:

В добавление к таким основным требованиям, в случае если имеют место приведённые ниже свойства, они требуют соответствующих изменений во всём лесу при подготовке к самой операции переименования домена:

 

Связанная информация

Приведённые ниже ресурсы содержат дополнительную информацию, которая имеет отношение к данной теме:

---

Данный раздел является переводом How Domain Rename Works с обновлениями от 19 ноября 2014.

Вы можете применять обсуждаемый процесс переименования домена для изменения имён своего домена, кроме того, вы также можете использовать для изменения имеющейся структуры всех деревьев домена в вашем лесу. Данный процесс приводит к изменению DNS (Domain Name System) и инфраструктур доверительных отношений (trust), а также Групповой политики и SPN (service principal names, Основных имён служб).

Так как данный процесс переименования влечёт за собой обновление всех DNS и доверительной инфраструктуры, а также Групповой политики и SPN, некая операция переименования воздействует на все контроллеры домена в вашем лесу. Переименование домена является монгоэтапным процессом, который имеет результатом обноления во всём каталоге и влияет на прочие стороны. Данный раздел предоставляет подробности такого процесса переименования домена и его взаимодействие с AD DS (Службами каталога Active Directory), DNS, Групповой политикой и безопасностью.

Имеется обязательное требование того, чтобы вы не пытались предпринимать некую операцию переименования домена пока вы не прочтёте и не поймёте всё содержимое данного технического руководства. Описываемая операция переименования домена не поддерживается в Microsoft Exchange Server 2007 или Exchange Server 2010. Переименование домена DNS поддерживается только в Microsoft Exchange Server 2003. Однако переименование всех имёно домена NetBIOS не поддерживается ни в какой версии Exchange Server. Прочие приложения не Microsoft также могут не поддерживать переименование домена. Для дополнительной информации о прочих приложениях Microsoft, которые не совместимы с переименованием домена ознакомьтесь со статьёй 300684 в базе знаний Microsoft.

 

Правила для сформированного надлежащим образом леса

Те возможности переименования домена, которые имеют результатом полное перестроение некоторого леса, поддерживают любой набор изменений во всех именах DNS и именах NetBIOS (network basic input/output system) этих доменов в некотором лесу, что приводит к "правильному формированию леса".

В правильно сформированном лесу являются истинными следующие условия:

 

Условия переименования домена и последствия для обслуживания

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

В рассматриваемый процесс переименования домена встроены следующие условия и последствия:

 

Процессы и взаимодействия переименования домена

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

 

Инструмент переименования домена Rendom

Rendom.exe является утилитой командной строки для переименования доменов. Rendom содержится на CD операционной системы Windows Server 2003. Однако в Инструментарии переименования домена (Domain Rename Tools) Windows Server 2003 на веб сайте Microsoft доступна некая обновлённая версия Rendom. Эта версия Rendom делает возможным переименование домена в лесу, который имеет развёрнутым Exchange Server 2003 с SP1.

Rendom.exe встроена в контроллеры домена, исполняющиеся под Windows Server 2008 R2 и Windows Server 2008. Она также доступна в RSAT (Remote Server Administration Tools).

 

Файл состояния переименования домена

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

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

 

Состояния контроллера домена

Rendom записывает четыре состояния выполнения для каждого контроллера домена в своём файле состояния:

Те шаги в процедуре переименования домена, которые пытаются перевести некий контроллер домена из состояния Initial в состояние Prepared, а также из состояния Prepared в состояние Final могут быть исполнены только после того как все контроллеры домена в данном лесу достигли требуемого состояния. Некий шаг может быть выполнен множество раз для некоторых контроллеров домена, которые не могут быть достигнуты после начальной попытки. Каждое такое дополнительное исполнение одного и того же этапа пытается взаимодействовать только с теми контроллерами домена, которые не достигли требуемого состояния.

Для получения дополнительной информации по файлу состояния ознакомьтесь с Domain Rename Script and State File.

 

Общие этапы в процессе переименования домена

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

Основными этапами в вашей процедуре переименования домена являются:

 

Требования для переименования домена

Прежде чем начнётся операция переименования домена должны быть выполнены следующие требования:

 

Требования функционального уровня леса

Данная операция переименования домена поддерживается в некотором AD DS если - и только если - никакие контроллеры в данном лесу не исполняются под управлением Windows 2000 Server и уровень функциональности данного леса был повышен до Windows Server 2003 или выше. Повышение имеющегося уровня функционирования до Windows Server 2003 требует чтобы все домены в данном лесу имели некий уровень функционирования по крайней мере естественный Windows 2000, причём вне зависимости от того какие домены переименовываются.

Для получения дополнительной информации об уровнях функционирования леса и домена ознакомьтесь с Active Directory Functional Levels Technical Reference.

 

Требования доверительных взаимоотношений

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

 

Типы доверительных взаимоотношений

Некая иерархия доменов AD DS реализуется доверительными взаимоотношениями между доменами. Между доменами в некотором лесу AD DS устанавливаются следующие типы доверительных взаимоотношений:

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

 

Предварительное создание доверительных взаимоотношений для перестраиваемого леса

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

 

Предварительное создание доверительных взаимоотношений родитель- потомок

В качестве примера предположим, что компания Coho Winery желает перестроить свой лес cohowinery.com таким образом, чтобы его домен products.sales.cohowinery.com стал потомком домена cohowinery.com. Прежде чем операция переименования домена осуществится для того чтобы обслужить такое перестроение, вначале должно быть создан некий ярлык двустороннего, транзитивного доверительного взаимоотношения между products.sales.cohowinery.com и cohowinery.com. Такое доверительное взаимоотношение устанавливает необходимую основу для того двунаправленного доверительного взаимоотношения предок- потомок, которое потребуется для получаемых в результате родительского и дочернего доменов.

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

 

Предварительное создание множественных доверительных взаимоотношений родитель- потомок

Для сценариев, в которых вы желаете перестроить некий домен, который является и доменом потомком, и родительским доменом, вам следует создать ярлыки доверительных взаимоотношений в двух местах. Например, предположим что компания Coho Winery желает перестроить имеющийся лес cohowinery.com с тем, чтобы переместить hr.sales.cohowinery.com таким образом, чтобы он стал потомком домена eu.cohowinery.com. В то же самое время эта компания желает сделать его дочерний домен, payroll.hr.sales.cohowinery.com, прямым потомком являющегося в настоящее время его прародителем домена sales.cohowinery.com. Для выполнения этой операции должны быть созданы ярлыки доверительных взаимоотношений, которые станут доверительными взаимоотношениями для их нового леса после его перестроения следующим образом:

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

 

Предварительное создание доверительных взаимоотношений некоторого корня дерева c первым корневым доменом леса

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

Например, допустим что имеется некое глубокое дерево в лесу cohowinery.com и компания Coho Winery желает создать некое новое дерево переместив домен самого нижнего уровня, eu.sales.cohowinery.com с тем, чтобы он стал неким доменом корня дерева. Последующий рисунок отображает тот двунаправленный ярлык доверительных взаимоотношений который создаётся, а также то доверительное взаимоотношение дерево- корень, которое оно предоставляет после перестроения, когда домен eu.sales.cohowinery.com переименован с тем, чтобы создать домен корня дерева cohovineyardandwinery.com.

 

Требования зон DNS

Когда некое приложение или клиент запрашивают доступ к AD DS, механизм локатора (Locator) определённого контроллера домена находит некий сервер AD DS (то есть некий контроллер домена).

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

Такие требования DNS для переименования некоторого AD DS домена идентичны аналогичным требованиям DNS для поддержки некоторого имеющегося домена AD DS. Ваша текущая инфраструктура DNS уже предоставляет всю необходимую поддержку для применения текущего имени вашего домена AD DS. Обычно вы просто зеркалируете имеющуюся инфраструктуру DNS чтобы добавить поддержку такого нового имени вашего домена.

Например, предположим, что Coho Vineyard желает переименовать имеющийся у неё домен AD DS sales.cohovineyard.com в marketing.cohovineyard.com. Если те записи ресурсов SRV, которые зарегистрированы контроллерами доменов в том домена AD DS, который имеет название sales.cohovineyard.com, зарегистрированы в соответствующей зоне DNS с именем sales.cohovineyard.com, должна быть создана некая новая зона DNS с названием marketing.cohovineyard.com, чтобы соответствовать созаваемому новому имени такого домена AD DS.

Для получения дополнительной информации о том как DNS предоставляет поддержку для AD DS ознакомьтесь с DNS Support for Active Directory Technical Reference. Для получения дополнительной информации по Локатору, ознакомьтесь с Locator mechanism.

 

Требования перенаправления папки и роуминга профиля пользователя

Если вы применяете Перенаправление папки (Folder Redirection) или роуминг (поддержку постоянного контакта) профиля пользователя, вам может понадобиться изменить все сетевые пути для них перед выполнением своей операции переименования домена. Если вы поместили Перенаправление папки или роуминг профилей пользователя (и соответствующие домашние каталоги) в некоторое сетевое местоположение с применением пространства имён DFS (Distributed File System, Распределённой файловой системы) на основе домена, тогда переименование такого домена сделает неверным данный путь к такому пространству имён на основе домена и Перенаправленная папка или роуминг профилей пользователя, которые применяют данный путь прекратят свою работу. Для роуминга профилей пользователя это остановит регистрацию пользователя пока все пути не будут исправлены. Однако, если такое имя NetBIOS некоторого домена применяемого для соединения с неким пространством имён DFS на основании домена не изменено в процессе операции изменения имени домена, такой путь к данному пространству имён DFS на основе домена продолжит оставаться правильным. То же самое верно для FQDN (fully qualified domain name, полностью определённого имени домена); если данное FQDN имя некоторого домена применяется для соединения с неким пространством имён DFS на основе домена и такое FQDN имя данного домена не изменено в процессе операции переименования домена, данный путь к пространству имён DFS на основе домена продолжит оставаться верным. Если вы совсем не используете пространства имён DFS и пути к именам серверов не определяются при помощи FQDN, все пути продолжат оставаться верными.

Для получения дополнительной информации ознакомьтесь с Relocate Folder Redirection and Roaming User Profiles.

 

Требования имени хоста компьютера

По умолчанию имеющийся первичный суффикс DNS некоторого компьютера участника какого- либо домена AD DS настроен на автоматическое изменение при изменениях данного компьютера в членстве в домене. точно такое же поведение по умолчанию верно в случае, когда изменяется данное имя DNS текущего домена к которому присоединён некий компьютер. таким образом, некое переименование какго бы то ни было домена AD DS может вызвать изменение данного первичного суффикса DNS и, в конечном итоге, всех полных имён DNS хостов данных компьютеров, которые являются участниками данного переименованного домена.

Например, если домен sales.cohowinery.com переименовывается в marketing.cohowinery.com, имеющийся первичный суффикс DNS всех компьютеров участников данного домена может также измениться с sales.cohowinery.com на marketing.cohowinery.com в зависимости от того имеет ли своё действие поведение по умолчанию. Если установленное по умолчанию поведение действительно, всё полное имя DNS хоста компьютера в таком переименованном домене будет изменено с hostNamesales.cohowinery.com на hostNamemarketing.cohowinery.com.

 

Условия для автоматического изменения имени хоста компьютера

Текущий первичный суффикс DNS и, следовательно, имеющееся полное имя DNS некоторого компьютера участника в каком- то домене AD DS изменяется при переименовании данного домена если верны оба следующих условия:

 

Эффекты репликации переименования большого числа компьютеров

Если являются верными все условия, которые предписывают автоматическое обновление имеющегося первичного суффикса DNS для всех компьютеров в имеющемся домене, а также если имеется большое число компьютеров участников в таком домене, которые подлежат переименованию, тогда репликация столь больших изменений может повлечь чрезмерный обмен в вашей сети. Такой обмен репликациями, который является результатом от подлежащих изменению большого числа имён компьютеров является функцией от общего числа компьютеров, которые являются участниками данного переименованного домена. Данный "штром" репликаций, который может быть результатом подлежащих переименованию тысяч имён компьютеров примерно в одно и то же время является проблемой исключительно для самых крупных реализаций. Вы можете избежать этого условия изменив все установки с указывающих на автоматическое обновление имеющегося первичного суффикса DNS. Если вы не считаете что такой получаемый в результате обмен репликациями вызовет некие проблемы для вашей инфраструктуры (то есть риска некоторой перегруженности или насыщения сетевой среды), такой подготовительный шаг не является обязательным.

Некое изменение имени компьютера переключает обновление имеющихся атрибутов dnsHostName и servicePrincipalName для соответствующей учётной записи AD DS компьютера. Обычно эти атрибуты обновляются в процессе перезагрузки такого компьютера участника, как это требуется рассматриваемой процедурой переименования домена после того, как такой домен переименован. Обновление этих атрибутов на некотором большом числе компьютеров в каком- то коротком промежутке времени может переключить активность репликаций, которая насытит вашу сеть. Более того, некое изменение имени компьютера переключает обновление всех записей ресурсов DNS адресов хоста (A) и указателей (DNS) в имеющеся базе данных DNS. Такие обновления также вызывают дополнительный обмен репликаций, вне зависимости от того хранятся ли зоны DNS в AD DS или в некотором другом хранилище DNS. По этим причинам вам следует подготовиться к данной операции переименования домена на будущее путём перенастройки имеющегося по умолчанию поведения, которое изменяет имеющийся в компьютерах участниках первичный суффикс DNS после того как некий домен оказался переименованным.

 

Пересмотр Групповой политики самого первого суффикса DNS перед некоторым переименованием домена

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

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

Для установки необходимого первичного суффикса DNS для своего домена в качестве используемого нового DNS имени домена вы можете воспользоваться установкой Групповой политики Primary DNS Suffix. Когда эта установка Групповой политики вступит в действие, она перепишет имеющееся по умолчанию поведение изменения текущего первичного суффикса DNS при изменениях имени DNS данного домена. В этом случае все имена компьютеров остаются теми же самыми при переименовании вами домена и репликации изменений имён не происходят.

Однако, так же как автоматическое изменение имеющегося первичного суффикса DNS вызывает репликацию, Primary DNS Suffix также вызывает репликацию. По этой причине Групповая политика должна применяться при организации к компьютерам участникам. Чтобы применить Групповую политику ко всем компьютерам участникам в данном домене или подлежащих переименованию доменах - и в то же время также избежать репликации в некотором большом масштабе, поделите объекты сомпьютеров между различными местоположениями в AD DS либо по Подразделениям (OU, organizational units), либо по площадкам (sites), либо по обоим.

 

Настройка требований перед применением Групповой политики

Когда вы применяете установки Primary DNS Suffix, имеющийся суффикс DNS компьютеров участников более не соответствует имеющемуся имени DNS того домена, участником которого они являются. Чтобы позволить всем компьютерам участникам некоторого домена иметь некий первичный суффикс, который не соответствует имеющемуся DNS имени домена, вы должны вначале настроить такой домен на принятие тех имён, которые могут иметь данный суффикс DNS. Такая настройка должна быть размещена на своём месте до того как вы установите Групповую политку для применения некоторых установк компьютеров.

Имеющийся атрибут msDS-AllowedDNSSuffixes со многими значениями определённого объекта домена (для данного домена это объект domainDns) содержит некий список суффиксов DNS, которые могут иметь компьютеры участники домена AD DS. Установка Primary DNS Suffix текущей Групповой политики применяет все значения из этого атрибута. Изменяя данный атрибут добавив необходимый первичный суффикс DNS планируемого нового домена, вы делаете для Групповой политики возможным установить такое новое имя домена в качестве имеющегося первичного суффикса DNS.

 

Требования CA

Управление корпоративными сертификатами может продолжаться на протяжении некоторой процедуры переименования домена когда вступают в действие следующие требования перед переименованием домена:

Если имеется одно из приведённых ниже условий на момент переименования домена, управление CA не поддерживается:

Для получения дополнительной информации о сертификатах и CA ознакомьтесь с Certificates Technical Reference и CA Certificates Technical Reference.

 

Определение структуры вашего целевого леса

После того как вы запланировали переименование своего домена, вы начинаете этот процесс переименования домена с использованием инструмента переименования домена (Rendom) чтобы сделать некий перечень всех имеющихся имён домена, включая имена разделов каталога приложений, в своей текущей структуре леса. После того как вы примените Rendom для создания такого перечня, вы создаёте нужную вам новую структуру леса путём изменения всех имён в данном пееречне. В соответствии с имеющейся схемой именования иерархии DNS вся структура такого леса подразумевается в множестве имён DNS для всех доменов и всех разделов каталога приложений, которые создают данный лес. В добавление к определению изменений имён DNS для доменов и разделов каталога приложений вы можете также изменить имеющееся имя NetBIOS любого домена. Поддерживаются изменения имён доменов DNS и NetBIOS, а также всех имён DNS разделов каталога приложений, составляющих данный лес, с учётом всех ограничений, описанных в "Ограничения и возможности переименования домена" из Что такое переименование домена? (перевода What Is Domain Rename?).

 

Текущие имена домена: создание вашего Файла описания леса

Команда rendom /list создаёт текущее описание леса и записывает его в некий файл вывода (который по умолчанию имеет название rendom /list) с применением некоторой закодированной в XML структуры. Этот файл содержит некий список всех доменов и разделов каталога приложений в вашем лесу совместно с их соответствующими именами DNS и NetBIOS. (Разделы каталога приложений не имеют имён DNS.) Все домены и разделы каталога приложений также определяются неким GUID (globally unique identifier, глобально уникальным идентификатором), который не изменяется при каком- либо переименовании домена. Чтобы упростить такую новую структуру леса, Rendom автоматически получает и компилирует всю имеющуюся текущую структуру леса таким образом, чтобы требуемая новая структура леса могла быть наложена поверх данной текущей структуры леса.

Следующий рисунок отображает некий пример файла описания леса который сгенерирован для некоторого леса, имеющего дерево доменов с названием cohovineyard.com (самый первый корневой домен леса), sales.cohovineyard.com и hr.sales.cohovineyard.com, а также четыре раздела каталога приложений с названиями DomainDnsZones.hr.sales.cohovineyard.com, DomainDnsZones.sales.cohovineyard.com, DomainDnsZones.cohovineyard.com и ForestDnsZones.cohovineyard.com, которые используются в DNS. В данном примере неизменяемые значения обозначаются жирным текстом.

Файл описания леса (Domainlist.xml) после выполнения команды rendom /list

<Forest>
<Domain><!-- PartitionType:Application --><GUID>78438a56-f4a7-383a-5c82-fe05a76ed464</GUID><DNSname>DomainDnsZones.hr.sales.cohovineyard.com</DNSname>
    <NetBiosName></NetBiosName><DcName></DcName></Domain><Domain>
    <GUID>89cf8ae3-f4a3-453b-ac5c-cb05a76bca40</GUID>
    <DNSname>hr.sales.cohovineyard.com</DNSname><NetBiosName>HR</NetBiosName><DcName></DcName></Domain><Domain><!-- PartitionType:Application --><GUID>b9748a56-c4a7-385a-5d84-7490e76ba484</GUID><DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname><NetBiosName></NetBiosName><DcName></DcName></Domain><Domain><GUID>89238a56-f3a1-343b-bc5c-cb05a76bc341</GUID><DNSname>sales.cohovineyard.com</DNSname>
    <NetBiosName>SALES</NetBiosName><DcName></DcName></Domain><Domain><!-- PartitionType:Application --><GUID>ea658a56-f4a7-383a-5c82-cb05a76bdf35</GUID><DNSname>DomainDnsZones.cohovineyard.com</DNSname><NetBiosName></NetBiosName><DcName></DcName></Domain><Domain><!-- PartitionType:Application --><GUID>ea658a56-f4a7-383a-5c82-cb05a76bd461</GUID>
    <DNSname>ForestDnsZones.cohovineyard.com</DNSname><NetBiosName></NetBiosName><DcName></DcName></Domain><Domain><! — ForestRoot --><GUID>34fg8ae3-f4a3-453b-ac5c-3ce5a76bca42</GUID><DNSname>cohovineyard.com</DNSname><NetBiosName>COHOVINEYARD</NetBiosName><DcName></DcName></Domain></Forest>
 	   

 

Имена целевого домена: изменение вашего Файла описания леса

Создаваемый командой rendom /list файл описания текущего леса является текстовым файлом, который вы можете изменять для выражения структуры целевого леса в качестве новых имён домена. Для представления нужной вам новой структуры вы просто изменяете поля <DNSname> и <NetBiosName> с тем, чтобы они содержали те новые имена, которые требуются вам.

Например, применяя предыдущий файл описания леса, если вы хотите изменить имеющееся имя своего домена hr.sales.cohovineyard.com на payroll.sales.cohovineyard.com и поменять его имя NetBIOS с HR на PAYROLL вы заменяете имеющиеся переменные значения в соответствующих строках в данном файле описания леса как это показано ниже (Неизменные значения обозначены жирным текстом):

Основываясь на такой новой структуре леса Rendom считывает информацию для каждого домена из текущего каталога и затем создаёт некий набор инструкция обновления каталога. По умолчанию вся собираемая Rendom информация отыскивается во всех доступных контроллерах домена в каждом домене. Однако у вас имеется вариант определить некий конкретный контроллер домена в каждом домене из которого требуется забирать всю необходимую для создания инструкций обновления планируемого изменения домена. Чтобы воспользоваться такой возможностью просто добавьте нужное DNS имя хоста требующегося контроллера домена в поле <DNSname></DNSname> в своём файле описания леса.

После того как вы измените свой файл описания леса, вы можете воспользоваться командой Rendom /showforest для отображения создаваемой новой структуры леса, которая содержится в данном файле. (Эта команда не имеет никакого воздействия на имеющийся каталог сам по себе.) Дружественный пользователю формат применяет отступы для отображения имеющейся иерархии домена в данном лесу.

 

Передача Инструкций переименования домена в AD DS

После того как вы создадите такую новую структуру изменив свой файл описания леса следующий этап состоит в самом процессе переименования домена, влекущего за собой трансляцию изменённой новой структуры леса в некую последовательность инструкций обновления каталога которые будут исполняться по отдельности на каждом контроллере домена в данном лесу. Трансляция выполняется когда вы выполняете команду rendom /upload и получаемый в результате инструкции переименования домена разгружаются (upload) в раздел настройки каталога того контроллера домена, который в настоящее время в данном домене именуется хозяином операций (operations master) для рассматриваемого леса. Все инструкции затем реплицируются во все прочие контроллеры домена в данном лесу посредством обычных репликаций данного раздела настроек каталога. Только после этого инструкции переименования реплицируются на все контроллеры домена в данном лесу и проверяются все необходимые условия в каждом контроллере домена, которые все контроллеры домена продолжат при выполнении данных инструкций переименования.

Следующий раздел описывает все подробности тех изменений, которые вырабатываются выполненной командой rendom /upload. Действительная последовательность действий которая происходит в ответ на эту команду описываются в подразделе Выполняемые Rendom действия в ответ на команду rendom /upload далее в этом разделе.

 

Сценарий переименования домена и файл состояния

Чтобы преобразовать имеющуюся в настоящее время структуру леса в целевую структуру Rendom транслирует имеющееся новое описание леса в набор неких инструкций обновления которые данный контроллер домена применяет для обновления своих реплик разделов каталога чтобы в действиельности выполнить все изменения имён. Выполненная команда rendom /upload создаёт все необходимые инструкции переименования домена, которые кодируются в специальном формате сценария, являющимся частной собственностью (закрытым) в своей реализации. Данная команда rendom /upload также создаёт необходимый файл состояния который применяется для отслеживания всего протекания планируемой операции переименования домена.

 

Сценарий переименования домена для обновления Инструкций

Тот сценарий, который создаётся выполнением команды rendom /upload является внутренним, частным для конкретной процедуры переименования домена и он не производит определённых изменений в самом каталоге. Вместо этого данный сценарий предоставляет инструкции для контроллеров домена которые они исполняют в виде ответа на команды Rendom. Данный сценарий является закодированным в некотором XML виде документе который имеет три компоненты:

 

Файл состояния для отслеживания

В процессе трансляции рассматриваемого описания леса в конкретный сценарий инструкций обновления и передачи этого сценария содержащего все описания в требуемый каталог Rendom также создаёт необходимый ему файл состояния (который по умолчанию имеет название DClist.xml). Этот файл имеет структуру текстового документа в виде XML для обслужвания отслеживания состояния всех контроллеров домена при прохождении ими различных этапов общего процесса переименования домена. Данный файл содержит некоторую запись для каждого контроллера домена в данном лесу. Каждый контроллер домена определяется его DNS именем хоста совместно с полями для его текущего состояния и самой последней ошибкой произошедшей в данном контроллере домена при выполнении им инструкций переименования домена.

 

Подготовка контроллеров домена для переименования домена

Когда вы исполняете команду rendom /upload, в имеющихся именованиях домена хозяина исполнения (operations master) происходят определённые изменения в подготовке для реального исполнения переименования домена. В данном хозяине именования домена созданный сценарий в XML- коде, который содержит все инструкции переименования домена записывается в атрибут восьмибитовой строки с единственным значением msDS-UpdateScript в определённом объекте контейнера раздела (cn=partitions,cn=configuration,dc=ForestRootDomain) в соответствующем разделе настроек каталога. Такой контейнер Разделов (Partitions) может обновляться только в том контроллере домена, который является в настоящее время хозяином именования домена (domain naming master) для данного леса; данный атрибут msDS-UpdateScript обязательно изменяется в данном контроллере домена, который содержит все необходимые операции роли хозяина по переименованию домена (также имеющим название роли FSMO, flexible single master operations, операций с единым исполнителем). Из такого контроллера домена источника данный сценарий, который сохраняется в соответствующем атрибуте msDS-UpdateScript реплицируется во все контроллеры домена в данном лесу посредством обычных репликаций данного раздела настроек каталога.

 

Установка некоторого алиаса DNS для нового имени домена

Помимо описанного значения msDS-UpdateScript, записываемого в соответствующий контейнер Разделов все новые имена DNS каждого подлежащего переименованию домена также записываются Rendom в атрибут с Unicode- строкой и единственным значением msDS-DnsRootAlias в объекте перекрёстной ссылки (класса crossRef), который относится к данному домену. Опять же, так как объекты перекрёстных ссылок хранятся в контейнерах Разделов (Partitions) и такой контейнер Разделов может обновляться только в единственном хозяине именования домена, данный атрибут msDS-DnsRootAlias может быть изменён только в том контроллере домена, который содержит такую роль хозяина операций именования домена. Из такого контроллера домена источника данное имя DNS в таком атрибуте msDS-DnsRootAlias реплицируется во все котнроллеры домена в данном лесу посредством обычных репликаций в имеющемся разделе настроек каталога.

 

Механизм локатора

Клиентам AD DS требуется DNS для того, чтобы они могли определять местоположение контроллеров домена. Данный Локатор (Locator) является алгоритмом обнаружения наилучшего контроллера домена для некоторого запроса на основании сетевой близости с применением записей ресурсов которые зарегистрированы контроллерами домена в DNS. В процессе установки AD DS необходимые записи ресурсов SRV и A динамически регистрируются в DNS имеющейся службой Net Logon (Сетевой регистрации). Оба типа записей необходимы для функционирования описываемого мехонизма Локатора. Чтобы отыскать контроллеры домена в некотором лесу доменов, любой клиент запрашивает у DNS записи ресурсов SRV и A требующегося контроллера домена. Данные записи ресурсов снабщают этого клиента необходимыми именами и IP адресом нужных контроллеров домена. В этом контексте такие записи ресурсов SRV и A называются записями ресурса DNS (DNS resource records). Каждый контроллер домена также регистрирует некую запись канонического имени (CNAME) для использования при репликации AD DS.

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

Owner name    time to live    record class    record type    data/host name
 	   

В соответствии с полученным от клиента запросом данный Локатор может применять различные определённые критерии, которые соответствуют значениям в таких записях ресурсов SRV для определения местоположения контроллеров домена с определёнными ролями или возможностями. Например, данный Локатор может обнаружить некий контроллер домена, который имеет какую- то полную, записываемую реплику неоторого раздела каталога домена; какую- то реплику домена в некоторой определённой площадке (site); либо какой- то контроллер домена, который является сервером глобального каталога. Данное имя владельца в некоторой записи ресурса SRV предоставляет такую специфическую информацию о соответствующем типе контроллера домена подлежащего локализации. Например, какой- то контроллер домена может располагаться в некоторой определённой площадке с применением следующего формата:

_Service._Protocol.SiteName._sites.DnsDomainName
 	   

Следующее имя владельца в какой- то записи ресурса SRV определяет некоторый контроллер домена определяемый той службой LDAP, которая исполняется поверх протокола TCP) на конкретной площадке (site) East в имеющемся домене Cohowinery.com:

_ldap._tcp.east._sites.cohowinery.com
 	   

Для получения дополнительной информации об обсуждаемом Локаторе и всех записях ресурсов DNS которые регистрируются неким контроллером домена ознакомьтесь с How DNS Support for Active Directory Works.

 

Публикация двух наборов записей ресурса SRV локатора в DNS

Обсуждаемая служба каталога расширена в лесах Windows Server 2003 и более поздних версий для применения атрибута msDS-DnsRootAlias с целью поддержки описанной концепции некоторого алиаса для любого домена. наличие данного атрибута предписывает службе Сетевой регистрации (Net Logon) исполняющейся в таком контроллере домена зарегистрировать данное значение DNS имени домена этого атрибута в DNS.

При добавлении такого атрибута msDS-DnsRootAlias имеющаяся служба Сетевой регистрации имеет возможность зарегистрировать не одно, а дав имени домена в DNS. Полная идентичность имеющегося реального (первоначального) имени домна и его алиаса (цели) имени домена устанавливается за счёт публикации двух наборов записей ресурсов в DNS, а именно:

Отметим, что в той опубликованной записе ресурса SRV, которая относится к данному алаисному имени домена имеющееся в ней поле владельца отражает такое новое имя домена, вне зависимости от того, что само поле имени хоста отражает самое настоящее имя DNS своего контроллера домена. Например, если наш домен cohovineyard.com переименовывается в cohowinery.com, имеющаяся служба Сетевой регистрации публикует две следующие записи ресурсов SRV для выполняющейся в некотором контроллере домена службы LDAP с именем DC01 для такого домена:

_ldap._tcp.cohovineyard.com  SRV  0  0  389  dc01.cohovineyard.com
_ldap._tcp.cohowinery.com  SRV  0  0  389  dc01.cohovineyard.com
 	   

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

 

Предварительная публикация записей CNAME для репликации

Весь набор относящихся к домену записей ресурсов которые публикуются в DNS службой Сетевой регистрации (Net Logon) исполняющейся в каком- то контроллере домена содержат некоторую запись CNAME DNS, которую AD DS применяет для репликации.

<DsaGuid>._msdcs.<DnsForestName>.
 	   

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

Для нахождения своего партнёра по репликации данному контроллеру домена необходимо знать только сам GUID того объекта DSA (directory system agent, системного агента каталога) для которого контроллер домена (который представлен DsaGuid в данной записи CNAME). Данный GUID DSA является самим GUID Объекта установок NTDS (класса nTDSDSA). Его значение хранится в атрибуте objectGUID того Объекта установок NTDS, который является потомком объекта сервера данного контроллера домена. Этот объект располагается в контейнере Площадки (Site) в имеющемся разделе настроек каталога. Если самый первый корневой домен леса подлежит переименованию, является существенным то, что эта запись CNAME заблаговременно публикуется в DNS с тем, чтобы репликации продолжали работать после обновления изменений доменного имени самого первого корня леса некоторого контроллера домена. Если такие записи CNAME DNS для имеющегося нового самого первого корневого имени домена не опубликованы заблаговременно для каждого контроллера домена, а записи для имеющегося старого самого первого имени корня реплицируются по серверам DNS, которые используют AD DS для хранения зон DNS, репликации прерываются в результате некоторого условия зацикливания. Данное условие вырабатывает следующую ошибку: "Cannot replicate because the CNAME record cannot be read from the local DNS replica; the CNAME record is not present in the local DNS replica because it is not replicating." (Репликация невозможна из- за того, что определённая запись CNAME не может быть прочтена из имеющейся локальной реплики DNS; данная запись CNAME не представлена в имеющейся локальной реплике DNS так как она не может быть реплицирована.) Предварительная публикация всех записей DNS сокращает тот период, на протяжении которого данная служба каталога недоступна на протяжении перестройки всего леса.

Отметим, что в предварительно опубликованной записи ресурса CNAME, которая соответствует требуемому новому имени леса, соответствующее поле владельца отражает такое новое имя леса, а имеющееся поле имени хоста отражает реальное имя DNS данного контроллера домена. Например, если имеющийся лес cohovineyard.com переименовывается в cohowinery.com, службой Сетевой регистрации для некоторого контроллера домена с названием DC01 в этом домене публикуются две следующих записи ресурсов CNAME:

<DsaGuid>.cohovineyard.com  IN  CNAME  dc01.cohovineyard.com
<DsaGuid>.cohowinery.com  IN  CNAME  dc01.cohovineyard.com
 	   

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

Прежде чем весь процесс переименования домена может быть продолжен на следующем этапе, все предварительно опубликованные записи CNAME, соответствующие имеющимся в msDS-DnsRootAlias значения должны быть реплицированы во все сервера DNS, которые авторизованиы для таких записей.

 

Установка SPN для некоторого нового имени домена

Имеющийся в каждом контроллере домена DSA записывает набор SPN в атрибут с названием servicePrincipalName в конкретном объекте компьютера контроллера домена в имеющемся разделе каталога домена. Помимо прочих вещей SPN применяются для взаимной аутентификации между контроллерами домена в процессе репликации AD DS. Тот определённый SPN, который применяется для взаимной аутентификации между пратнёрами репликации имеет следующий формат из трёх частей:

E3514235-4B06-11D1-AB04-00C04FC2DCD2/<DsaGuid>/<DnsForestName>
 	   

где первая часть является определённым GUID интерфейса RPC (remote procedure call) для репликации AD DS, вторая часть является GID для объекта DSA данного контроллера домена, а третья часть является именем DNS для вашего самого первого корневого домена леса.

 

Предварительная публикация двух наборов SPN

Вскоре после того как определённое значение для атрибута msDS-DnsRootAlias в объекте перекрёстной ссылки установлено в некотором контроллере домена, либо посредством первоначальной записи, либо некоторой записью репликации, имеющийся в таком контроллере домена DSA перезаписывает все SPN в объекте компьютера данного контроллера домена таким образм, что каждый SPN, который содержит определённое имя домена (или самое первое корневое имя леса) представлено в двух видах - одном для реального имени домена (или корня леса) и одном для определённого алиаса, который сохраняется в данном аторибуте объекта перекрёстной ссылки msDS-DnsRootAlias этого домена (или корне леса). Те значения SPN, которые относятся к алиасу данного имени домена требуют предварительной публикации по той же самой причине, по которой её требуют записи CNAME DNS, то есть для урезания некоторого циклического условия, которое производит следующую ошибку: "Cannot replicate because the SPN needed for mutual authentication cannot be read from the directory replica; the required SPN value is not present in the directory replica because it is not replicating." (Репликация невозможна из- за того, что определённое значение SPN, необходимое для встречной аутентификации не может быть прочтено из имеющейся реплики каталога; требуемое значение SPN не представлено в имеющейся реплике каталога так как она не может быть реплицирована.) Предварительная публикация данных SPN сокращает тот период времени, на протяжении которого данная служба каталога является недоступной в процессе перестройки данного леса.

Прежде чем данный процесс переименования домена сможет продолжиться на следующем этапе, все предварительно опубликованные SPN, которые относятся ко всем имеющимся в msDS-DnsRootAlias значениям, должны быть реплицированы во все контроллеры домена в данном домене, а также во все серверы глобального каталга в данном лесу.

 

Выполняемые Rendom действия в ответ на команду rendom /upload

В ответ на команду rendom /upload выполняется следующая последовательность действий:

На своей управляющей станции (том компьютере, с которого исполняется данная команда Rendom), Rendom записывает некий новый файл состояния для отслеживания всего процесса для всех контроллеров домена в данном лесу. Данный файл состояний содержит некую запись для каждого контроллера в данном лесу, причём все записи контроллеров домена помечены таким образом, чтобы находиться в состоянии Initial.

 

Побочный эффект команды rendom /upload в настройке леса

Если после того как началась данная операция в этом лесу выполняются определённые изменения, такие изменения могут повлиять на результат всего процесса переименования и вызвать его отказ таким образом, что некоторые из участвовавших в нём контроллеров могут больше никогда не завершить такой процесс переименования домена. Для предотвращения подобной ситуации успешное исполнение команды rendom /upload замораживает имеющуюся настройку леса по отношению к изменениям таких видов после начала рассматриваемой операции. Приводимые ниже операции не могут осуществляться в некотором лесу после успешного выполнения команды rendom /upload:

Данная настройка леса остаётся замороженной на протяжении того времени, пока имеющийся в соотвествующем контейнере разделов (Partitions) атрибут msDS-UpdateScript имеет некоторое значение, которое отображает тот факт, что выполняется какая- то операция переименования домена. Вся конфигурация леса становится размороженной по определённому завершению данной операции переименования домена через исполнение команды rendom /end.

 

Проверка готовности контроллера домена

Данный этап рассматриваемого процесса переименования домена проверяет что имеющиеся в каждом контроллере домена данного леса базы данных каталога подготовлены надлежащим образом для исполнения всех тех изменений, которые предписываются имеющимся в атрибуте msDS-UpdateScript сценарии. В ответ на команду rendom /prepare, выполняются все необходимые проверки во всех контроллерах домена путём выполнения определённого тестового компонента имеющегося в msDS-UpdateScript сценария в виде некоторой транзакции в режиме только для чтения в каждой локальной базе данных каталога. Данный тест проверяет следующие условия:

Кроме того, данный тест содержит некую проверку авторизации в каждом контроллере домена на предмет того имеет или тот пользователь, который исполняет данную команду rendom /prepare авторизацию на исполенение данных инструкций переименования домена которые содержатся в msDS-UpdateScript. Такая проверка атроизации сверяется с тем, что данный пользователь имеет полномочия на запись в данный атрибут msDS-UpdateScript в соответствующем контейнере Разделов (Partitions). Если этот пользователь не авторизован, данная команда завершается неудачно.

 

Выполняемые Rendom действия в ответ на команду rendom /prepare

В ответ на команду rendom /prepare происходит следующая последовательность действий:

 

Выполнение инструкций переименования домена

На окончательном этапе рассматриваемого процесса переименования домена все базы данных каталога во всех контроллерах домена в данном лесу обновляются в индивидуальном порядке для реализации необходимой новой структуры леса. Этот процесс не полагается на репликации AD DS. Вместо этого, имеющаяся компонента действия в исполняемом сценарии в msDS-UpdateScript выполняет все необходимые изменения в соответствующей базе данных каталога локально в каждом контроллере домена в виде некоторой отдельной транзакции обновления. Такая компонента действия данного сценария в действительности обновляет необходимое имя домена. Данный окончательный этап исполняет команда rendom /execute .

 

Однопользовательский режим

Чтобы выполнить имеющуюся компоненту действия исполняемого сценария msDS-UpdateScript, все лужбы каталога во всех контроллерах домена входят в специальный режим, который имеет название Однопользовательского режима (single-user mode). В однопользовательском режиме AD DS отвергает обслуживание всех обычных клиентов данной службы каталога, включая LDAP, MAPI (Messaging API), репликацию, SAM (Security Accounts Manager, Диспетчер безопасных учётных записей), kerberos, а также прочие RPC обслуживания каталога. В данном режиме только сама служба каталога по себе может осуществлять чтение и запись в имеющуюся локальную базу данных каталога, причём применяя единственный поток. такой однопользовательский режим необходим, посколку все обновления имени домена, котрые выполняет данная служба каталога делают недействительной структуру данных внутреннего каталога. После того как данная служба каталога выполнит эти изменения в однопользовательском режиме, данный контроллер домена перегружается. После этой перезагрузки имеющиеся внутренние структуры данных перестраиваются в непротиворечивое состояние.

 

Транзакция обновления

Все те обновления каталога, которые определены в имеющейся компоненте действия исполняемого сценария msDS-UpdateScript выполняются внутри некоторой ESE (Extensible Storage Engine, Расширяемого механизма хранения) транзакции базы данных. если не происходит никаких ошибок, данная транзакция фиксируется; в противном случае вся транзакция откатывается обратно. Контроллеры домена, которые зафиксированли данную транзакцию обновления в однопользовательском режиме и затем выполнили перезагрузку рассматриваются как имеющие выполненное данное переименование домена.

 

Вход в однопользовательский режим

В качестве части некоторой успешной транзакции обновления, конкретный нереплицируемый атрибут msDS-ReplicationEpoch с единственным целым значением в объекте Установок (Settings) соответствующего NTDS для данного контроллера домена обновляется в некоторое новое значение путём инкрементального увеличения его текущего значения. Если два контроллера домена имеют различные значения msDS-ReplicationEpoch, между ними не разрешено никакое RPC взаимодействие репликации каталога. Помимо репликации также прекращаются исчисления встроенного группового участия и просмотры глобального каталога. Так как данная процедура переименования домена влечёт за сосбой осуществление таких изменений независимым образом на всех контроллерах домена в данном лесу, не имеется возможности изменять эти контроллеры домена одновременно. Единственной целью атрибута msDS-ReplicationEpoch является минимизация потенциальной сложности включающих в себя репликацию взаимодействий между теми контроллерами домена, которые завершили данный процесс переименования домена и теми контроллерами домена, которые пока не закончили такое переименование домена.

 

Переключение реальных и алиасных имён DNS

Далее, как часть некоторой успешной транзакции обновления все значения в имеющихся атрибутах dnsRoot и msDS-DnsRootAlias в объектах перекрёстных ссылок переименованных доменов взаимно обмениваются таким образом, что имеющеесяновое имя домена, ранее хранившееся в msDS-DnsRootAlias, становится действующим именем домена, которое хранится в dnsRoot.

 

Выполняемые Rendom действия в ответ на команду rendom /execute

В ответ на команду rendom /execute происходит следующая последовательность действий:

 

Определение завершения переименования домена

В некотором большом лесу какое- то число контроллеров домена может выступить в качестве невозможных для контакта с ними на протяжении данного процесса переименования домена. Такие контроллеры домена никогда не достигают окончательного состояния Done. Вы должны определить как долго продолжать предпринимать попытки достичь контроллеров домена, которые являются недоступными, а также сколько выполнять попыток переповтора отказавших обновлений в контроллере домена, который достиг данного состояния Error. Когда дальнейший процесс в данном лесу невозможен, объявите данный процесс переименования домена завершённым. Все контроллеры домена, которые не достигли окончательного состояния Done из- за того что они либо недоступны, либо завершились с состоянием Error, должны быть демонтированы или удалены от обслуживания, если их демонтаж невозможен. Для того, чтобы некоторый лес работал без проблем после какого бы то ни было переименования домена, в таком лесу могут иметься только контроллеры домена, достигшие состояния Done.

 

Согласование Групповой политики после переименования домена

Когда данное имя DNS некоторого домена изменено, все ссылки на GPO (Group Policy objects, объекты Групповой политики) в данном переименованном домене через ссылки Групповой политики (атрибут gpLink) на площадках (sites), в доменах, а также в Подразделениях (OU) переводятся в нерабочие, так как они основаны на имеющемся старом имени домена. Далее, необязательный атрибут gpcFileSysPath в некотором GPO, который содержит путь UNC (uniform naming convention, универсальное соглашение именования) к некой папке шаблонов Групповой политики, размещённым в имеющемся SYSVOL данного переименованного домена также переводятся в неверные, так как этот путь применяет имеющееся старое DNS имя домена. Чтобы исправить отрезанные ссылки Групповой политики и все неверные пути UNC в GPO для такого переименованного домена вы можете воспользоваться инструментом Групповой политики, Gpfixup.exe для обновления всех ссылок Групповой политики и путей UNC в GPO, которые основаны на имеющемся новом имени домена. Инструмент Gpfixup доступен для занрузки в инструментах переименования домена (Domain Rename Tools) Windows Server 2003 на веб сайте Microsoft. Это инструмент встроен в контроллеры домена, которые исполнябтся под управлением Windows Server 2008 R2 и Windows Server 2008. Он также доступен в RSAT (Remote Server Administration Tools, инструментах Удаленного администрирования серверами). Выполните Gpfixup.exe по одному разу для каждого переименованного домена после завершения реальной операции переименования домена и прежде чем выполнится другая операция переименования домена.

 

Удаление старых имён домена после переименования домена

Вслед за выполнением всего процесса переименования домена для некоторого леса вы применяете имеющуюся команду rendom /clean для удаления всех старых имён домена из AD DS. Такой шаг очистки удаляет все значения msDS-DnsRootAlias из имеющегося хозяини операций именования (domain naming operations master) и удаление таких значений реплицируется во все контроллеры домена в имеющемся лесу. Так как эти атрибуты содержат все старые имена домена после завершения данного переименования домена, репликация таких удалений имеющихся значений атрибута msDS-DnsRootAlias во всех контроллерах домена в данном лесу запросит службу Сетевой регистрации (Net Logon) в таком контроллере домена отменить регистрацию таких записей ресурса имеющегося Локатора DNS для всех старых имён домена. В процессе такой отмены регистрации все записи ресурсов CNAME DNS, которые используются репликацией AD DS также будут удалены для всех старых имён ломена. Кроме того, данная очистка удалит все занчения атрибута msDS-UpdateScript из контейнера разделов (Partition) в имеющемся хозяине именования домена (domain naming master).

После того как вы успешно выполните rendom /clean, ваш новый лес готов для другой операции перестроения леса.

 

Связанная информация

Приведённые ниже ресурсы содержат дополнительную информацию, которая имеет отношение к данной теме:

Данный раздел является переводом одного из блогов Dishan M. Francis, Step-by-Step guide to rename Active Directory Domain Name, опубликованного 14 мая 2015 в Active Directory, MICROSOFT, Windows 2012, Windows Server 2008 и имеющего теги DC rename, DNS, DNS suffix, domain forest, domain name, domain restructure, forest.

---

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

Ниже приведены все критические моменты, которые вам следует рассмотреть перед переименованием AD.

Когда ваша инфраструктура готова, чтобы выполнить весь процесс переименования нам нужен некий компьютер или сервер администрирования. Он должен быть участником домена и не должен быть неким DC (контроллером домена). Он должен иметь установленными Инструменты Администрирования Удалённого сервера ("Remote Server Administration Tools"). Для Windows 2012 сервера имеется возможность их добавления в качестве свойства через Диспетчер сервера. Для Windows 8 и последующих версий вы можете загрузить их с http://www.microsoft.com/en-us/download/details.aspx?id=28972.

В демонстрации я собираюсь переименовать домен contoso.com в домен canitpro.local. Он исполняется под управлением Windows Server 2012 R2.

Я подготовил некий сервер, который исполняет Windows Server 2012 R2 будучи сервером участником для выполнения данного переименования. Вы можете установить Инструменты Удалённого администрирования сервера через Диспетчер сервера > Добавление ролей и свойств (Server manager > Add roles and features). Убедитесь что вы выбрали в RSAT (Remote Server Administration Tools) AD DS and AD LDS tools.

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

Кроме того я забежал вперёд и создал необходимую соответствующую зону DNS для своего нового имени домена в первичном сервере DNS. (в моём блоге вы можете найти завершённую статью про dns, в которой объясняется установка зоны DNS).

Затем зарегистрируйтесь в своём серере участнике домена под администратором домена и откройте соответствующее приглашение командной строки с правами администратора.

Вначале нам необходимо создать некий отчёт, который раскроет текущие настройки нашего леса. Чтобы выполнить это, наберите rendom /list и нажмите Enter.

Это создаст некий файл xml с именем Domainlist.xml в том пути, в котором исполнялась приведённая выше команда. В моём демо это C:\Users\Administrator.CONTOSO.

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

Затем наберите команду rendom /upload в той же самой папке пути.

Чтобы проверить доступность данного домена на чтение прежде чем вы запустите процесс переименования введите rendom /prepare.

Если она пройдёт без ошибок, выполните rendom /execute чтобы осуществить переименование. Это выполнит автоматический перезапуск всех контроллеров домена.

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

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

Это можно выполнить применив команду netdom computername DC.contoso.com /add:DC.canitpro.local.

Затем наберите netdom computername DC.contoso.com /makeprimary:DC.canitpro.local и по завершению перезагрузите данный DC (контроллер домена).

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

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

Чтобы исправить и это, наберите и введите gpfixup /olddns:contoso.com /newdns:canitpro.local

Затем выполните gpfixup /oldnb:CONTOSO /newnb:canitpro

С этим мы также покончили. Единственное что нам осталось, это исполнить random /end чтобы остановить этот процесс переименования и разморозить активность данного DC.

Это завершает данный процесс переименования и теперь у нас имеется некий DC с новым именем домена.

Если у вас имеются вопросы обо всём описанном, не стесняйте себя в контакте со мной по адресу rebeladm@live.com.