Msdcs зона что это

10

Сетевые сервисы Windows 2012 — DNS

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

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

Содержание:

1. Основные сведения
2. Немного о формате сообщения DNS
3. TCP и UDP
4. DNS в Windows Server 2008 и 2012
5. DNS и Active directory
6. Источники информации

(анкеров нет, поэтому содержание без ссылок)

1. Основные сведения

DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:

А — то самое сопоставление символьного имени домена его IP адресу.

АААА — то же что А, но для адресов IPv6.

CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.

MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.

NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.

SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.

SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.

Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.

Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):

Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.

Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.

Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.

В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.

В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.

Итеративный и рекурсивный запросы.

Понятно, что отдельно взятый DNS-сервер не знает обо всех доменах в интернете. Поэтому, при получении запроса на неизвестный ему адрес, например metro.yandex.ru, инициируется следующая последовательность итераций:

DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.

Клиент обращается к держателю зоны ru с тем же запросом.

DNS-сервер зоны RU ищет у себя в кэше соответствующую запись и, если не находит, возвращает клиенту адрес сервера, являющегося полномочным для домена второго уровня — в нашем случае yandex.ru

Клиент обращается к DNS yandex.ru с тем же запросом.

DNS яндекса возвращает нужный адрес.

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

Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».

2. Немного о формате сообщения DNS

Сообщение состоит из 12-байтного заголовка, за которым идут 4 поля переменной длины.

Заголовок состоит из следующих полей:

Формат DNS-сообщения

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

Флаги — 16-битовое поле, поделенное на 8 частей:

• QR (тип сообщения), 1-битовое поле: 0 обозначает — запрос, 1 обозначает — отклик.
• opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения — это 1 (инверсный запрос) и 2 (запрос статуса сервера).
• AA — 1-битовый флаг, который означает «авторитетный ответ» (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.
• TC — 1-битовое поле, которое означает «обрезано» (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.
• RD — 1-битовое поле, которое означает «требуется рекурсия» (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query). Мы рассмотрим примеры обоих типов запросов в следующих примерах.
• RA — 1-битовое поле, которое означает «рекурсия возможна» (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).
• 0 — Это 3-битовое поле должно быть равно 0.
• rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Пример (получен с помощью WinDump при выполнении команды ping www.ru):

IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)
IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)

Первая строка — запрос: имя моего ПК, 51036 — случайно выбранный порт отправки, 53- заранее известный порт DNS-сервера, 36587 — идентификатор запроса, + — «требуется рекурсия», А — запрос записи типа А, знак вопроса означает, что это запрос, а не ответ. В скобках — длина сообщения в байтах.

Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.

3. TCP и UDP

На слуху сведения о том, что DNS работает по протоколу UDP (порт 53). Это действительно по умолчанию так — запросы и ответы отправляются по UDP. Однако, выше упоминается наличие в заголовке сообщения флага TC (Truncated). Он выставляется в 1, если размер отклика превысил 512 байт — предел для UDP-отклика — а значит был обрезан и клиенту пришли только первые 512 байт. В этом случае клиент повторяет запрос, но уже по TCP, который ввиду своей специфики, может безопасно передать большие объёмы данных.

Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.

4. DNS в Windows Server 2008 и 2012

В Windows 2008 появились следующие возможности:

Фоновая загрузка зон

• определяются все зоны, которые должны быть загружены;
• из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
• загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
• начинается обработка запросов и удаленных вызовов процедур (RPC);
• создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.

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

Поддержка IPv6-адресов

Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.

Изменения DNS-клиента

Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.

Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.

5. DNS и Active directory

Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.

Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.

SRV записи регистрируемые службой Net Logon:

_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName

Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:

_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;

_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;

_kpassword — идентифицирует серверы изменения паролей kerberos в сети;

_gc — запись, относящаяся к функции глобального каталога в Active Directory.

В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.

Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.

DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.

Как происходит процесс поиска DC

Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.

Служба посылает один или несколько запросов с помощью API функции DsGetDcName()

DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.

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

После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.

Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).

Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.

Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)

Msdcs зона что это

Зона _ msdcs и ее полномочные сервера в лесу AD

Доброго времени суток.

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

