none
Не применяются групповые политики на конечных рабочих станциях после перезапуска. RRS feed

  • Вопрос

  • Здравствуйте!
    С некоторых пор, на конечных станциях пользователей перестали применятся групповые политики. Поясняю, если в домен заводится новая рабочая станция с новым DNS именем, то все отрабатывается замечательно. Перестали они применяться на рабочих станциях, которые уже более года работают в ЛВС.
    Делаем gpupdate, - не применилась ГПО. Делаем gpupdate /force - все получается. Ну не бегать же после каждой перезагрузки к рабочей станции. Учетки этих рабочих станций удалял, по новой проводил идентификацию, - то же самое.
    Windows 2003 Server R2, WinXP sp2

     

    30 ноября 2007 г. 6:54

Ответы

  •  

    Лишний раз убедился - хочешь сделать хорошо, сделай это сам.

    Причина была в том, что в настройках параметров брандмауэра Windows объекта групповой политики, был настроен только профиль домена, а стандартный не был настроен. Когда все настроил идентично друг другу проблема снялась полностью.

    14 марта 2008 г. 13:43

Все ответы

  •  

    Включите на рабочей станции запись в лог процесса применения групповых политик и посмотрите отличия при выполнении gpupdate и gpupdate /force.

     

    http://technet2.microsoft.com/windowsserver/en/library/b7baac12-26c2-4271-bb39-f607644322471033.mspx 

    30 ноября 2007 г. 8:08
    Модератор
  • А что выдает gpresult? В логах ошибки есть? Возможно, между DC и станциями есть разница в часовых поясах(политики не будут применятья при разнице более 15 минут)

     

    30 ноября 2007 г. 8:17
  •  

    Исключено. У меня все WS синхронизируются на одном сервере по времени.
    30 ноября 2007 г. 8:36
  •  

    Содержание Userenv после gpupdate:

     

    - USERENV(31c.970) 13:40:53:382 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.
    USERENV(31c.528) 13:40:53:412 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.

     

    Содержание Userenv после gpupdate /force:

     - USERENV(31c.528) 13:42:00:068 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.
    USERENV(31c.970) 13:42:00:118 GetGPOInfo:  Local GPO's gpt.ini is not accessible, assuming default state.
    USERENV(31c.894) 13:42:03:913 PolicyChangedThread: UpdateUser failed with 6.

     

    В первом случае не применились, во втором применились.

    30 ноября 2007 г. 8:48
  • Можно попробывать rsop.msc запустить на станции и посмотреть что да как...

    30 ноября 2007 г. 8:58
  • попробуйте увеличить таймаут

     

    http://support.microsoft.com/default.aspx?scid=kb;en-us;840669

     

    и проверьте всё ли впорядке с правами %windir%\system32\grouppolicy

    на клиентских машинах.

     

    30 ноября 2007 г. 8:59
  •  Vitaliy Shestakov написано:

    Можно попробывать rsop.msc запустить на станции и посмотреть что да как...

     

    Да, это я запускал и смотрел. Там видно все, что выставлено в AD. Все тоже самое.

    30 ноября 2007 г. 9:29
  •  

    Так же там можно посмотреть какие политики применились а какие нет, и главное почему...

    Правым кликом по Computer Configuration и/или User configuration раздел Error Information

     

    А вообще то ЛОГИ, где ЛОГИ??? Телепатов тут нема

    30 ноября 2007 г. 9:34
  •  se000 написано:

    попробуйте увеличить таймаут

     

    http://support.microsoft.com/default.aspx?scid=kb;en-us;840669

     

    и проверьте всё ли впорядке с правами %windir%\system32\grouppolicy

    на клиентских машинах.

     

     

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

     

     

    %windir%\system32\grouppolicy - ни папки , ни файла такого на клиентских машинах нет.
    30 ноября 2007 г. 9:35
  •  Vitaliy Shestakov написано:

     

    Так же там можно посмотреть какие политики применились а какие нет, и главное почему...

    Правым кликом по Computer Configuration и/или User configuration раздел Error Information

     

    А вообще то ЛОГИ, где ЛОГИ??? Телепатов тут нема

     

    В том разделе нет ошибок, везде - Успех!

    Я выше давал данные из userenv , какие еще дать?

    30 ноября 2007 г. 9:44
  • А если так:

    Заходим в сетевые подключения. Выбираем вверху пункт дополнительно. Далее дополнительные параметры. Порядок служб доступа. Перемещаем Microsoft Network вверх. Пробуем обновить политики.

    30 ноября 2007 г. 11:24
  •  Joker Alvares написано:

    В том разделе нет ошибок, везде - Успех!

    Я выше давал данные из userenv , какие еще дать?

     

    Так откуда тогда сведения что политики не применяются???

    Если gpupdate на машине на которой якобы "не применяются" политики говорит что все хорошо, значит все хорошо, если бы политики не применялись он бы это отразил у себя и написал что да как.

    Надо попробывать на нескольких машинах, думается мне.

    Логи у клиента ес-но о том что не может что то или где то ошибки и предупреждения, хотя скорее всего ошибки.

    И не gpupdate ошибки, а Event Viewer (Application и System)

     

     Undel написано:

    А если так:

    Заходим в сетевые подключения. Выбираем вверху пункт дополнительно. Далее дополнительные параметры. Порядок служб доступа. Перемещаем Microsoft Network вверх. Пробуем обновить политики.

    Это делать сооооовсем незачем...

    30 ноября 2007 г. 11:55
  •  Joker Alvares написано:
     

    %windir%\system32\grouppolicy - ни папки , ни файла такого на клиентских машинах нет.

     

    должен быть. он скрытый.

    30 ноября 2007 г. 11:56
  •  se000 написано:
     Joker Alvares написано:
     

    %windir%\system32\grouppolicy - ни папки , ни файла такого на клиентских машинах нет.

     

    должен быть. он скрытый.

     

    Нет такого файла\папки

    3 декабря 2007 г. 7:23
  •  Vitaliy Shestakov написано:
     Joker Alvares написано:

    В том разделе нет ошибок, везде - Успех!

    Я выше давал данные из userenv , какие еще дать?

     

    Так откуда тогда сведения что политики не применяются???

    Если gpupdate на машине на которой якобы "не применяются" политики говорит что все хорошо, значит все хорошо, если бы политики не применялись он бы это отразил у себя и написал что да как.

    Надо попробывать на нескольких машинах, думается мне.

    Логи у клиента ес-но о том что не может что то или где то ошибки и предупреждения, хотя скорее всего ошибки.

    И не gpupdate ошибки, а Event Viewer (Application и System)

     

    Я имею ввиду, что если применены политики, то в брандмауре в списке исключений видны выставленные в ГПО значения. А так на общей вкладке брандмауер пишет "Некоторые параметры управляются групповой политикой", а на самом деле их нет в списке. Делаем  gpupdate /force - значения появляются. Причем просто gpupdate не срабатывает. Слушай, и еще момент, у меня устанавливается Клиент межсетевого экрана для ISA server 2004. Может он как то влияет на брандмауер?

    3 декабря 2007 г. 7:31
  •  Vitaliy Shestakov написано:
     Joker Alvares написано:

    В том разделе нет ошибок, везде - Успех!

    Я выше давал данные из userenv , какие еще дать?

     

    Так откуда тогда сведения что политики не применяются???

    Если gpupdate на машине на которой якобы "не применяются" политики говорит что все хорошо, значит все хорошо, если бы политики не применялись он бы это отразил у себя и написал что да как.

    Надо попробывать на нескольких машинах, думается мне.

    Логи у клиента ес-но о том что не может что то или где то ошибки и предупреждения, хотя скорее всего ошибки.

    И не gpupdate ошибки, а Event Viewer (Application и System)

     

     

    Разобрался я!

    У меня еще на клиентскую машину ставится клиент межсетевого экрана для ISA server 2004. Как только он устанавливается, в списке исключений брандмауера пропадают значения исключений для портов и программ. Как только мы его (клиента) отключаем , либо удаляем, все политики применяются и отрабатыватся отлично. Тогда вопрос, почему? И можно ли сделать так, чтоб эти два экрана существовали параллельно не мешая друг другу?

    3 декабря 2007 г. 8:32
  •  

    Так как все таки сделать так, чтобы ISA  клиент спокойно себя чувствовал с брандмауером ХР? Хорошим бы вариантом было настроить запуск службы ISA клиента с отсрочкой скажем на 1 минуту, тогда бы все отрабатывалось. Но как это сделать? Есть соображения?
    13 февраля 2008 г. 10:00
  • Это же служба, а для служб можно настроить зависимости, т.е. задать порядок загрузки.

    13 февраля 2008 г. 11:24
    Модератор
  •  

    Нууу,в  предыдущем посте я про это и спрашивал, знаю я, что есть такая возможность! Главный то вопрос - КАК и в каком порядке это сделать, а главное, правильно! Посоветуйте, пожалуйста.
    13 февраля 2008 г. 15:05
  •  

    На разных станциях в управлении рабочей станцией в оснастке "Службы" в свойствах брандмауера Windows на вкладке восстановление выставлены параметры в случае сбоя "Не выполнять никаких действий", я выставил на первый и второй сбой  "Перезапуск службы" - политики применяются первый раз после перезапуска. После второго перезапуска, опять не применяются. Где еще копать?? Блин, голову уже сломал почти.
    14 февраля 2008 г. 3:25
  • Специально для вас:  How to delay loading of specific services

    14 февраля 2008 г. 13:18
    Модератор
  •  

    О, спасибо, попробую, о результате сообщу.
    18 февраля 2008 г. 8:45
  •  sie написано:

    Специально для вас:  How to delay loading of specific services

     

    Попробовал, в качестве зависимости использовал службу Spooler, так как она вместе с Messenger запускается последней, то есть служба агента межсетевого экрана запустилась последней. Все равно, в брандмауере нет групповых политик, указано только, что некоторые параметры управляются групповой политикой.  Убрал ярлык агента межсетевого экрана из: Пуск>Автозагрузка, перезапустил машину, - все ок, все политики в наличии. Операционка (WinXPsp2) только что установлена на рабочей станции (что исключает "шаловливые ручки"), обновления все самые последние, домен 2003 sp2 R2, тут тоже все самые последние обновления.

    18 февраля 2008 г. 9:11
  •  

    Есть еще соображения?
    20 февраля 2008 г. 5:53
  •  

    Лишний раз убедился - хочешь сделать хорошо, сделай это сам.

    Причина была в том, что в настройках параметров брандмауэра Windows объекта групповой политики, был настроен только профиль домена, а стандартный не был настроен. Когда все настроил идентично друг другу проблема снялась полностью.

    14 марта 2008 г. 13:43