Изменение имени домена в Windows Server

·
изменение имени домена в Windows Server

Переименование домена Active Directory выполняется через утилиту rendom и требует подготовки: бэкап, проверка совместимости приложений, обновление DNS-зон и перезагрузка всех контроллеров домена. Процедура рискованная и поддерживается не во всех конфигурациях (если у вас Exchange, даже не думайте).

Когда это реально нужно

Короче, переименование домена требуется редко. Вот типичные случаи:

  • Компания сменила название (слияние, ребрендинг)
  • Домен был назван неправильно при создании (company.local хотят заменить на company.com)
  • Юридические требования
  • Выделение подразделения в отдельную компанию

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

Мой коллега Игорь из Челябинска столкнулся с этим, когда две компании объединились. На его Dell PowerEdge R740xd нужно было переименовать домен с firma-a.local на newcompany.local. Процесс занял выходные и пару бессонных ночей. Но всё закончилось хорошо.

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

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

Нельзя переименовать если:

  • Установлен Microsoft Exchange (Exchange не поддерживает переименование домена вообще, ни одна версия)
  • Используется Azure AD Connect с синхронизацией
  • Функциональный уровень леса ниже Windows Server 2003
  • Есть доверительные отношения с другими лесами (могут сломаться)
  • Используется Microsoft Lync/Skype for Business Server
  • Используется SCCM (System Center Configuration Manager)
  • Домен является корневым в лесу с дочерними доменами

Если честно, ограничение с Exchange убивает эту возможность для 80% организаций. Exchange и переименование домена несовместимы. А Exchange стоит почти в каждой организации с Active Directory.

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

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

Вот в чём прикол: подготовка важнее самой процедуры. Грубо говоря, 80% времени это подготовка и тестирование, 20% собственно переименование.

  1. Полный бэкап. Все контроллеры домена, System State. Без вариантов. Если что-то пойдёт не так, вы должны иметь возможность откатиться
  2. Проверка здоровья AD. Репликация должна работать идеально. Ни одной ошибки
  3. Инвентаризация. Все приложения, которые используют имя домена. Все скрипты, все строки подключения, все сертификаты
  4. DNS. Подготовить новые зоны
  5. Тестовая среда. Если есть возможность, протестируйте переименование в лаборатории
  6. Оповестить пользователей. После переименования им придётся перелогиниться
  7. Выбрать время. Только в нерабочее время, желательно в выходные
# Проверяем здоровье репликации AD
# Все контроллеры должны отвечать без ошибок
repadmin /replsummary

# Подробная проверка
repadmin /showrepl

# Проверяем состояние FSMO-ролей
netdom query fsmo

# Проверяем DNS
dcdiag /test:dns /v

# Полная диагностика AD
dcdiag /v /c

# Бэкап System State на каждом контроллере
wbadmin start systemstatebackup -backupTarget:D: -quiet

Кстати, команда dcdiag /v /c запускает все тесты диагностики. Если хоть один тест не пройден, не начинайте переименование. Сначала исправьте все ошибки.

Процедура переименования через rendom

Утилита rendom входит в Windows Server. Работает из командной строки. Процесс состоит из 7 шагов.

# Шаг 1: Генерируем XML-файл с текущей конфигурацией леса
rendom /list

# Это создаст файл Domainlist.xml
# Открываем его в текстовом редакторе и меняем имена доменов
# Находим строку DNSname="olddomain.local" и меняем на "newdomain.local"
# Меняем и NetBIOS-имя если нужно

# Шаг 2: Загружаем изменённый файл обратно
# rendom проверит валидность изменений
rendom /upload

# Шаг 3: Подготовка (проверка без применения)
# Этот шаг безопасен, ничего не меняет
rendom /prepare

# Шаг 4: Применяем переименование
# ТОЧКА НЕВОЗВРАТА, после этого пути назад нет (только откат из бэкапа)
rendom /execute

# Каждый контроллер домена перезагрузится автоматически

После перезагрузки всех контроллеров нужно сделать ещё несколько шагов:

# Шаг 5: Исправляем GPO (они привязаны к имени домена)
gpfixup /olddns:olddomain.local /newdns:newdomain.local
gpfixup /oldnb:OLDDOMAIN /newnb:NEWDOMAIN

# Шаг 6: Очищаем старые DNS-записи и ссылки
rendom /clean

# Шаг 7: Завершаем процедуру и поднимаем функциональный уровень если нужно
rendom /end

Знаете что, звучит просто. Но на практике между шагами 4 и 5 наступает момент, когда ничего не работает. Пользователи не могут войти, GPO не применяются, DNS путается. Поэтому делайте это в нерабочее время. По факту, окно простоя составляет от 30 минут до нескольких часов, в зависимости от размера домена.

Что сломается после переименования