Итак, создаем новый лес. Будем использовать мастер DCPROMO . На первом контроллере в корневом домене example . com создаются две DNS зоны: _ msdcs . example . com и, собственно, example . com . В зоне example . com создается запись делегирования _ msdcs , в которой полномочным сервером для зоны _ msdcs.example.com записывается наш первый контроллер. При добавлении второго и последующего контролеров в корневой домен и последующей установки на них DNS сервисов автоматического обновления записи делегирования в плане добавления в нее даных FQDN и IP адресов новых контроллеров не происходит. Почему? Ведь очевидно, что новые контроллеры являются не менее полномочными представителями зоны _ msdcs . example . com , чем первый контроллер. Приходится обновлять запись делегирования вручную.

Далее. У нас появляется дочерний домен branch . example . com . На первом контроллере дочернего домена до запуска мастера DCPROMO устанавливаем DNS сервис, создаем зону branch . example . com , настраиваем условную пересылку запросов на DNS сервер корневого домена, в зоне example . com создаем запись делегирования для зоны branch будущему контроллеру и т.д.

Тест « dcdiag / test : dcpromo / DnsDomain : branch . example . com / ChildDomain » на member – сервере и разрешение имен проходят успешно. Спустя некоторое время после успешного повышения рядового сервера до роли первого контроллера дочернего домена в его оснастке DNS появляется зона _ msdcs . example . com .

Вопрос: нужно ли данные этого контролера ( FQDN и IP адрес) добавлять в запись делегирования зоны _ msdcs . example . com на контроллерах корневого домена, ведь раз контроллер дочернего домена содержит реплику зоны _ msdcs . example . com (или другими словами, содержит раздел каталога приложений ForestDnsZones. example . com ), значит, является полномочным для нее. И, опять же, почему запись делегирования не обновляется автоматически, ведь появляются же автоматически данные о новом контроллере на вкладке «Серверы имен» в свойствах зоны _ msdcs . example . com . Нужно ли обновлять запись делегирования вручную?

Как изменить имя (переименовать) домен Active Directory?

06.10.2022
itpro
Active Directory, Windows Server 2016
комментариев 17

В этой небольшой статье мы покажем, как правильно изменить имя домена Active Directory с test.com на resource.loc . Вообще говоря, переименование домена Active Directory это не всегда самая лучшая идея. Для больших и сложных инфраструктур AD лучше выполнить постепенную миграцию пользователей, компьютеров и серверов в новый домен. Но и процедура переименования домена вполне рабочая.

Прежде чем начать, убедитесь, что:

1. У вас есть актуальная резервная копия контроллеров домена;
2. В вашем домене корректно работает репликация и нет критических ошибок контроллеров домена или DNS (проверка здоровья домена Active Directory);
3. В вашем домене нет Exchange. Нельзя переименовать домен AD с развёрнутым в нем Exchange (кроме Exchange 2003);
4. Для переименования домена нужен уровень не менее Windows Server 2003 (в моем примере функциональный уровень домена и леса – Windows Server 2016).

Сначала нужно создать DNS зону нового домена на контроллерах домена. Для этого откройте консоль dnsmgmt.msc , создайте новую первичную зону типа Forward Lookup Zone с именем resource.loc и реплицируйте ее по всем DNS серверам в старом домене test.com.

Add-DnsServerPrimaryZone -Name resource.loc -ReplicationScope «Domain» –PassThru

Дождитесь окончания репликации новой зоны по всем DC.

Выполните команду rendom /list чтобы сгенерировать файл Domainlist.xml с текущей конфигурацией леса AD.

Откройте файл Domainlist.xml на редактирование и замените все имена старого домена на новый:

Сохраните файл и выполните команду:

Данная команда покажет какие изменения будут внесены в конфигурацию.

Следующая команда загрузит файл Domainlist.xml с новой конфигурацией разделов AD на контроллер домена с FSMO ролью Domain naming master:

netdom query fsmo

После этого блокируются любые изменении в конфигурация леса AD

Следующая команда rendom /prepare проверит доступность всех DC в лесу и проверить их готовность к переименованию.

Убедитесь, что эта команда не вернула ошибок.

