Комментарии 37
Статья опоздала лет на 10 или даже 15.
Windows 7, 775 сокет, сокет 1155. Накатил винду версии 1809, обновления пока не ставил.
Вам такое надо публиковать на https://overclockers.ru/. Там любят подобную некрофилию.
Для чего мне все это надо — на это вопрос я не смог ответить.
Куча свободного времени, которое просто некуда потратить. Вот и ответ на ваш вопрос.
Результат прежний — политики применяются через 15 секунд. Бесит только одно — почему не сразу, а через 15 сек. Ладно, думаю, что потом разберусь.
Раньше говорили RTFM и отправляли читать документацию. В вашем случае нужна книга "Настройка Active Directory. Windows Server 2008 (70-640)". Она как раз из тех древних времён, которым посвящена ваша статья. Там есть несколько глав, посвящённых групповым политикам. Там есть всё, что вам нужно и даже больше.
Я и другие комментаторы к прошлой статье подобные развернутые комменты написали, но автор кинул обидку :D
Не все люди готовы принять окружающую действительность. Это нормально. Иногда для этого требуются годы.
Изучение старых технологий для некоторых людей становится чем-то вроде хобби, которое позволяет убежать от проблем в реальности. Старые технологии застыли в развитии, а значит, там есть стабильность, которой так не хватает человеку в постоянно меняющейся реальности.
В предыдущей статье я сказал
в какой? написано что 1 часть
Почему я задался целью обойти время применения политик к локальным компьютерам?
Ну вы же знаете что я сейчас напишу? )
и с сервера послал команду
Invoke-GPUpdate -RandomDelayInMinutes 0
Такую?
Резюмирую. Я все настроил, встретились кое-какие проблемы, но я их решил - как, я вам конечно же не скажу. Спасибо за статью.
Какую команду посылаете с сервера для применения политик?
Немного терпения. Сегодня, крайний срок завтра выкладываю финальную часть.
Ну вы опять написали каких-то криповых вещей.
Групповая политика не должна применяться мгновенно. Время ее применения зависит от refresh interval, задействованных extensions и числа и характера обрабатываемых настроек.
Групповая политика не должна применяться мгновенно
Вы уверены в этом?
На 146%. Ничего мгновенного не бывает, и ещё раз, это зависит от конкретного extension и что ему отдали на обработку. Если это монтирование дисков или ваш любимый folder redirection, можно долго ждать результат.
Плюс не забывайте про синхронный и асинхронный режим применения.
Плюс не забывайте про синхронный и асинхронный режим применения.
Я об этом знаю. Но, чтобы не плодить, а если, попробуйте выполнить все на практике. Это долгий, но самый действенный вариант. Вот когда у вас не заработает, тогда и будет о чем поговорить.
А ничего что пользователю/компьютеру необходим новый вход (logout/login) для примения участия в группах?
В том то и дело, что не обязателен.
В некоторых ситуациях изменение членства в domain local группах не требует повторный вход, если на целевой сервис ещё не выдавался билет Kerberos. Но это не точно)
А это как то можно отследить?
К сожалению, я не смог решить проблему отслеживания. Только в PowerShell можно увидеть, что политика прошла.
В том и проблема что не знаю как. Смотрите, сейчас могу приврать. Список универсальных и глобальных групп при входе добавляются и хранятся в tgt, у Microsoft для этого есть вендорское расширение. Причем после purge, не заметил, чтобы добавлялись новые (почему?) А локальные группы добавляются контроллером только в service ticket, плюс в него добавляется список групп из tgt.
Ситуация усложняется, если сервис находится ещё и в другом домене (или лесу).
Тема мутная, потому повторный вход всегда надёжнее.
Вот здесь описан механизм, который я до конца не понимаю
[MS-PAC]: Rules for SID Inclusion in the PAC | Microsoft Learn
Я по английиски знаю тольк рашен водка. А в машинном переводе могут быть такие неточности и ошибки, что сам черт не разберет. Извините, здесь я вам не помощник.
Добрый день!
Подскажите, что это за документ? Просто из этой статьи можно провалиться только напрямую в \learn.
Не могу ответить. Сам сомневаюсь.
Применение GPO почти всегда требует повторного входа. Ну или ждать, когда сервер в течение времени до 90 мин обработает политику. Повторный вход помогает, когда политика принята компьютером, но ждет выхода\входа в систему для применения.
Нужен не вход, а обновление выданных билетов Kerberos. Новый вход это просто форсирует, а так обычно можно с помощью klist purge для нужной учетки справиться.
А что мешает сбросить керберос тикет и послать gpupdate через тот же invoke-command и не ждать стандартные 8 часов жизни тикета? Кроме религии?
klist -lh 0 -li 0x3e7 purge
Или (с 2016)
klist –li 0x3e7 purge
И потом gpupdate любым из 3х вариантов доступных
Да мало того, но обе десятки странным образом не хотят видеть папки SYSVOL и NETLOGON сервера
Вот это ещё забавное.
Как обойти ребут РС при применении групповых политик. Часть 1