У нас есть существующий сервер SBS2011, и мы хотим перейти на новый сервер 2012 R2. В идеале мы хотели бы сделать это в новом домене - 1. мы хотели бы реорганизовать OU, чтобы удалить материал с именем «SBS» (т.е. все пользователи не являются пользователями, они находятся в SBSUsers и т. Д. ..) и 2. мы хотели бы использовать доменное имя, которое больше соответствует передовой практике (subdomain.ourdomain.com, а не name.local).
Я пытаюсь найти лучший способ сделать эту миграцию. Большинство вещей, которые я прочитал, говорят о миграции путем добавления нового контроллера домена к существующему домену, его продвижения, синхронизации всего и последующего понижения статуса старого. Однако это не решает ни одну из наших проблем, связанных с переименованием или реорганизацией.
Я также подумал, возможно, о чем-то другом, но из того, что я могу сказать, вам понадобится либо ADMT (не поддерживается в 2012 году), либо, возможно, платный инструмент (маловероятный вариант, поскольку мы некоммерческая организация и имеем минимальный бюджет. для этого).
Наконец, я мог экспортировать пользователей и импортировать их, но это похоже на то, что это потребует различных шагов для пользователей, компьютеров, групп и т. Д., И я беспокоюсь о том, насколько хорошо это будет сцепляться. Кроме того, опять же, насколько я могу судить, без одного из вышеперечисленных инструментов (и, возможно, даже тогда!) Я все еще не могу этого сделать, не заставив всех пользователей сбросить свои пароли.
Exchange здесь не является переменной (я не думаю!), Поскольку мы переносим его в Office 365, и для простоты не добавляем SSO пока, пока все остальное не будет отсортировано.
Есть ли вариант, который мне не хватает, который позволил бы нам соответствовать всем нашим критериям - возможность изменить доменное имя и сохранить стандартный макет OU, а не SBS, не покупать дорогостоящий сторонний инструмент и не влиять на учетную запись пользователя / пароли ?
Exchange 2007 и более новые версии не позволяют вам выполнять переименование домена. Поскольку вы говорите, что отказываетесь от локального Exchange, это не имеет значения. Это открывает дверь для того, что, на мой взгляд, будет намного проще, чем создание любого нового леса или домена:
Завершите миграцию на Office 365 и удалите Exchange из среды SBS 2011.
Добавьте временный контроллер домена в существующий домен и перенесите AD (и все роли FSMO) с сервера SBS, возвращая сервер SBS обратно члену домена в процессе. (После этого у вас будет 21 день для завершения миграции.)
Выполните переименование домена.
Добавьте свой постоянный DC W2K12 R2 и понизьте / удалите временный DC.
Переименуйте / переместите OU (GPO и т. Д.) В AD по своему усмотрению.
Перенесите любые другие функции с машины SBS и выведите ее из эксплуатации.
Временный DC не является строго необходимым, но я, вероятно, это сделаю (потому что я суеверный). Переименование домена звучит сложно, но без Exchange это довольно просто. Если вас это что-то беспокоит, смоделируйте свою среду, используя виртуальные машины в изолированной сети, и опробуйте ее (желательно, используя реальную копию вашего AD, «собранную» из вашей производственной сети и помещенную в виртуальную среду).
Вам также придется отказаться от центра сертификации по умолчанию, созданного установкой SBS 2011, когда вы это сделаете. Вывод из эксплуатации ЦС предприятия на самом деле не так уж и сложно, если предположить, что вы на самом деле не используете его ни для чего. (Если да, то независимо от того, какую стратегию миграции вы выберете, вам нужно будет об этом беспокоиться.)
Когда вы все сделаете, у вас будет красивое блестящее новое доменное имя, ваши OU будут выглядеть так, как вы хотите, все пароли пользователей останутся нетронутыми, а все компьютеры-члены домена будут иметь неповрежденные доверительные отношения домена.
Спланированное, протестированное и надлежащее выполнение переименования и миграции рабочего домена могло занять всего пару часов. (Очевидно, время, которое вы потратите на предварительное планирование и тестирование, принесет огромные дивиденды, когда вы действительно будете делать настоящие вещи.)
(Я бы также экспортировал доли на новой машине W2K12R2, которые отражали доли, экспортированные старой машиной SBS, и я бы добавил машину SBS как Псевдоним DNS на новый сервер. Тогда существующие ярлыки, UNC и т. Д. Будут «просто работать» после миграции.)
Редактировать:
Я не знаю, почему люди так уклоняются от переименования домена. Вам нужно спланировать это и выполнить методично, но для меня это было безболезненно. Я сделал три переименования рабочих доменов и не имел никаких проблем (кроме давно забытых полных доменных имен, используемых во встроенных устройствах, которые необходимо было изменить). В двух средах был Exchange 2003, а в одном - нет. У одного был один DC, у двух других - несколько DC. Я смоделировал первые два (среды, в которых был Exchange) на виртуальных машинах, но третий я просто запустил в производственной сети без макета (потому что это было так просто - один DC, без Exchange).
Вот этот маркер сверху «Выполнить переименование домена», разбитый на шаги.
Что касается статей Microsoft, я предпочитаю: Как работает переименование домена Статья содержит много лишнего фона, но основные шаги там.
Для однодоменного леса с одним DC процесс довольно безболезненный:
Выведите из эксплуатации любой корневой центр сертификации предприятия.
Создайте новую зону DNS, интегрированную в AD, для нового доменного имени.
Установите функциональный уровень леса на Windows 2003 или выше.
Бегать rendom /list для создания файла описания леса (Domainlist.xml).
Отредактируйте Domainlist.xml файл для отображения новых доменных имен DNS и NetBIOS.
Запустить rendom /showforest, который отображает Domainlist.xml файл "дружественным" способом и просмотрите вывод, чтобы убедиться, что вы внесли правильные изменения.
Запустить rendom /upload команда для установки нового доменного имени в Active Directory. На этом этапе переименования не происходит - вы просто готовите AD для переименования. В среде с несколькими контроллерами домена это инициирует репликацию команд переименования на все контроллеры домена.
Запустить rendom /prepare команда для проверки готовности к переименованию. В среде с несколькими DC эта команда проверяет каждый DC, чтобы убедиться, что все они получили инструкции по переименованию. Переименование не может начаться, пока все контроллеры домена не реплицируют инструкции переименования. (Необходимо, чтобы изменение происходило практически одновременно со всеми репликами базы данных AD.) После выполнения rendom /prepare вы не можете добавлять новые домены в лес или контроллеры домена в домен, пока не выполните rendom /clean (увидеть ниже).
Запустить rendom /execute команда для выполнения переименования. Это указывает контроллерам домена выполнить переименование. Каждый DC переключит свою базу данных AD в однопользовательский режим обслуживания, выполнит переименование, а затем перезагрузится в нормальное рабочее состояние.
После того, как все контроллеры домена завершат переименование, выполните 'Gpfixup' с соответствующими старым и новым доменными именами, чтобы обновить любые ссылки на старое доменное имя на новое имя в объектах групповой политики.
Измените основной DNS-суффикс на каждом DC потому что они не меняются автоматически. Я не знаю, почему Microsoft не внесла эти изменения автоматически, но этого не произошло. После внесения этого изменения снова перезагрузите контроллер домена.
Дважды перезагрузите все компьютеры, входящие в домен. Это не обязательно делать сразу (я держал домен в таком состоянии пару недель). Компьютеры, входящие в домен, «обнаружат», что было выполнено переименование домена, и автоматически обновятся во время этих двух перезагрузок.
После того, как вы дважды перезагрузили все компьютеры, входящие в домен, выполните команду rendom /clean команда, чтобы очистить инструкции по переименованию из AD и вернуть домен в нормальное рабочее состояние.
Удалите зону DNS старого домена из AD, как только вы перенесете из нее любые записи, не являющиеся членами домена.
Как я уже сказал, среда с одним доменом и одним контроллером домена проста, потому что вам не нужно беспокоиться о репликации инструкций по переименованию домена или возможности связаться со всеми контроллерами домена.
Что касается побочных эффектов:
Вы должны знать, что корневые имена доменов DFS изменятся. Если у вас есть установка программного обеспечения групповой политики, происходящая из путей DFS домена, вы увидите переустановки программного обеспечения (поскольку клиент групповой политики будет думать, что программное обеспечение не установлено).
если ты /clean слишком рано (до того, как все рядовые компьютеры были перезагружены дважды), вы можете столкнуться с состоянием, когда у вас есть машины, которые необходимо вручную отсоединить и повторно присоединить к домену.
В более крупных средах вы увидите увеличение трафика репликации по мере заполнения новых зон DNS.