Рейтинг:0

Windows Active Directory — изменение настроек сервера времени после перемещения PDC/FSMO

флаг es

Мы настроили объект групповой политики для настройки нашего сервера PDC, как описано здесь (и во многих других блогах). https://docs.microsoft.com/en-us/archive/blogs/nepapfe/its-simple-time-configuration-in-active-directory

Это означает, что наш объект групповой политики использует фильтр, который применяется только к основному PDC, чтобы установить параметры NTP в качестве основного источника времени в нашем домене AD. Выберите * из Win32_ComputerSystem, где DomainRole = 5

Когда роли FSMO перемещаются на другой контроллер домена, эти настройки времени/ntp применяются к новому контроллеру домена, который действует как основной контроллер домена. Но после перемещения роли старый PDC по-прежнему настроен со СТАРЫМИ настройками ntp/time.

Чтобы исправить эту ситуацию, мы применяем эту ручную команду в СТАРОМ PDC. w32tm/config/syncfromflags:domhier/update

Но мы хотели бы сделать это автоматически, как мы можем это сделать? , как мы можем автоматически сбросить предыдущие настройки, которые все еще остаются на СТАРОМ PDC?

заранее спасибо

LeeM avatar
флаг cn
Если ответ сработал для вас, было бы полезно принять его как ответ и/или проголосовать за него.
Рейтинг:0
флаг cn

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

Чтобы перейти к погоне - на самом деле есть ДВА Объекты групповой политики, которые необходимо создать. Первый относится к PDCE с фильтром WMI и конфигурацией источника времени NTP, как вы сделали.

Второй упоминается под Создание объекта групповой политики с глобальными настройками в той статье. Как говорится, в другом GPO, отличном от PDCE, включите Глобальные параметры конфигурации под Конфигурация компьютера\Административные шаблоны\Система\Служба времени Windows\Поставщики времени и вы можете просто оставить значения по умолчанию.

Этот второй объект групповой политики для включения параметра времени «по умолчанию» должен применяться в групповой политике для все ДЦ. Убедитесь, что объект групповой политики, содержащий конфигурацию времени по умолчанию, имеет более низкий приоритет, чем приоритет PDCE.

Обычно, если у вас есть Контроллеры домена по умолчанию политики, связанной с OU контроллеров домена, можно просто включить базовую Глобальные параметры конфигурации для времени Windows там. Пользовательский объект групповой политики для PDCE заботится о конфигурации времени NTP при смене роли, а объект «по умолчанию» вернет настройку времени для старого PDCE.

Убедитесь, конечно, что ваш порядок ссылок GPO правильный в OU - опять же, ваш GPO пользовательской политики времени PDCE должен иметь более высокий приоритет, чем политика DC по умолчанию.

Если вы хотите создать собственный объект групповой политики, связанный с OU контроллеров домена для конфигурации времени по умолчанию, это тоже работает. Создание отдельного объекта групповой политики требует немного больше усилий, если у вас уже есть политика DC по умолчанию. Опять же, такой пользовательский объект групповой политики также должен иметь меньший приоритет, чем объект PDCE.

Я обнаружил, что в реальном мире в среде с хорошим подключением требуется < 5 минут, чтобы PDCE получил свою новую конфигурацию времени (или GPRefresh для ускорения), в то время как предыдущему PDCE требуется немного больше времени, чтобы вернуться к домену. иерархии в зависимости от времени обновления GP. А незначительный задержка для предыдущего PDCE, чтобы наверстать упущенное, в порядке.

Рейтинг:-2
флаг cv

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

Перемещение ролей FSMO при сохранении активного владельца текущей роли FSMO — еще более редкое событие, и поэтому это похоже на решение проблемы.

флаг es
В компании, в которой мы работаем, периодически делают DRP, и мы хотели бы избежать каких-либо дополнительных ручных действий, чтобы избежать возможных ошибок, которые уже случались в прошлом.
LeeM avatar
флаг cn
Это 100% неверно. Это нормально и на самом деле *настоятельно рекомендуется* изящно **переносить** роли FSMO перед действиями по обслуживанию (такими как установка исправлений) для держателя роли FSMO. Если у владельца роли FSMO произошел сбой из-за технического обслуживания, вам может потребоваться **захватить** роли на другой контроллер домена, что действительно должно быть редким явлением.В частности, PDCE важно передавать во время обслуживания — он синхронизирует время в домене и запускает циклы репликации. Нет PDCE = нет репликации и смещения во времени. *Всегда* переносите FSMO перед обслуживанием и проверяйте NTP на новом PDCE.
joeqwerty avatar
флаг cv
@LeeM ** Это нормально и на самом деле настоятельно рекомендуется изящно передавать роли FSMO перед действиями по обслуживанию (такими как установка исправлений) для держателя роли FSMO ** - я бы призвал вас процитировать любую документацию Microsoft, подтверждающую ваше утверждение. Никто никогда не передавал роли FSMO из-за исправления или планового обслуживания.
LeeM avatar
флаг cn
@joeqwerty - чувак, ты серьезно? Что произойдет, если ваш PDCE выйдет из строя из-за технического обслуживания? Как долго вы готовы работать, пока в вашем домене не работает репликация или меняется пароль? Вы можете какое-то время обойтись без мастера именования доменов, если вы не создаете новые контроллеры домена или дочерние домены или мастер инфраструктуры в лесах с одним доменом или все контроллеры домена являются GC. Даже мастер схемы, если вы не исправляете Exchange или другие изменения схемы. Не так много других или мастера NTP.
LeeM avatar
флаг cn
Что касается «цитирования, пожалуйста», если совет lMSFT и общепринятая передовая практика с 2000 года недостаточно для вас, пожалуйста, прочитайте: * Мы рекомендуем вам передавать роли FSMO в следующих сценариях: ... DC который в настоящее время владеет ролями FSMO, переводится в автономный режим для планового обслуживания, и вам необходимо назначить определенные роли FSMO действующим контроллерам домена... Это особенно верно для роли эмулятора PDC....* https://docs.microsoft. com/en-us/troubleshoot/windows-server/identity/transfer-or-seize-fsmo-roles-in-ad-ds#determine-когда-to-transfer-or-seize-roles
LeeM avatar
флаг cn
Еще один момент - вы понимаете разницу между *переводом* и *захватом*? Если вы на самом деле имеете в виду последнее, вы правы. Вы не бегаете *захватывая* роли, кроме как в крайнем случае. Что касается «Никто никогда не передавал роли FSMO из-за исправления ...», вау, очевидно, множество коллег и я с момента существования AD - «никто».
joeqwerty avatar
флаг cv
Никто из тех, кого я знаю, никогда не знал. работал или иным образом знал о том, что когда-либо передавал роли FSMO во время планового исправления держателя роли FSMO (обратите внимание, что я использовал слово «передача», а не захват ... точно так же, как я использовал его в своем предыдущем комментарии).
LeeM avatar
флаг cn
Я предлагаю вам изменить свои рабочие процедуры в соответствии с рекомендуемой практикой. Я работал в одном месте (из 8 средних), где мне впервые пришлось внедрять техническое обслуживание FSMO — правительства штатов раздражаются, когда ни один из их 20 000+ сотрудников не может изменить свои пароли и многие не могут войти в систему удаленно до истечения времени. дрейф на рабочих станциях от длительного простоя "FSMO DC" (в т.ч. PDCE) при плановой прошивке (тупо сделано в период праздников). Меня взяли на работу через 2 месяца после сбоя - больше такого не повторялось. Вам *повезло*, с маленьким окружением или нет.

Ответить или комментировать

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