Грубо говоря, много чего. Вот полный список того, что нужно проверить и исправить:

  • Профили пользователей. Путь к профилю содержит имя домена. Может потребоваться пересоздание перемещаемых профилей
  • Скрипты. Всё, что ссылается на старое имя домена (логон-скрипты, PowerShell, bat-файлы)
  • Сертификаты. SSL-сертификаты с именем домена станут невалидными. Нужно перевыпустить
  • SQL Server. Строки подключения с FQDN. Могут использовать старое имя домена
  • DFS. Пространства имён DFS привязаны к домену. Нужно пересоздать
  • Принтеры. Сетевые принтеры с UNC-путями (\olddomainprinter)
  • Ярлыки. Сетевые ярлыки на рабочих столах пользователей
  • Резервное копирование. Задания бэкапа могут ссылаться на старые UNC-пути
  • Мониторинг. Системы мониторинга (Zabbix, Nagios) с FQDN-именами

Кстати, рабочие станции тоже нужно перезагрузить минимум дважды после переименования домена. Первая перезагрузка обновит имя компьютера, вторая применит новые GPO. А ещё рабочие станции должны быть подключены к сети во время переименования.

Альтернатива: миграция вместо переименования

На самом деле часто проще создать новый домен и мигрировать в него, чем переименовывать старый. И это не шутка.

Инструмент: Active Directory Migration Tool (ADMT). Позволяет перенести пользователей, группы, компьютеры из одного домена в другой с сохранением SID-history (чтобы не потерять доступ к ресурсам).

По факту, миграция через ADMT безопаснее переименования:

  • Старый домен продолжает работать во время миграции
  • Можно мигрировать постепенно, отдел за отделом
  • Если что-то сломается, пользователи вернутся в старый домен
  • Работает с Exchange (в отличие от переименования)
  • Можно делать в рабочее время без простоя
  • Откат возможен на любом этапе

Анна, IT-руководитель из логистической компании в Перми, выбрала миграцию вместо переименования. 200 пользователей, 8 серверов (Lenovo ThinkSystem SR530). За месяц перенесла всех в новый домен без единого часа простоя. Попробовала бы переименовать? Простой был бы неизбежен. Плюс у них Exchange, так что переименование вообще было невозможно.

Процесс миграции через ADMT

# Подготовка: настройка доверия между доменами
netdom trust newdomain.local /domain:olddomain.local /add /twoway

# Установка ADMT на сервере в новом домене
# Скачивается с сайта Microsoft

# Миграция пользователей (с сохранением SID-history)
# Через GUI ADMT:
# 1. User Account Migration
# 2. Выбираем пользователей из старого домена
# 3. Target OU в новом домене
# 4. Включаем "Migrate user SIDs to target domain"

# Миграция компьютеров
# Computer Migration
# Компьютер переводится в новый домен автоматически
# Пользователь при следующем входе использует новый домен

Тут такое дело: ADMT требует настройки доверия между доменами, правильных DNS-записей и определённых прав. Это не «нажал кнопку и забыл». Но по сравнению с переименованием, миграция контролируемая и безопасная.

Переименование отдельного сервера (не домена)

А ещё бывает нужно переименовать не домен, а сам сервер (член домена). Это гораздо проще.

# Переименование рядового сервера в домене
# Учётные данные нужны для обновления записи в AD
Rename-Computer -NewName "SRV-FILE01" `
    -DomainCredential (Get-Credential) -Restart

# Для контроллера домена чуть сложнее
# Сначала добавляем новое имя
netdom computername DC01.contoso.local /add:DC-NEW.contoso.local

# Делаем новое имя основным
netdom computername DC01.contoso.local /makeprimary:DC-NEW.contoso.local

# Перезагружаем
Restart-Computer

# Удаляем старое имя
netdom computername DC-NEW.contoso.local /remove:DC01.contoso.local

Если честно, переименование рядового сервера, это 5 минут. Переименование контроллера домена, 15 минут. Переименование самого домена, часы работы и бессонные ночи. Разве не проще правильно назвать домен с самого начала?

Чек-лист после переименования домена

Если вы всё-таки решились на переименование, вот что нужно проверить после завершения:

  1. Все контроллеры домена перезагружены и отвечают
  2. Репликация работает (repadmin /replsummary)
  3. DNS-зоны обновлены, старые записи удалены
  4. GPO применяются (gpresult /r на рабочей станции)
  5. Пользователи могут войти в систему
  6. Общие папки доступны (\newdomainshare)
  7. Принтеры работают
  8. SQL Server и другие приложения подключаются
  9. Сертификаты перевыпущены
  10. Скрипты обновлены
  11. Мониторинг обновлён
  12. Бэкап настроен для нового домена

На самом деле, полная стабилизация после переименования занимает 1-2 недели. Первые дни будут мелкие проблемы: то скрипт не работает, то принтер не подключается, то DFS namespace не резолвится. Это нормально. Главное, чтобы основные функции (вход, почта, файловые шары) работали сразу.

Рекомендации по именованию доменов

Чтобы в будущем не пришлось переименовывать домен, вот рекомендации по именованию:

  • Используйте реальный зарегистрированный домен (company.com), а не .local
  • Для внутреннего домена используйте поддомен (ad.company.com или corp.company.com)
  • Не используйте название города или подразделения (msk-office.local), оно может измениться
  • Не используйте аббревиатуры, которые могут быть непонятны через 10 лет
  • NetBIOS-имя домена должно быть коротким (до 15 символов)

Вот в чём прикол: Microsoft официально не рекомендует использовать .local для доменов AD. Лучше использовать поддомен вашего публичного домена. Это избавит от проблем с сертификатами и DNS-резолвингом.

PowerShell-скрипт для проверки готовности

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

# Проверка готовности к переименованию домена
# Запускать на контроллере домена от администратора

Write-Host "=== Проверка готовности к переименованию домена ==="

# Проверяем функциональный уровень леса
$forest = Get-ADForest
Write-Host "Уровень леса: $($forest.ForestMode)"
if ($forest.ForestMode -lt "Windows2003Forest") {
    Write-Host "ОШИБКА: уровень леса ниже 2003, переименование невозможно" -ForegroundColor Red
}

# Проверяем наличие Exchange
$exchange = Get-ADObject -Filter 'objectClass -eq "msExchOrganizationContainer"' `
    -SearchBase (Get-ADRootDSE).configurationNamingContext -ErrorAction SilentlyContinue