Следующая команда выполнит переименование домена (контроллеры домена некоторое время будут недоступны и автоматически перезагрузятся, чтобы применить новые настройки):

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

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

gpfixup /olddns:test.com /newdns:resource.loc

Затем обновите NetBIOS имя домена:

gpfixup /oldnb:TEST /newnb:RESOURCE

Следующая команда удалит из AD ссылки на старый домен:

Разблокируйте конфигурацию домена:

Теперь нужно вручную добавить новые имена на каждом контроллере домена и сделать их основными:

netdom computername %COMPUTERNAME%.test.com /add:%COMPUTERNAME%.resource.loc
netdom computername %COMPUTERNAME%.test.com /makeprimary:%COMPUTERNAME%.resource.loc

И перезагрузить DC:

Запустите консоль ADUC (dsa.msc) и проверьте, что она подключилась к новому имени домена, а вся структура OU, пользователи и компьютеры остались на месте.

Осталось сменить “Full computer name” на всех компьютерах и серверах в домене. Для добавления компьютеров в домен можно использовать команды выше.

После окончания процедуры переименования домена обязательно проверьте состояние репликации и ошибки на DC (ссылка была выше).

Предыдущая статья Следующая статья

alt=»двухфакторная аутентфикация в windows server» width=»58″ height=»56″ /> Настройка двухфакторной аутентификации (2FA) в Windows с помощью MultiOTP
Когда истекает пароль пользователя в AD, оповещаем пользователей о необходимости сменить пароль
alt=»создать gpo для подключения сетевых дисков» width=»58″ height=»56″ />Подключение сетевых дисков в Windows через групповую политику
Критическая уязвимость Active Directory Zerologon (CVE-2020-1472)

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

Microsoft Exchange 2000 Server
Microsoft Exchange Server 2007
Microsoft Exchange Server 2010
Microsoft Exchange Server 2013
Microsoft Internet Security and Acceleration (ISA) Server 2004
Microsoft Live Communications Server 2005
Microsoft Operations Manager 2005
Microsoft SharePoint Portal Server 2003
Microsoft Systems Management Server (SMS) 2003
Microsoft Office Communications Server 2007
Microsoft Office Communications Server 2007 R2
Microsoft System Center Operations Manager 2007 SP1
Microsoft System Center Operations Manager 2007 R2
Microsoft Lync Server 2010
Microsoft Lync Server 2013

привет, а если у меня Exchange 2019 ?

Я бы не стал такое делать. Документации можно ли сделать смену имения домена с Exchange 2019 я не видел.
Подумайте, может быть вам просто добавить пользователям новый UPN суффикс + accepted domains в exchnage и забыть ��

Вручную переименовывать нужно только КД, остальные компьютеры и сервера можно перезагрузить два раза и они сами подхватят новый домен.
Делать это нужно после /execute и ДО выполнение команды rendom /clean

Очень полезная статья, самому приходилось пару раз этим заниматься. Очень сокращает время для поднятия нового DMZ.

немного оффтопик: после очередной штатной перезагрузки перестало разрешаться короткое (netbios) имя домена, недоступны общие папки по \\test\Namespace\share_name и в домен компьютер добавить по короткому имени (test), по полному (test.loc) все ок. Подскажите как это вообще проверять, это netbios или dns?

Это netbios. Проще всего сделай в DNS cname запись для contoso, указывающую на contoso.com

Переименовал домен по вашей инструкции, все прошло без проблем, котроллеры и сервера подцепились, клиенты тоже.
Но есть вопрос!
Как удалить все возможные следы старого имени домена? Они все равно остались, встретил их и в dhcp и в dns, возможно еще где-то остались.
Спасибо

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

добрый день
вопрос, если есть exchange online (on premise нету)
правильный ли такой сценарий?
1. добовляем пользователям AD почтовые алиасы нового домена, делаем их основными например
2. меняем имя домена AD как в статье
3. обновляем конфигаруацию AD sync

По логике все так. Только я бы сначала сделал адрес из нового домена вторичным через proxyAddresses и дождался синхронизации.
А зачем вам переименовывать on-prem AD? можно ведь обойтить дополнительным UPN суффиксом на земле https://winitpro.ru/index.php/2021/05/21/upn-suffiksy-userprincipalname-v-active-directory

