Замена сетевой карты на контроллере домена
Продолжительное время пытаюсь разобраться с одной проблемой в доменной сети. На разных Windows Server после перезагрузки периодически тип сети с доменной (domain) меняется на частную (private). Происходит этот как на контроллерах домена, так и на рядовых серверах. Поделюсь своими рецептами борьбы с этой проблемой.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Цели статьи
- Описать проблему, с которой столкнулся, по смене категории сети на сетевом интерфейсе после перезагрузки windows сервера.
- Показать методы, которые применял для решения проблемы.
- Получить помощь или совет по текущей проблеме.
Введение
Сразу проясню технические моменты.
- Все события происходят на серверах версии Windows Server 2012 R2.
- Используются бесплатные гипервизоры Windows Hyper-V Server 2012 R2 и Windows Hyper-V Server 2016.
- Все серверы включены в домен. Часть серверов сами являются контроллерами доменов.
Теперь по симптомам. Периодически после плановой установки обновлений и перезагрузки в свойствах сетевого подключения меняется тип сети. Она перестает быть доменной и становится приватной.
Так же несколько раз была ситуация, когда сетевое подключение получало новое имя. Как видно на примере, сетевой интерфейс имеет имя Сеть 3. То есть это уже третий раз, когда он поменял имя. Оба эти события не всегда случаются одновременно. Имя сети может и не поменяться, но поменяется ее тип. При этом вирутальные машины никуда не переезжают, их настройки не меняются. Мне совершенно не понятно, почему может измениться сетевой интерфейс.
Пару раз была ситуация, когда сервер вообще был недоступен по сети после перезагрузки. При подключении к консоли я видел запрос на выбор типа сети. После того, как я указывал тип сети, сервер становился досупен. При этом его сетевые настройки не слетали, везде прописана статика. Конкретно эта ошибка гарантирована не воспроисзводилась, я особо не занимался расследованием. А вот со сменой типа сети сталкиваюсь регулярно, поэтому накопилась статистика.
Изменение типа сети на доменную
Простого способа указать, что данное соединение доменное в windows server нет. Я нашел как минимум 2 рабочих способа, которые гарантированно позволяют вернуть соединению статус Domain Network.
- Способ номер один. Заходим в свойства сетевого подключения и отключаем ipv6. Сеть сразу же становится доменной.
- Способ номер два. Перезапускаем службу Служба сведений о подключенных сетях (Network Location Awareness Service).
Идея полностью отключать ipv6 мне не нравится, потому что неоднократнго видел информацию о том, что она каким-то образом нужна для корректной работы сервера и Microsoft не рекомендует ее отключать.
При втором способе, если сделать для службы тип запуска Автоматически (отложенный запуск), то после перезагрзки сервера статус сети всегда будет доменный. Это вроде как решает проблему, хотя мне кажется, что это больше костыль, чем решение.
В целом, мне не понятно, в чем конкретно проблема и почему она стала проявляться в какой-то определенный момент, причем на разных серверах. Иногда помогает просто перезагрузка, иногда нет. Когда я последний раз исследовал ошибку, она на 100% повторялась на двух серверах с ролью контроллера домена, dhcp и dns сервера. Помогало либо отключение ipv6, либо перезапуск службы. В логах при этом ничего подходящего под указанную проблему не находил.
Причины изменения типа сети
Теоретически, Windows определяет тип сети как доменный, если с соответствующего адаптера достижим контроллер домена, с которого были получены групповые политики. На контроллере домена этот сервер - он сам, все сетевые адаптеры на нём должны определяться как принадлежащие доменной сети. Почему у меня на контроллерах домена сеть оказывалась не доменной, ума не приложу.
Есть мысли, что это из-за настроек ipv6. Изначально там указано получать адрес автоматически. И Windows какой-то адрес получала. Даже не знаю откуда.
Пытался разобраться в теме ipv6, но скажу честно, сходу в нее не вник. Там все как-то не просто и надо погружаться, изучать. Пытался указывать ipv6 адрес вручную, статический. Думал, это может помочь. Почему-то после перезагрузки, настройки слетали обратно на получение адреса автоматически.
Отдельно пробовал настройку Предпочтение протокола IPv4 протоколу IPv6, как описано в руководстве на сайте microsoft. Это не помогло. На проблемном сервере гарантированно получал частную сеть вместо доменной.
Заключение
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!По факту каких-то проблем из-за данной настройки я не получал. Отличий в настройке фаервола в зависимости от типа сети у меня нет, так что видимых проблем не было. На текущий момент там, где последний раз словил эту ошибку, настроил отложенный запуск службы сведений о подключенных сетях (Network Location Awareness Service). Ошибка больше не воспроизводится. Буду наблюдать дальше.
Если вы сталкивались с подобными ошибками, либо есть советы, что еще попробовать, буду рад комментариям по этой теме.
DNS (Domain Name System, Система Доменных имен) – система, позволяющая преобразовать доменное имя в IP-адрес сервера и наоборот.
DNS-сервер – это сетевая служба, которая обеспечивает и поддерживает работу DNS. Служба DNS-сервера не требовательна к ресурсам машины. Если не подразумевается настройка иных ролей и служб на целевой машине, то минимальной конфигурации будет вполне достаточно.
Настройка сетевого адаптера для DNS-сервера
Установка DNS-сервера предполагает наличие доменной зоны, поэтому необходимо создать частную сеть в личном кабинете и подключить к ней виртуальные машины.
После того, как машина будет присоединена к двум сетям, важно не перепутать, какое из подключений требует настройки. Первичный сетевой адаптер настроен автоматически с самого начала, через него открыт доступ к интернету, в то время как на дополнительно подключенных сетевых адаптерах доступа в интернет нет, пока не будет произведена ручная настройка:
Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.
Далее предстоит проделать цепочку действий:
- Нажать правой клавишей мыши Пуск, в выпадающем меню выбрать пункт Сетевые подключения;
- Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
- В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
- Заполнить соответствующие поля необходимыми данными:
Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].
Установка роли DNS-сервера
Для установки дополнительных ролей на сервер используется Мастер Добавления Ролей и Компонентов, который можно найти в Диспетчере Сервера.
На верхней навигационной панели Диспетчера сервера справа откройте меню Управление, выберите опцию Добавить Роли и Компоненты:
Откроется окно Мастера, в котором рекомендуют убедиться что:
1. Учётная запись администратора защищена надёжным паролем.
2. Настроены сетевые параметры, такие как статические IP-адреса.
3. Установлены новейшие обновления безопасности из центра обновления Windows.
Убедившись, что все условия выполнены, нажимайте Далее;
Выберите Установку ролей и компонентов и нажмите Далее:
Выберите необходимый сервер из пула серверов и нажмите Далее:
Отметьте чек-боксом роль DNS-сервер и перейдите Далее:
Проверьте список компонентов для установки, подтвердите нажатием кнопки Добавить компоненты:
Оставьте список компонентов без изменений, нажмите Далее:
Прочитайте информацию и нажмите Далее:
В последний раз проверьте конфигурацию установки и подтвердите решение нажатием кнопки Установить:
Финальное окно Мастера сообщит, что установка прошла успешно, Мастер установки можно закрыть:
Создание зон прямого и обратного просмотра
Доменная зона — совокупность доменных имён в пределах конкретного домена.
Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.
Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.
Создание зон и управление ими осуществляется при помощи Диспетчера DNS.
Перейти к нему можно в правой части верхней навигационной панели, выбрав меню Средства и в выпадающем списке пункт DNS:
Создание зоны прямого просмотра
- Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:
- Откроется окно Мастера с приветствием, нажмите Далее:
- Из предложенных вариантов выберите Основная зона и перейдите Далее:
- При необходимости поменяйте название будущего файла зоны и перейдите Далее:
- Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:
- Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:
Создание зоны обратного просмотра
- Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер Создания Новой Зоны:
- Выберите назначение для адресов IPv4, нажмите Далее:
- Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:
- При необходимости поменяйте название будущего файла зоны и перейдите Далее:
- Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:
- Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:
Создание A-записи
Данный раздел инструкции в большей степени предназначен для проверки ранее проделанных шагов.
Ресурсная запись — единица хранения и передачи информации в DNS, заключает в себе сведения о соответствии какого-либо имени с определёнными служебными данными.
Запись A — запись, позволяющая по доменному имени узнать IP-адрес.
Запись PTR — запись, обратная A записи.
- В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду "Создать узел (A или AAAA). ":
- Откроется окно создания Нового Узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс Создать соответствующую PTR-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:
Если поле имени остается пустым, указанный адрес будет связан с именем доменной зоны.
- Также можно добавить записи для других серверов:
Проверка
- Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):
- Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:
- Запрос по домену;
- Запрос по IP-адресу:
В примере получены подходящие ответы по обоим запросам.
В дополнение к имени домена и адресам появилась строчка «Non-authoritative answer», это значит, что наш DNS-сервер не обладает необходимой полнотой информации по запрашиваемой зоне, а информация выведенная ниже, хоть и получена от авторитетного сервера, но сама в таком случае не является авторитетной.
Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:
Здесь машина сама себе назначена предпочитаемым DNS-сервером. Доменное имя DNS-сервера отображается как неопознанное, поскольку нигде нет ресурсных записей для IP-адреса (10.0.1.7). По этой же причине запрос 2 возвращает ошибку (Non-existent domain).
UPD2: Микрософт традиционно меняет привычный синаксис в командной строке, поэтому роли в кажлый версии Windows Server могут звучать по-разному. Они вообще теперь не fsmo называются а operation masters. Так вот, для корректных команд в консоли после fsmo maintenance напишите просто ? и он вам покажет доступные команды.
У меня в апрельский журнал "Системный администратор" взяли статью на тему "Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server"
И даже сто долларов заплатили и дали пакет с мозгами)) Я теперь Онотоле.
Безболезненная замена устаревшего или отказавшего контроллера домена на базе Windows Server. (кому вдруг надо - картинки пришлю)
Если ваш контроллер домена вышел из строя или полностью устарел и требует замены – не спешите планировать провести ближайшие выходные за созданием нового домена на новом сервере и кропотливым переносом в него пользовательских машин. Грамотное управление резервным контроллером домена поможет быстро и безболезненно заменить предыдущий сервер.
Практически каждый администратор, работающий с серверами на базе Windows, рано или поздно сталкивается с необходимостью замены полностью устаревшего основного контроллера домена, дальнейший апгрейд которого больше не имеет смысла, на новый и более соответствующий современным требованиям. Бывают ситуации и хуже – контроллер домена просто-напросто приходит в негодность из-за поломок на физическом уровне, а резервные копии и образы устарели, или потерялись
В принципе, описание процедуры замены одного контроллера домена на другой можно найти на разных форумах, но информация даётся отрывками и, как правило, применима только к конкретной ситуации, однако фактического решения не даёт. Кроме того, даже вдоволь начитавшись форумов [1], баз знаний [2, 3] и прочих ресурсов на английском языке – я смог грамотно провести процедуру замены контроллера домена без ошибок только с третьего или четвёртого раза.
Таким образом, я хочу привести поэтапную инструкцию замены контроллера домена вне зависимости от того работоспособен он или нет. Единственная разница заключается в том, что при «упавшем» контроллере эта статья поможет только если вы заранее позаботились и развернули резервный контроллер домена.
Подготовка серверов к повышению/понижению роли
Сама процедура создания резервного контроллера домена элементарна – мы просто запускаем на любом сервере сети мастер dcpromo. При помощи мастера dcpromo создаём контроллер домена в существующем домене. В результате проделанных манипуляций мы получаем развернутую службу каталогов AD на нашем дополнительном сервере (я буду называть его pserver, а основной контроллер - dcserver).
Дальше, если dcpromo сам не предложил – запускаем установку DNS сервера. Никаких настроек изменять не надо, зону создавать также не надо – она хранится в AD, и все записи автоматически реплицируются на резервный контроллер. Внимание – основная зона в DNS появится только после репликации, для ускорения которой сервер можно перезагрузить. В настройках TCP/IP сетевой карты резервного контроллера домена адресом первичного DNS сервера должен быть указан ip-адрес основного контроллер домена.
Теперь можно легко проверить работоспособность резервного контроллера домена pserver. Мы можем создать пользователя домена как на основном так и на резервном контроллере домена. Сразу после создания он появляется на дублирующем сервере, но где-то в течении минуты (пока происходит репликация) – он показан как отключенный, после чего начинает отображаться одинаково на обоих контроллерах.
На первый взгляд все действия по созданию исправной схемы взаимодействия нескольких контроллеров домена выполнены, и теперь, в случае выхода из строя «основного» контроллера домена, «резервные» контроллеры будут автоматически выполнять его функции. Однако, хотя разница между «основным» и «резервным» контроллерами домена чисто номинальная, «основной» контроллер домена имеет ряд особенностей (роли FSMO), о которых не стоит забывать. Таким образом, вышеприведенных операций для нормального функционирования службы каталогов при отказе «основного» контроллера домена не достаточно, и действия, которые надо произвести для грамотной передачи/захвата роли основного контроллера домена будут описаны ниже.
Нужно знать, что контроллеры домена Active Directory исполняют несколько видов ролей. Эти роли называются FSMO (Flexible single-master operations):
- Schema Master (Хозяин схемы) – роль отвечает за возможность изменения схемы – например разворачивания Exchange server или ISA server. Если владелец роли будет недоступен – схему существующего домена вы изменить не сможете;
- Domain Naming Master (Хозяин операции именования доменов) – роль необходима в том случае, если в вашем доменном лесу есть несколько доменов или поддоменов. Без неё не получится создавать и удалять домены в едином доменном лесу;
- Relative ID Master (Хозяин относительных идентификаторов) – отвечает за создание уникального ID для каждого объекта AD;
- Primary Domain Controller Emulator (Эмулятор основного контроллера домена) – именно он отвечает за работу с учётными записями пользователей и политику безопасности. Отсутствие связи с ним позволяет входить на рабочие станции со старым паролем, который нельзя сменить, если контроллер домена «упал»;
- Infrastructure Master (Хозяин Инфраструктуры) – роль отвечает за передачу информации об объектах AD прочим контроллерам домена в рамках всего леса.
Об этих ролях достаточно подробно написано во многих базах знаний, но основную роль практически всегда забывают – это роль Global Catalog (Глобального Каталога). По факту этот каталог просто запускает LDAP сервис на порту 3268, но именно его недоступность не позволит доменным пользователям входить в систему. Что примечательно – роль глобального каталога могут иметь все контроллеры домена одновременно.
Фактически можно сделать вывод – если у вас примитивный домен на 30-50 машин, без расширенной инфраструктуры, не включающий в себя поддомены - то отсутствие доступа к владельцу/владельцам первых двух ролей вы можете не заметить. Кроме того, мне несколько раз попадались организации, работающие больше года вообще без контроллера домена, но в доменной инфраструктуре. То есть все права были розданы давно, при работающем контроллере домена, и не нуждались в изменении, пароли пользователи себе не меняли и спокойно работали.
Определение текущих владельцев ролей fsmo.
Уточняю - мы грамотно хотим заменить контроллер домена, не потеряв никаких его возможностей. В том случае, если в домене два или более контроллеров, нам необходимо выяснить кто является обладателем каждой из ролей fsmo. Это достаточно просто сделать, использовав следующие команды:
dsquery server –hasfsmo schema
dsquery server – hasfsmo name
dsquery server – hasfsmo rid
dsquery server – hasfsmo pdc
dsquery server – hasfsmo infr
dsquery server –forest -isgc
Каждая из команд выводит нам информацию о том, кто является владельцем запрашиваемой роли (рис.1). В нашем случае владелец всех ролей – основной контроллер домена dcserver.
Добровольная передача ролей fsmo при помощи консолей Active Directory.
Вся информация, необходимая для передачи роли основного контроллера домена у нас есть. Приступаем: для начала нужно убедиться в том, что наша учётная запись входит в группы «Администраторы домена», «Администраторы схемы» и «Администраторы предприятия», а затем приступить к традиционному методу передачи ролей fsmo – управлением доменом через консоли Active Directory.
Для передачи роли “хозяина именования домена” выполняем следующие шаги:
- открываем «Active Directory Домены и Доверие» на том контроллере домена, с которого мы хотим передать роль. Если мы работаем с AD на том контроллере домена, которому мы хотим передать роль, то следующий пункт пропускаем;
- щёлкаем правой кнопкой мыши на значке Active Directory — домены и доверие и выбираем команду Подключение к контроллеру домена. Выбираем тот контроллер домена, которому хотим передать роль;
- щелкаем правой кнопкой мыши компонент Active Directory — домены и доверие и выбираем команду Хозяева операций;
- в диалоговом окне Изменение хозяина операций нажимаем кнопку Изменить (рис. 2).
- после утвердительного ответа на всплывающий запрос получаем успешно переданную роль.
Аналогичным образом, при помощи консоли «Active Directory — пользователи и компьютеры» можно передать роли «хозяин RID», «основной контроллер домена» и «хозяин инфраструктуры».
Для передачи роли «хозяина схемы» необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory:
regsvr32 schmmgmt.dll
Далее в консоль mmc необходимо добавить оснастку «Схема Active Directory», в которой, аналогично предыдущим пунктам, можно изменить владельца роли.
После того как все роли переданы остаётся разобраться с оставшейся опцией – хранителем глобального каталога. Заходим в Active Directory: «Сайты и Службы», сайт по умолчанию, сервера, находим контроллер домена, ставший основным, и в свойствах его NTDS settings ставим галочку напротив global catalog. (рис. 3)
Итог – мы поменяли хозяев ролей для нашего домена. Кому нужно окончательно избавиться от старого контроллера домена – понижаем его до рядового сервера. Однако простота проделанных действий окупается тем, что их выполнение в ряде ситуаций невозможно, или оканчивается ошибкой. В этих случаях нам поможет ntdsutil.exe.
Добровольная передача ролей fsmo при помощи консолей ntdsutil.exe.
На случай, если передача ролей fsmo при помощи консолей AD не удалась, Microsoft создал очень удобную утилиту – ntdsutil.exe – программа обслуживания каталога Active Directory. Этот инструмент позволяет выполнять чрезвычайно полезные действия – вплоть до восстановления всей базы данных AD из резервной копии, которую эта утилита сама создала во время последнего изменения в AD. Со всеми её возможностями можно ознакомиться в базе знаний Microsoft (Код статьи: 255504). В данном случае мы говорим о том, что утилита ntdsutil.exe позволяет как передавать роли, так и «отбирать» их.
Если мы хотим передать роль от существующего «основного» контроллера домена к «резервному» – мы заходим в систему на «основной» контроллер и начинаем передавать роли (команда transfer).
Если у нас по каким-то причинам отсутствует основной контролер домена, или мы не можем войти под административной учетной записью – мы входим в систему на резервный контроллер домена и начинаем «отбирать» роли (команда seize).
Итак первый случай – основной контроллер домена существует и функционирует нормально. Тогда мы заходим на основной контроллер домена и набираем следующие команды:
ntdsutil.exe
roles
connections
connect to server имя_сервера (того кому хотим отдать роль)
q
Если выскакивают ошибки – нужно проверить связь с тем контроллером домена, к которому мы пытаемся подключиться. Если ошибок нет – значит мы успешно подключились к указанному контроллеру домена с правами того пользователя, от имени которого вводим команды.
Полный список команд доступен после запроса fsmo maintenance стандартным знаком ? . Пришла пора передавать роли. Я сходу, не задумываясь, решил передавать роли в том порядке, в каком они указаны в инструкции к ntdsutil и пришёл к тому, что не смог передать роль хозяина инфраструктуры. Мне, в ответ на запрос о передаче роли, возвращалась ошибка: «невозможно связаться с текущим владельцем роли fsmo». Я долго искал информацию в сети и обнаружил, что большинство людей дошедших до этапа передачи ролей сталкиваются с этой ошибкой. Часть из них пытается отобрать эту роль принудительно (не выходит), часть оставляет всё как есть – и благополучно живёт без этой роли.
Я же путём проб и ошибок выяснил, что при передаче ролей в данном порядке гарантируется корректное завершение всех шагов:
- хозяин идентификаторов;
- хозяин схемы;
- хозяин именования;
- хозяин инфраструктуры;
- контроллер домена;
После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance), и можем начать передавать роли :
- transfer domain naming master
- transfer infrastructure master
- transfer rid master
- transfer schema master
- transfer pdc master
После выполнения каждой команды должен выходить запрос о том – действительно ли мы хотим передать указанную роль указанному серверу. Результат удачного выполнения команды показан на рис.4.
Роль хранителя глобального каталога передаётся способом, описанным в предыдущем разделе.
Принудительное присваивание ролей fsmo при помощи ntdsutil.exe.
Второй случай – мы хотим присвоить нашему резервному контроллеру домена роль основного. В этом случае ничего не меняется – единственная разница в том, что мы проводим все операции, с использованием команды seize, но уже на том сервере, которому хотим передать роли для присвоения роли.
seize domain naming master
seize infrastructure master
seize rid master
seize schema master
seize pdc
Обратите внимание – если вы отобрали роль у контроллера домена, отсутствующего в данный момент, то при его появлении в сети контроллеры начнут конфликтовать, и проблем в функционировании домена вам не избежать.
Работа над ошибками.
Самое главное, о чём не следует забывать – новый основной контроллер домена сам себе настройки TCP/IP не исправит: ему адресом первичного DNS сервера теперь желательно (а если старый контроллер домена + DNS сервер будут отсутствовать, то обязательно) указать 127.0.0.1 .
При этом если у вас в сети есть DHCP сервер, то нужно заставить его выдавать адресом первичного DNS сервера ip вашего нового сервера, если DHCP нет – пройтись по всем машинам и прописать им этот первичный DNS вручную. Как вариант, можно назначить новому контроллеру домена тот же ip что был у старого.
Теперь необходимо проверить как всё работает и избавиться от основных ошибок. Для этого я предлагаю на обоих контроллерах стереть все события с сохранением журналов в папку с прочими резервными копиями и перезагрузить все сервера.
После их включения внимательно анализируем все журналы событий на факт появления предупреждений и ошибок.
Установить эту утилиту можно с оригинального диска Windows 2003 из папки /support/tools. Утилита позволяет проверить работоспособность всех служб контроллера домена, каждый её этап должен оканчиваться словами successfully passed. Если у вас выходит failed (чаще всего это тесты connection или systemlog) то ошибку можно попробовать вылечить в автоматическом режиме:
dcdiag /v /fix
Как правило, все ошибки, связанные с DNS должны пропасть. Если нет – пользуемся утилитой проверки состояния всех сетевых служб:
И её полезным инструментом устранения ошибок:
netdiag /v /fix
Если и после этого остаются ошибки связанные с DNS – проще всего удалить из него все зоны и создать вручную. Это довольно просто – главное создать основную зону по имени домена, хранящуюся в Active Directory и реплицируемую на все контроллеры домена в сети.
Более подробную информацию об ошибках DNS даст ещё одна команда:
dcdiag /test:dns
По окончанию проделанных работ у меня ушло ещё где-то 30 минут на выяснение причины появления ряда предупреждений – я разобрался с синхронизацией времени, архивацией глобального каталога и прочими вещами, до которых раньше не доходили руки. Теперь всё работает как часы – самое главное не забудьте завести резервный контроллер домена, если вы хотите удалить старый контроллер домена из сети.
Довольно часто перед начинающими администраторами встает задача перенести контроллер домена на новое железо. В статье будет описан перенос контроллера домена под управлением Windows 2003 на новый сервер с установленной операционной системой Windows 2003. Переносить можно как с сохранением имени старого сервера, так и без сохранения имени. Статья рассчитана на совсем уж новичков, поэтому все будет разжевано.
- Домен: company.local;
- Старый сервер: Win2003, AD, DNS, DHCP, IP=192.168.0.100, имя=dc01;
- Новый сервер: Win2003, IP=192.168.0.101, имя=dc02;
1. Проверка действующего контроллера домена
, то их необходимо установить. Либо с установочного диска Windows 2003, либо с официального сайта. Если никаких ошибок не обнаружено, то идем дальше, если же появляются ошибки, то исправляем их. В принципе достаточно воспользоваться поиском по каждой из ошибок и найти решение.
2. Установка дополнительного контроллера домена
и в появившемся окне выбрать Additional domain controller for an existing domain
После установки AD, перезагружаемся.
3. Установка DNS и DHCP
Устанавливаем DNS и если нужно, то DHCP на новый сервер. Заходим в Установку и удаление программ (Add or Remove Programs) и выбираем пункт установка компонентов Windows (Add/Remove Windows Components). В разделе Сетевые службы (Network Services) ставим галочки напротив DNS и DHCP и устанавливаем их.
Вполне вероятно что при установке AD, заодно поставился и DNS, поэтому не пугайтесь если DNS уже установлен.
На обоих контроллерах домена выставляем в настройках DNS, адрес нового сервера.
4. Перенос базы DHCP
Если нужно перенести базу DHCP, на старом сервере выполняем команду:
переносим полученный файл на новый сервер и на новом сервере выполняем команду:
Ну и соответственно в настройках DHCP выставляем всем клиентам DNS адрес нового сервера 192.168.0.101
5. Проверка контроллеров домена на ошибки
После всех предыдущих манипуляций, ждем минут 15-20, чтобы дать новому серверу перенести все настройки и записи в AD со старого. После чего, запускаем на обоих серверах уже знакомые нам утилиты dcdiag и netdiag и убеждаемся в отсутствии ошибок.
6. Перемещение Global Catalog
7. Перенос ролей FSMO
Для начала посмотрим, кто же все таки является держателем ролей FSMO-ролей в домене, в этом нам поможет команда:
Результат будет примерно таким:
Как видно из вывода, держателем ролей является наш старый сервер dc01. Исправим это недоразумение. Все дальнейшие действия производим на новом сервере.
Передача ролей хозяин RID, основной контроллер домена и хозяин инфраструктуры
Открываем оснастку Active Directory — пользователи и компьютеры (Users and Computers), щелкаем правой кнопкой по имени сайта и выбираем меню Хозяева операций (Operations Masters). В появившемся окне, на всех 3-х вкладках жмем на кнопку изменить (change) и соглашаемся с применением изменений.
Передача роли хозяина именования домена
Открываем оснастку Active Directory — домены и доверие (Domain and Trusts), и точно так же выбираем меню Хозяева операций (Operations Masters). В появившемся окне жмем на кнопку изменить (change) и соглашаемся с применением изменений.
Передача роли хозяина схемы
С передачей этой роли все происходит немного посложнее. Для начала нужно зарегистрировать в системе библиотеку schmmgmt.dll. Для этого выполняем команду:
Далее запускаем оснастку mmc:
и в появившемся окне в меню файл выбираем пункт Добавить или удалить оснастку (Add/Remove Snap-in). Далее Добавить (Add) и Схема Active Directory (Active Directory Schema).
И добавляем схему. Далее так же выбираем меню Хозяева операций (Operations Masters). В появившемся окне жмем на кнопку изменить (change) и соглашаемся с применением изменений. Если в поле изменить будет стоять адрес старого сервера, то достаточно выбрать пункт меню Изменение контролера домена (Change Domain Controller) и выбрать новый домен контроллер, после чего опять попытаться изменить хозяина.
Ну что, все роли успешно перенесены на новый сервер.
8. Удаление старого контроллера домена
Теперь настала пора удалить старый домен контроллер из сети. Запускаем:
Читайте также: