[Отказ от ответственности: этот вопрос был основан на ошибочных впечатлениях. Взять с собой очень мелкая крупинка соли или совсем без соли.]
Как администратор Linux, который неохотно возвращается к администрированию Windows после всего лишь десятилетнего отсутствия прикасания к серверам Windows, я немного озадачен некоторыми вещами о групповой политике в наши дни по сравнению с тем, как это делалось раньше, когда .
Я до сих пор помню те дни, когда была вкладка групповой политики для определенных объектов в ADUC (скажем, с Windows Server 2003), таких как OU (если я правильно помню), но похоже, что теперь ADUC и групповая политика были разделены на другое управление. консоли и отключены, а GPMC теперь является местом для GPO. Я уверен, что для этого есть веские причины. Однако теперь у меня есть несколько вопросов.
Почему кажется, что структура и имена OU, а также связь GPO с фактическими объектами AD в ADUC полностью отделены от их аналогов GPMC? Похоже, что администратор GP должен проявлять бдительность, чтобы имитировать любые изменения, внесенные в именование или структуру OU в ADUC в GPMC, но я вижу, что это неизбежно идет наперекосяк, поскольку время от времени неизбежно будут происходить ошибки и упущения.
Очевидно, что ИТ-администратор должен быть достаточно умен и бдителен, чтобы убедиться, что нет никаких несоответствий, но то, как разделение ADUC и GPMC действительно улучшает технологически Говорящий? Кажется, что автоматизация и проверка соответствия между ними должны быть не только возможными, но и тривиальными. В Windows Server 2003 казалось, что объекты групповой политики были напрямую связаны с самими объектами AD, поэтому объекты групповой политики будут следовать за объектами независимо от того, что вы с ними сделали; в то время как я где-то читал, что теперь объекты групповой политики «не принадлежат объекту AD» с точки зрения прямой ассоциации и связи. В чем причина этого изменения?
Но, возможно, я просто читал не ту документацию и совершенно неправильно понял ситуацию [Edit: да].
Спасибо, что терпеливо объяснили это администратору Linux.
OU, которые вы видите в GPMC, на самом деле те же самые OU, которые вы видите в ADUC. Переименуйте в одном, и он будет переименован в другом (ожидающая репликация, если не подключен к тому же DC) после обновления представления.
Короче говоря, они по-прежнему связаны так же, как и всегда. Вы просто не видите в GPMC дочерних объектов, не являющихся объектами групповой политики, потому что приложение предпочитает не отображать их.
Поскольку подразделения групповой политики не привязаны напрямую к подразделениям в ADUC
Групповые политики очень тесно интегрированы в AD и связаны с подразделениями.
\\example.org\SYSVOL\example.org\Policies)CN=Policies,CN=System,DC=example,DC=org контейнерgPLink свойство данной OU. Get-ADObject 'OU=Domain Controllers,DC=example,DC=org' -Properties DistinguishedName, gpLinkМногие ваши вопросы, кажется, связаны с несовпадением двух инструментов. Возможно, два инструмента устарели, если у вас оба открыты. Или, возможно, вы каким-то образом подключились к другому контроллеру домена, и репликация того, что вы сохранили, не завершена. Но GPMC, безусловно, хранит информацию о политиках непосредственно в AD. Если вы выполните принудительное обновление или подождите несколько минут, внесенные вами изменения должны синхронизироваться.
Следует отметить, что в консоли управления групповыми политиками вы не увидите значение по умолчанию. Компьютеры или Пользователи контейнеры, потому что они Контейнеры, а не OU. GPO нельзя связать с этими контейнерами. Объекты групповой политики, связанные в корне домена, и объекты групповой политики, связанные на уровне сайта, будут применяться к объектам в этих двух контейнерах по умолчанию.