Windows 2003 DC к Windows 2008 R2 DC с тем же именем и тем же IP
Среда = собственный домен Windows 2003 с 8 контроллерами домена
У меня есть старый контроллер домена под управлением 2003 года, роль CA Enterprise, DHCP, DNS, несколько сценариев GPO, которые указывают на общие ресурсы, и некоторые другие второстепенные функции. Все наши серверы указывают на него в качестве основного DNS, и на данный момент существует множество ссылок на его IP или имя по всему домену (более 8 лет спустя). Я действительно не хочу менять все это вручную, это было бы довольно масштабным мероприятием.
Я хочу следовать этому руководству: http://msmvps.com/blogs/acefekay/archive/2010/10/09/remove-an-old-dc-and-introduce-a-new-dc-with-the-same-name-and-ip-address.aspx мы надеемся, что в итоге мы получим, так сказать, "обновление на месте".
Я подумал о том, чтобы сделать P2V из коробки, но мы не хотим, чтобы он продолжал работать в 2003 году, если честно. Я также подумал об использовании CNAME и добавлении 2-го IP-адреса (старого), но, опять же, казалось, что было бы чище, используя прикрепленную ссылку.
Мой актуальный вопрос:
Есть ли какие-либо ошибки или признаки большой осторожности при выполнении того, что предлагает ссылка? Кто-нибудь пошел по этому пути и есть совет, как поступить?
2 ответа
Это довольно распространенная операция. Ace - хороший рекламный ресурс, так что довольно легко поверить ему на слово для чистого DC.
Он не тратит много времени на другие услуги, которые в вашем случае важны:
CA может быть немного болезненным, потому что для правильной работы вам потребуется обновить текущий DC, если вы не хотите потерять всю информацию о выданных сертификатах (см. http://support.microsoft.com/kb/298138). В зависимости от того, что вы используете CA для этого может быть или не быть в порядке. Я, конечно, видел, как это было сделано с потерей конфигурации CA и заменой ее без существенного ущерба для окружающей среды. Просто убедитесь, что вы не создадите новый CA, пока не переименуете и не продвинете новую машину, потому что вы не можете выполнять эти операции в CA.
Миграция данных DNS будет происходить волшебным образом при условии, что AD интегрирован, в противном случае вам нужно будет настроить его как дополнительный, а затем изменить его на основной и перенастроить после назначения старого IP-адреса новому серверу.
Перенос данных DHCP возможен и неплох, если вы следуете инструкциям (см. http://support.microsoft.com/kb/962355). Ace рассказывает об этом на связанной странице.
Перенос акций будет включать данные и разрешения. Обычно вы используете что-то вроде FSMT ( http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=10268), но вы не делаете постоянное изменение имени сервера. Поэтому просто используйте robocopy, чтобы скопировать файлы на новый сервер, включая разрешения (/copyall), и перенести определения общего ресурса (вручную или что-то вроде http://support.microsoft.com/kb/125996).
Об этом в ArsTechnica ( http://arstechnica.com/civis/viewtopic.php?f=17&t=1117166) есть ветка, в которой рекомендуется использовать "свинг-сервер". Я сделал это в случаях миграции SBS, но я считаю, что в вашем случае это излишне, поскольку у вас так много существующих контроллеров домена.
Вы не сказали, существуют ли DNS и DHCP на других серверах или только на этом; если только на этом, во-первых, плохо из-за единственной точки отказа и т. д., но также это означает, что вы смотрите на очень заметное время простоя для конечных пользователей, когда вы это делаете, и в этом случае свинг-сервер может имеет смысл (два меньших сообщения вместо одного большего).
Качественный товар. Все выглядит хорошо, и @MikeBaz - это хороший способ указать на центр сертификации, о котором ACE не упоминает, но он часто встречается на DC. Менее "все или ничего" переключение состоит в том, чтобы просто сделать это медленно и переместить каждый сервис в новое место, как его собственный мини-проект. Скорее всего, DNS - это единственный, который вам нужен для IP-адреса (при условии, что на нем нет WINS-сервера).
Ваша сеть должна быть спроектирована так, чтобы AD DC были отказоустойчивыми, так как ни один сбой DC не затронул бы сетевые сервисы, такие как DC, DNS, DHCP, CA, netlogon и т. Д. Я рекомендую использовать замену этого сервера как шанс улучшить ваш дизайн каждый из них должен быть высокодоступным. Хорошая новость заключается в том, что каждый может быть с минимальными усилиями, что делает замену NEXT DC намного проще.
Для сценариев, если они указывают / работают из netlogon, который находится на всех DC (и реплицируется между ними), то любые имена серверов в сценариях не должны указывать на \\old-dc\netlogon, а скорее на \\domainname.com\netlogon, это предпочтительный способ, чтобы клиенты могли получать скрипты и вспомогательные файлы из ближайшего DC. Если вы храните файлы на других общих ресурсах в сценариях / объектах групповой политики, рассмотрите возможность использования DFS + DFSR, которая проста в использовании и предотвращает любой доступ к файлу из-за сбоя одного общего файлового ресурса.
Для DNS с таким количеством контроллеров домена в вашей сети все клиенты и серверы должны быть настроены как минимум на два DNS-сервера. Если это так, то отключение одного DC не является проблемой во время миграции. Для клиентов DHCP просто измените область DHCP на другой хост DC / DNS, что вы можете сделать сейчас. Для серверов со статическими IP-адресами вы можете использовать скрипт или назначить младший. Администратор задачи вручную, чтобы убедиться, что все они имеют правильные записи DNS. DNS является источником жизненной силы AD, и, когда это возможно, я фактически добавляю 3+ DNS-адреса на сетевые карты сервера (НИКОГДА не меньше 2) из-за таких случаев, когда DNS-серверы должны быть заменены или им даны новые IP-адреса.