спасибо за ответ

зачем переименновывать домен — у компании меняется имя вот и все
соответсвенно почтовые адреса должны поменяться
пути к сетевым дискам DFS, dns суфиксы компьютеров серверов, и так далее

У нас используется доменная система с двумя контроллерами домена на базе Microsoft Windows Server 2012 R2. Лес и домен работает в режиме Windows Server 2012 R2.
Клиентская база составляет порядка 200 ПК на базе ОС Windows 7 и Windows 10.

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

Поэтому для образовательных целей развернул у себя тестовый домен, работающий, как и «боевой» в таком же режиме и состоящий из двух контроллеров и одного клиентского ПК.

Изучил в интернете довольно много материала по переименованию домена, в том числе и статью на эту тему «Как изменить имя (переименовать) домен Active Directory?» на Вашем сайте WinITPro.ru.

Провел на тестовом домене переименование. Как-будто домен с новым именем полностью работоспособен (провел рекомендуемые тесты по проверке его здоровья как и перед операцией переименования), но осталось несколько вопросов.

Может Вы согласитесь мне на них ответить.

Некоторые авторы, в том числе и Вы, в числе подготовительных работ, перед выполнением переименования, рекомендуют создать новую первичную зону типа Forward Lookup Zone с именем нового домена и реплицировать ее по всем DNS серверам в старом домене.

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

А если эту зону не создавать предварительно (некоторые авторы об этом не пишут)? По Вашему мнению смогут ли клиентские ПК и рядовые серверы без проблем присоединиться к новому доменному имени?

В Вашей статье не указано, на каком этапе выполнять переподключение клиентских ПК и рядовых серверов к новому доменному имени. Это нужно делать до выполнения команды rendom /clean, которая должна удалить из AD ссылки на старый домен,

и команды rendom /end, которая должна разблокировать конфигурацию домена или можно (или нужно) выполнять после выполнения указанных мной выше команд?

3. Нужно ли после выполнения переименования домена из Forward Lookup Zone удалять первичную зону с именем старого домена? И как быть с зоной _msdcs.старый домен? Ее тоже нужно удалить и «ручками» создать такую, но уже с именем нового домена в названии?

Этих моментов совсем нет в Вашей статье? Или у меня все же как-то «кривовато» прошла операция переименования?

1) Зону желательно создать предварительно, я не знаю создается ли она автоматически при переименовании. Я пробовал именно сценарий с ручным созданием зоны. Тем более это не сложно.
2) Переподключение рабочих станций в новый домен логично выполнять уже после завершения процедуры переименования.
3) Старую зону, если она вам не нужна конечно можно будет со временем удалить. Но я бы сделал это не сразу, а черен некоторое (с неделю выждать). Чтобы убедится, что на нее ничего не завязано, я бы сначал запретил в ее свойствах чтение для everyone и очистил DNS кэш на клиентах (ipconfig /flushdns). Выждать еще недельку и если ничего не всплывает, можно ее удалять.
Зона _msdcs.новый домен должна создаться автоматически.

Я не понял, какие все таки проблемы у вас остались после переименования стендового домена.

Зону с новым именем домена я создавал предварительно, а вот зона с именем _msdcs.новый домен у меня не создалась сама. Может ее тоже нужно было создать предварительно «ручками»?

По идее DC сам должен создать зону _msdcs. Попробуйте перезагрузить DC на стенде и посмотреть, создалась ли она автоматически.
Если нет, ну тогда вручную.
_https://servergurunow.wordpress.com/2017/09/29/recreate-the-_msdcs-dns-zone/
К сожалению уже не помню, делали ли это вручную или нет.

После переименования домена не смог добавить новый DC в AD. В мастере dc promote появилась ошибка:
A domain rename operation is already in progress
Оказалось, я забыл завершить процедуру и разблокировать домен:
rendom /end
��

Msdcs зона что это

На данный момент я имею вот такую картину:
dcdiag /test:dns /fix

Командлет Get-DnsServerResourceRecord в конвейере команд в позиции 1
Укажите значения для следующих параметров:
ZoneName: dc.ru