if ($exchange) {
    Write-Host "ОШИБКА: обнаружен Exchange, переименование НЕВОЗМОЖНО!" -ForegroundColor Red
} else {
    Write-Host "Exchange не найден, ОК" -ForegroundColor Green
}

# Проверяем репликацию
Write-Host "Проверка репликации..."
repadmin /replsummary

# Проверяем количество контроллеров
$dcs = Get-ADDomainController -Filter *
Write-Host "Контроллеров домена: $($dcs.Count)"
foreach ($dc in $dcs) {
    Write-Host "  $($dc.HostName) - $($dc.OperatingSystem)"
}

По факту, этот скрипт за 30 секунд покажет, можно ли вообще начинать процедуру. Лучше потратить минуту на проверку, чем потом откатываться из бэкапа.

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

Лицензирование

Проверка здоровья AD после переименования через PowerShell

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

# Проверка здоровья AD после переименования
Write-Host "=== Проверка DNS ===" -ForegroundColor Cyan
Resolve-DnsName (Get-ADDomain).DNSRoot
Resolve-DnsName (Get-ADDomain).PDCEmulator

Write-Host "=== Проверка репликации ===" -ForegroundColor Cyan
repadmin /replsummary

Write-Host "=== Проверка SYSVOL ===" -ForegroundColor Cyan
$sysvol = "\$(Get-ADDomain).DNSRootSYSVOL"
Test-Path $sysvol

Write-Host "=== Проверка GPO ===" -ForegroundColor Cyan
Get-GPO -All | Select-Object DisplayName, GpoStatus | Format-Table

Write-Host "=== Проверка входа пользователей ===" -ForegroundColor Cyan
nltest /dsgetdc:(Get-ADDomain).DNSRoot

Мой коллега Алексей, админ в производственной компании (серверы Dell PowerEdge R750xs), прогонял этот скрипт каждый час в течение первых суток после миграции. На третьем прогоне обнаружил, что один из сайтовых контроллеров не обновил DNS-записи. Быстро починил, пока пользователи не успели заметить проблемы.

Тут такое дело: автоматические проверки экономят кучу времени. Вместо того чтобы ждать звонков от пользователей «у меня не работает», вы находите проблемы проактивно.

Частые ошибки при смене домена

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

Первая ошибка: не обновили SPN (Service Principal Names) для SQL Server и других сервисов. После переименования Kerberos-аутентификация к SQL ломается. Решение: пересоздать SPN через setspn для каждого сервиса.

Вторая ошибка: забыли про DHCP-сервер. Он раздаёт клиентам DNS-суффикс старого домена. Клиенты получают старое имя и не могут найти ресурсы. Нужно обновить настройки DHCP Scope Options (DNS Domain Name и DNS Servers).

Третья ошибка: не проверили Conditional Forwarders. Если у вас были условные пересылки DNS на партнёрские домены, они всё ещё ссылаются на старое имя.

# Проверяем SPN для SQL Server
setspn -L SQLServiceAccount

# Обновляем SPN
setspn -D MSSQLSvc/sqlserver.olddomain.local:1433 SQLServiceAccount
setspn -A MSSQLSvc/sqlserver.newdomain.local:1433 SQLServiceAccount

# Проверяем Conditional Forwarders
Get-DnsServerForwarder
Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Forwarder" }

Короче, переименование домена затрагивает десятки компонентов, о которых вы даже не думали. SPN, DHCP, DNS Forwarders, RADIUS, NAP, WSUS, все они хранят имя домена в своих настройках. Составьте полный список перед началом и проверяйте каждый пункт после завершения.

Лицензирование

Переименование домена не требует новых лицензий. Но если вы выбрали путь миграции в новый домен, каждому серверу нужна лицензия. Купить ключ Windows Server можно в keytrust24.store. Есть Standard и Datacenter для всех актуальных версий, активация моментальная.

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