Захват ролей FSMO из мертвого контроллера домена Windows

Роли, перечисленные в netdom query fsmo, совпадают с теми, которые я видел в других местах? Например, является ли владелец роли домена тем же, что и хозяин именования доменов? Диспетчер пула RID совпадает с ролью RID?

Да, точно. Не уверен, почему у них немного разные имена на этом конкретном дисплее.

Что плохого может случиться, если я займусь одной из этих ролей?

Сам припадок? Не много. Большинство потенциальных проблем, о которых предупреждают, связаны с повторным включением старого DC после того, как его роль была захвачена - и даже тогда существует много истерии из-за небольшого риска; нужны довольно странные сценарии, чтобы сломать что-либо с захватом вместо передачи роли. Чтобы ненадолго остановиться, давайте рассмотрим роли и возможные риски:

• Schema Master: Это заставляет всех сильно нервничать, но его нарушение - не очень вероятный сценарий. В документации говорится, что вы никогда не должны снова включать старый Schema Master после захвата роли, что я называю паникером. Старый сервер будет проинформирован об изменении роли, и как только это произойдет, он откажется от роли. Потенциальный риск здесь заключается в том, что в новый мастер схемы вносятся изменения, затем старый мастер схемы переводится в оперативный режим, а затем перед репликацией с других контроллеров домена, разные, конфликтующие, изменения схемы выполняются на старом сервере. Такая ситуация маловероятна, но разрушит ваш домен.

• Мастер именования: то же самое, что и с мастером схемы, вам нужно будет внести изменения (в данном случае создать новый домен в лесу) на старом контроллере домена после захвата его роли, но до того, как он узнает о захвате.

• Эмулятор PDC: Никакого риска, он не несет ответственности ни за что, если есть риск расхождения.

• RID Master: вам понадобится испорченная структура репликации, чтобы сломать эту - представьте, что у вас есть 2 DC; был занят старый мастер RID, который не знает своей роли, и новый мастер RID. В этой ситуации вам нужно будет создать достаточно объектов, чтобы исчерпать пул RID на обоих (их раздают по 500), и попросить их обоих назначить себе перекрывающиеся пулы. Создавайте объекты с идентичными RID, повторно подключайте контроллеры домена и наблюдайте, как разворачивается апокалипсис.

• Мастер инфраструктуры: честно говоря, вероятно, в 50% доменов в мире вообще нет работающего мастера инфраструктуры, поскольку он не работает, когда находится на GC. В любом случае судороги его не сломать.

Заметят ли пользователи?

Они не должны.

Такая установка существует уже давно, и люди функционируют более или менее нормально; собирается ли захват роли PDC изменить это?

Нет. При использовании одного контроллера домена ни одна из функций основного контроллера домена не теряется, за исключением того, что, возможно, ваш контроллер домена, не являющийся контроллером домена, не может синхронизировать время с источником, который он хочет (отсутствующий основной контроллер домена).

Тем более:

• Вы пропустите Мастер схемы только при попытке обновить схему.
• Вы пропустите Мастер именования только при попытке создать новый домен в лесу.
• Вы пропустите мастер RID только тогда, когда создадите слишком много объектов и исчерпаете пул RID вашего DC (вероятно, вы столкнетесь с этим, если вы просто продолжите работать как есть)
• Вам будет не хватать только мастера инфраструктуры для обновлений группы глобального каталога в многодоменном лесу.

Некоторые из этих документов предсказывают ужасные последствия для всех ролей на одном DC. С клиентской базой не более 20 - а в большинстве случаев, возможно, менее 10 - является ли реальной проблемой наличие всех ролей на одном DC?

Нет, но получите второй DC. Вы же не хотите, чтобы ваш единственный DC вышел из строя.

Есть ли какие-либо предостережения при выполнении процесса очистки, рекомендованного Microsoft для удаления старого контроллера домена из Active Directory?

Ага - будь осторожен. Но заточите свой ntdsutil ножами и вырвите старые данные - лишний хлам не помогает поддерживать домен.

Да, захватите эти роли. Вы - колебание мощности / зависание системы / солнечная вспышка вдали от катастрофы.

Это маловероятно, но пользователи могут заметить, если изменения учетной записи, кэшированные на их локальных машинах, не соответствуют AD.

У вас никогда не должно быть только одного DC. Минимум два, и по одному в каждом удаленном офисе. Если вы хотите использовать виртуальные машины (IMHO), они предназначены только для дополнения физических ящиков. И это только после того, как вы прочтете об использовании виртуальных машин в качестве контроллеров домена.

Я предпочитаю, чтобы все DC были GC. Это мое личное предпочтение, но это означает, что полная копия содержимого AD хранится на каждом DC с этой ролью. Если у вас есть два контроллера домена, но только один из них является сборщиком мусора, а этот умирает, я думаю, вы будете в таком положении, как если бы у вас был только один контроллер домена.

Ваш эмулятор PDC будет получать весь трафик от устаревших систем («системы», означающие машины, приложения и службы, такие как SQL Server 2000); поставил на железо.

Не обязательно плохо, что на одном контроллере домена есть все роли, ЕСЛИ у вас есть другие контроллеры домена и ваша репликация работает нормально.

Если нет действительно веская причина, вам обязательно следует использовать Microsoft DNS для внутреннего разрешения имен.

Исправьте свою среду, а затем обновите. Вы не рисуете тонущую лодку. Пока вы это делаете, серьезно подумайте о том, чтобы перейти к 2008 году. 2003 год находится на системе жизнеобеспечения.

Смотрите также: Что нужно делать после сбоя контроллера домена? и Как подключить еще один DC со всеми ролями, когда первый DC больше не доступен

Ваша текущая настройка (без работающих мастеров операций) представляет собой опасную и неподдерживаемую конфигурацию, которую необходимо исправить как можно скорее. Если отсутствующий сервер мертв и похоронен, захват ролей FSMO является необходимым шагом на пути к возобновлению нормальной работы.

Ответы на ваш конкретный вопрос:

1. Да, названия ролей с одинаковыми названиями, которые вы упоминаете, означают одно и то же.
2. Плохие вещи могут произойти, если вы захватите роль, а затем попытаетесь воскресить пропавший сервер, на котором она раньше была. Пожалуйста, убедитесь, что он мертв и закопан, прежде чем брать роли.
3. Пользователи вряд ли заметят какие-либо новые проблемы в результате захвата ролей FSMO.
4. Неспособность взять на себя роль вызовет проблемы в долгосрочной перспективе. Взятие роли сразу после отказа ее бывшего держателя не вызовет проблем.
5. На самом деле, для малых предприятий с 10-20 пользователями обычно используется один сервер со всеми ролями FSMO. и Обмен и Sharepoint. Это не создает серьезных проблем с производительностью, если сервер был указан правильно, но сайт гарантированно потерпит простой в случае отказа единственного сервера. Лучше всего иметь как минимум два контроллера домена на домен, даже если один из них представляет собой сервер Atom D525 стоимостью менее 500 долларов в шасси 1U.
6. Не особо, но любой обслуживание сервера несет в себе хоть какой-то риск. Как всегда, перед продолжением убедитесь, что у вас есть полные и проверенные резервные копии и план восстановления.
7. Это не должно быть проблемой, если вы сначала захватываете роли FSMO, а затем обновляете функциональный уровень домена.
8. Здесь нет хорошо причина использовать сторонний DNS для разрешения домена в среде Active Directory. Вам необходимо подготовить и реализовать план по переносу внутренних служб DNS на контроллер (ы) домена.

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