HostName RecordType Timestamp TimeToLive RecordData
——— ———- ——— ———- ———-
@ NS 0 01:00:00 srv.dc.ru.
@ SOA 0 01:00:00 [129][srv.dc.ru.][hostmaster.dc.ru.]
_msdcs NS 0 00:00:00 srv.dc.ru.
_gc._tcp.Default-First. SRV 02.10.2017 12:00:00 00:10:00 [0][100][3268][srv.dc.ru.]
_kerberos._tcp.Default. SRV 02.10.2017 12:00:00 00:10:00 [0][100][88][srv.dc.ru.]
_ldap._tcp.Default-Fir. SRV 02.10.2017 12:00:00 00:10:00 [0][100][389][srv.dc.ru.]
_gc._tcp SRV 02.10.2017 12:00:00 00:10:00 [0][100][3268][srv.dc.ru.]
_kerberos._tcp SRV 02.10.2017 12:00:00 00:10:00 [0][100][88][srv.dc.ru.]
_kpasswd._tcp SRV 02.10.2017 12:00:00 00:10:00 [0][100][464][srv.dc.ru.]
_ldap._tcp SRV 02.10.2017 12:00:00 00:10:00 [0][100][389][srv.dc.ru.]
_kerberos._udp SRV 02.10.2017 12:00:00 00:10:00 [0][100][88][srv.dc.ru.]
_kpasswd._udp SRV 02.10.2017 12:00:00 00:10:00 [0][100][464][srv.dc.ru.]
_ldap._tcp.Default-Fir. SRV 02.10.2017 12:00:00 00:10:00 [0][100][389][srv.dc.ru.]
_ldap._tcp.DomainDnsZones SRV 02.10.2017 12:00:00 00:10:00 [0][100][389][srv.dc.ru.]
_ldap._tcp.Default-Fir. SRV 02.10.2017 12:00:00 00:10:00 [0][100][389][srv.dc.ru.]
_ldap._tcp.ForestDnsZones SRV 02.10.2017 12:00:00 00:10:00 [0][100][389][srv.dc.ru.]
srv A 0 01:00:00 10.55.19.200
WS-Buh01 A 02.10.2017 7:00:00 00:20:00 10.55.19.185
WS-Buh02 A 02.10.2017 8:00:00 00:20:00 10.55.19.187
WS-Econ01 A 03.10.2017 3:00:00 00:20:00 10.55.19.188
WS-Econ02 A 02.10.2017 8:00:00 00:20:00 10.55.19.190
WS-econ03 A 02.10.2017 8:00:00 00:20:00 10.55.19.120
WS-Econ04 A 02.10.2017 8:00:00 00:20:00 10.55.19.179
/* и т.д. */
.
.

Вчера начал шевелиться DNS — обновил подзоны. Из сделанного вчера перед тем как он начал обновлять подзоны:
— заменил сетевой шнур у сервера;
— перезапустил свитч, к которому подключен сервер;
— добавил в реестр запись EnableEDNSProbes=0
— в очередной раз запустил команды ipconfig /flushdns, ipconfig /registerdns, net stop netlogon, net start netlogon, dcdiag /fix;
— на всякий пожарный вынес в отдельные правила в сетевом экране разрешение на порты 53 TCP/UDP и 389 TCP на локальный адрес сервера.

Но тесты ВРА и dcdiag /test:dns все равно выдают ошибки.

Добавлено:
В журнале системы постоянно возникают ошибки и предупреждения:

Ошибки DistributedCOM связанные с DNS серверами ISP и шлюзом.
Ошибки DistributedCOM

Код:

должно быть в самом начале вот так:

Код:

это не нужно. удалить. пока оставьте, надеюсь, что не помешает:

Код:

Цитата:

Да вот так, что вы не сказали ни да ни нет. Игрушки.

Цитата:

Если звёзды зажигают, то кому-нибудь это нужно. Жалко, что мы так и не услышали начальника транспортного цеха ответа на все вопросы, коих было-то не много. Пробелы в вводных превышают мои телепатические способности. Как это, сервер не слушает, но кто-то у него регистрируется. Возникают тогда пвопросы, про всякие DHCP и прочих всяких. клиентов его, но уже ее интересно. Какой смысл, чтоб старые забИть?
Вообще, тема напоминает викторину, хочу скажу, а хочу промолчу. Вы же угадывайте, может я вам даже отвечу.
Простите, что не сумел помочь. Курочить зоны на полностью работоспособном сервере я бы не стал без особой необходимости, а на инвалиде, где как я подлозреаю, проблемы непосредственно с ролью сервера DNS — так и подавно. И здесь тоже не помощник.
Вопос закрыт, таким образом.

Цитата:

Не совсем понимаю о чем Вы. В теме я уже расписал структуру своей сети. О каких игрушках идет речь?

Цитата:

Я регулярно отвечаю на вопросы и предоставляю результаты тестовых запросов.

Цитата:

Трогать настройки на полностью работоспособном сервере и я бы не стал, руководствуясь принципом — "работает — не трогай". А если инвалида не лечить, он так и останется инвалидом. И да — проблема с DNS сервером, с ролью, как Вы говорите, или еще с чем то, я пытаюсь это выяснить и исправить.

Цитата:

О том, что заданные вопросы висят без ответа уже неделю. Ровно.

Цитата:

Вы промолчали, значит ошибки нет. Между тем, где-то там ошибка, раз клиенты таки регистрируются. "Звёзды зажигают" и я бы спросил конфиг клиентов и кое-что еще.
Если вы отвечали Магниту, то с него и спрашивайте, мне не интересно, парень откровенно хамит, и технически, имхо, заблуждается. Во всяком случае, я не считаю, что отсутствие ответа на 53 потру сервера = не возможности разрешить А запись.
По моему, это очевидно.

Цитата:

Пожалуйста. разберетесь, я думаю. Не забудьте про виртуализацию

Цитата:

печально. давайте по второму кругу сделаем nslookup прямой и обратной зон с клиентов:

Код:

так же повторите вывод прямой зоны dc.ru. у вас там была ошибка с записью _msdcs — это запись вида А, но не NS.
ВАЖНО! стоит проверить откуда загружаются зоны на вкладке Дополнительно свойств сервера, должно быть из AD и реестра. там же можно тыкнуть в кнопку сброса к настройкам по умолчанию.

Цитата:

nslookup с клиента

С сервера тот же nslookup выдает таймауты.

Цитата:

Get-DnsServerResourceRecord

Цитата:

Зоны загружаются из AD и реестра. Кнопку сброса к дефолтным настройкам я уже нажимал несколько дней назад.

Добавлено:
надеюсь, что внутри все зоны заполнены правильно, есть соответствующие SRV-записи

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

Ошибка: DistributedCOM:
Не удалось установить связь DCOM с компьютером 195.98.32.200 через какой-либо из настроенных протоколов; запрос от PID 1c40 (C:\Windows\system32\dcdiag.exe).
Не удалось установить связь DCOM с компьютером 195.98.32.193 через какой-либо из настроенных протоколов; запрос от PID 1c40 (C:\Windows\system32\dcdiag.exe).
Не удалось установить связь DCOM с компьютером 10.55.19.1 через какой-либо из настроенных протоколов; запрос от PID 1c40 (C:\Windows\system32\dcdiag.exe).

Предупреждение: NETLOGON:
Ошибка при динамической регистрации или удалении одной или нескольких записей DNS, связанных с доменом DNS "ForestDnsZones.dc.ru.". Эти записи используются другими компьютерами для поиска данного сервера как контроллера домена (если указан домен Active Directory) или как сервера LDAP (если указанный домен является разделом приложений).

Ошибка при динамической регистрации или удалении одной или нескольких записей DNS, связанных с доменом DNS "DomainDnsZones.dc.ru.". Эти записи используются другими компьютерами для поиска данного сервера как контроллера домена (если указан домен Active Directory) или как сервера LDAP (если указанный домен является разделом приложений).

Ну и в большом количестве возникают ошибки bowser от разных клиентов сети:

Цитата:

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

Цитата:

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

Добавлено:
MAGNet
Проверка ВРА AD выдает вот такую ошибку: