Windows не удалось применить параметры group policy power options

Здравствуйте. С тех пор, как я начал использовать  preferences политики (это новый тип политик в 2008 сервере), стали на рабочих станциях Windows Vista и на сервере терминалов Windows 2008 возникать в логах ошибки. С помощью preferences политики у меня подключаются принтеры в зависимости от доменных групп. Ошибки такие: Источник: GroupPolicy Код события: 1091 Windows не удалось записать информацию результирующей политики (RSoP) для расширения групповой политики . Параметры групповой политики были успешно применены к этому компьютеру или пользователю; однако возможно, что средства управления не дают правильного отчета И еще ошибка. Источник: Group Policy Printers Код события:4099 Клиентскому расширению не удалось записать в журнал данные RSoP по причине ошибки с кодом "0x8004401e ". В результате чего, при заходе пользователя на сервер терминалов 2008 весит табличка, что применяю Group Policy Printers. На Windows Vista изредка отваливаются принтеры. Подскажите, каким образом возможно решить данную проблему?
  • Remove From My Forums
  • Вопрос

  • Здравствуйте.

    С тех пор, как я начал использовать  preferences политики (это новый тип политик в 2008 сервере), стали на рабочих станциях Windows Vista и на
    сервере терминалов Windows 2008 возникать в логах ошибки.

    С помощью preferences политики у меня подключаются принтеры в зависимости от доменных групп.

    Ошибки такие:

    Источник: GroupPolicy

    Код события: 1091

    Windows не удалось записать информацию результирующей политики (RSoP) для расширения групповой политики <Group Policy Power Options>. Параметры групповой политики были успешно
    применены к этому компьютеру или пользователю; однако возможно, что средства управления не дают правильного отчета

    И еще ошибка.

    Источник: Group Policy Printers

    Код события:4099

    Клиентскому расширению не удалось записать в журнал данные RSoP по причине ошибки с кодом «0x8004401e <unknown-message-text>».

    В результате чего, при заходе пользователя на сервер терминалов 2008 весит табличка, что применяю
    Group Policy Printers.

    На Windows Vista изредка отваливаются принтеры.

    Подскажите, каким образом возможно решить данную проблему?

    • Перемещено

      22 апреля 2012 г. 0:55
      (От:Windows Server 2008)

Ответы

  • Плохо… Потому что вариантов решения очень много ))))

    1) Возможно проблема с UAC. Решение
    тут.

    2) Возможно проблема с WMI. Решение
    тут.

    3) И еще хорошая статья о том, как решать проблемы с ГП, которые не желают применяться

    тут.


    Данный форум является бесплатным сервисом Microsoft с целью оказания посильной помощи пользователям и повышения уровня знаний о продуктах Microsoft. Информация, представленная на форуме, распространяется «как
    есть» без официальной ответственности компании Microsoft.

    • Помечено в качестве ответа
      akamsp
      15 сентября 2010 г. 7:09

На одном из компьютеров перестали применяться новые параметры групповых политик. Для диагностики я вручную обновил параметров GPO с помощью команды
gpupdate /force
и увидел такую ошибку в консоли:

Не удалось успешно обновить политику компьютера. Обнаружены следующие ошибки:
Ошибка при обработке групповой политики. Windows не удалось применить основанные на данных реестра параметры политики для объекта групповой политики "LocalGPO". Параметры групповой политики не могут быть применены, пока не будет исправлена эта ситуация. Сведения об имени и пути файла, вызвавшего эту ошибку, содержатся в подробностях об этом событии.
Computer policy could not be updated successfully. The following errors were encountered:
 The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

Ошибка при обработке групповой политики. Windows не удалось применить

При этом в журнале System появляется событие с EvetID 1096 с тем же описанием (The processing of Group Policy failed):

Log Name:     System
Source:       Microsoft-Windows-GroupPolicy
Event ID:     1096
Level:         Error
User:         SYSTEM

Если попробовать выполнить диагностику применения GPO с помощью команды gpresult (
gpresult.exe /h c:temptgpresultreport.html
), видно что не применяется только настройки из раздела Group Policy Registry —
Failed
:

Registry failed due to the following error listed below.
Additional information may have been logged. Review the Policy Events tab in the console or the application event log.

Group Policy Registry - Failed: Registry failed due to the following error listed below

Получается, что к компьютеру не применяются только GPO с настройками клиентских расширений групповых политик CSE (client-side extension), которые отвечают за управление ключами реестра через GPO.

Расширение Registry client-side не смогло прочитать файл registry.pol. Скорее всего файл это поврежден (рекомендуем проверить файловую систему на ошибки с помощью chkdsk). Чтобы пересоздать этот файл, перейдите в каталог c:WindowsSystem32GroupPolicyMachine и переименуйте его в registry.bak.

пересоздать файл registry.pol в Windows

Можно переименовать файл из командой строки:

cd "C:WindowsSystem32GroupPolicyMachine"
ren registry.pol registry.bak

Обновите настройки групповых политик командой:

gpupdate /force

Windows должна пересоздать файл registry.pol (настройки локальных GPO будут сброшены) и успешно применить все настройки GPO.

Если в журнале вы видите событие Event ID 1096 (
The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://
) c ErrorCode 13 и описанием “
The data is invalid
”, значит проблема связана с доменной GPO, указанной в ошибке.

eventid 1095 The processing of Group Policy failed LDAP data is invalid

Скопируйте GUID политики и найдите имя GPO с помощь команды PowerShell:

Get-GPO -Guid 19022B70-0025-470E-BE99-8348E6E606C7

  • Запустите консоль управления доменными GPO (gpmc.msc) и проверьте, что политика существует;
  • Проверьте, что в каталоге SYSVOL политики есть файлы registry.pol и gpt.ini и они доступны на чтение (проверьте NTFS права);
  • Проверьте, что версия политики на разных контроллерах домена одинакова (проверьте корректность работы домена и репликации в AD);
  • Удалите файлы GPO в SYSVOL на контроллере домена, с которого получает политику клиент (
    $env:LOGONSERVER
    ), и дождитесь ее репликации с соседнего DC
  • Если предыдущие способы не помогут, пересоздайте GPO или восстановите ее из бэкапа.

Windows 7 Enterprise Windows 7 Professional Windows 7 Ultimate Windows Server 2008 R2 Datacenter Windows Server 2008 R2 Enterprise Windows Server 2008 R2 for Itanium-Based Systems Windows Server 2008 R2 Foundation Windows Server 2008 R2 Standard Windows Server 2008 R2 Web Edition More…Less

Symptoms

When you use Group Policy to configure the power plan in a domain, power options do not work correctly on a client computer that is running Windows 7 or Windows Server 2008 R2.

For example, you use Group Policy to configure the Allow hybrid sleep setting to OFF. However, you may notice that the Allow hybrid sleep setting is set to ON instead of to OFF on a client computer that is running Windows 7.

Cause

This issue occurs because the index value setting in Group Policy is the opposite of the index value setting in Windows Power Management.

Resolution

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft website:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Prerequisites

To apply this hotfix, you must be running one of the following operating systems:

  • Windows 7

  • Windows 7 Service Pack 1 (SP1)

  • Windows Server 2008 R2

  • Windows Server 2008 R2 Service Pack 1 (SP1)

For more information about how to obtain a Windows 7 or a Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:

976932 Information about Service Pack 1 for Windows 7 and for Windows Server 2008 R2

Registry information

To use the hotfix in this package, you do not have to make any changes to the registry.

Restart requirement

You must restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.

Windows 7 and Windows Server 2008 R2 file information notes
  • The files that apply to a specific product, milestone (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table:

    Version

    Product

    Milestone

    Service branch

    6.1.760
    0.20xxx

    Windows 7 and Windows Server 2008 R2

    RTM

    LDR

    6.1.760
    1.21xxx

    Windows 7 and Windows Server 2008 R2

    SP1

    LDR

  • The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the «Additional file information for Windows Server 2008 R2 and for Windows 7» section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are very important for maintaining the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.

For all supported x86-based versions of Windows 7

File name

File version

File size

Date

Time

Platform

Gpprefcl.dll

6.1.7600.20924

585,216

15-Mar-2011

05:17

x86

Gpprefcl.dll

6.1.7601.21683

585,216

15-Mar-2011

04:18

x86

For all supported x64-based versions of Windows 7 and of Windows Server 2008 R2

File name

File version

File size

Date

Time

Platform

Gpprefcl.dll

6.1.7600.20924

785,920

15-Mar-2011

05:48

x64

Gpprefcl.dll

6.1.7601.21683

785,920

15-Mar-2011

05:13

x64

Gpprefcl.dll

6.1.7600.20924

585,216

15-Mar-2011

05:17

x86

Gpprefcl.dll

6.1.7601.21683

585,216

15-Mar-2011

04:18

x86

For all supported IA-64-based versions of Windows Server 2008 R2

File name

File version

File size

Date

Time

Platform

Gpprefcl.dll

6.1.7600.20924

1,504,256

15-Mar-2011

04:34

IA-64

Gpprefcl.dll

6.1.7601.21683

1,505,280

15-Mar-2011

04:02

IA-64

Gpprefcl.dll

6.1.7600.20924

585,216

15-Mar-2011

05:17

x86

Gpprefcl.dll

6.1.7601.21683

585,216

15-Mar-2011

04:18

x86

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.

More Information

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates

For more information about the Power Options preference extension in Group Policy, visit the following Microsoft TechNet website:

General information about the Power Options preference extensionTo configure power options, use the following Group Policy that is mentioned in the «Symptoms» section:

Computer Configuration -> Preferences -> Control Panel Settings -> Power Options

Additional file information

Additional file information for Windows 7 and for Windows Server 2008 R2

Additional files for all supported x86-based versions of Windows 7

File name

Update.mum

File version

Not applicable

File size

2,350

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

X86_2850a86fb4970b33e742c548a23a4d25_31bf3856ad364e35_6.1.7600.20924_none_febdef2de737b3de.manifest

File version

Not applicable

File size

711

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

X86_8af307f6bb46168b73297c12753bde72_31bf3856ad364e35_6.1.7601.21683_none_6c6424dc5d763b3f.manifest

File version

Not applicable

File size

711

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

X86_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7600.20924_none_37e9109dc33d59e3.manifest

File version

Not applicable

File size

53,968

Date (UTC)

15-Mar-2011

Time (UTC)

05:48

Platform

Not applicable

File name

X86_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7601.21683_none_398d8bebc09556f7.manifest

File version

Not applicable

File size

53,968

Date (UTC)

15-Mar-2011

Time (UTC)

04:46

Platform

Not applicable

Additional files for all supported x64-based versions of Windows 7 and of Windows Server 2008 R2

File name

Amd64_07c234fd532a7af49bfcc610fe92759f_31bf3856ad364e35_6.1.7600.20924_none_ee7f56efa831b685.manifest

File version

Not applicable

File size

1,070

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_11c9f86d7bc75d634637d0a1bf8ec154_31bf3856ad364e35_6.1.7601.21683_none_df16a33d7a9b9f27.manifest

File version

Not applicable

File size

715

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_26d3c383fd423476750c5acc9201e1bb_31bf3856ad364e35_6.1.7601.21683_none_b6f698a3f7aeafcf.manifest

File version

Not applicable

File size

715

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_2850a86fb4970b33e742c548a23a4d25_31bf3856ad364e35_6.1.7600.20924_none_5adc8ab19f952514.manifest

File version

Not applicable

File size

713

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_7a10e5afbbdfad3abd3626ea4d671e43_31bf3856ad364e35_6.1.7600.20924_none_7748ffa5a3b24572.manifest

File version

Not applicable

File size

715

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_898b7a3a92bdb344e643db42a5d2ddb9_31bf3856ad364e35_6.1.7601.21683_none_c5b7a36a5c8d0462.manifest

File version

Not applicable

File size

1,070

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_8af307f6bb46168b73297c12753bde72_31bf3856ad364e35_6.1.7601.21683_none_c882c06015d3ac75.manifest

File version

Not applicable

File size

713

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_bd494b6b8a5fd76ab6f30155df27fcff_31bf3856ad364e35_6.1.7600.20924_none_e716a6e25bd4cc5f.manifest

File version

Not applicable

File size

715

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Amd64_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7600.20924_none_9407ac217b9acb19.manifest

File version

Not applicable

File size

53,972

Date (UTC)

15-Mar-2011

Time (UTC)

06:46

Platform

Not applicable

File name

Amd64_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7601.21683_none_95ac276f78f2c82d.manifest

File version

Not applicable

File size

53,972

Date (UTC)

15-Mar-2011

Time (UTC)

05:49

Platform

Not applicable

File name

Update.mum

File version

Not applicable

File size

3,633

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Wow64_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7600.20924_none_9e5c5673affb8d14.manifest

File version

Not applicable

File size

34,836

Date (UTC)

15-Mar-2011

Time (UTC)

05:36

Platform

Not applicable

File name

Wow64_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7601.21683_none_a000d1c1ad538a28.manifest

File version

Not applicable

File size

34,836

Date (UTC)

15-Mar-2011

Time (UTC)

04:36

Platform

Not applicable

File name

X86_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7600.20924_none_37e9109dc33d59e3.manifest

File version

Not applicable

File size

53,968

Date (UTC)

15-Mar-2011

Time (UTC)

05:48

Platform

Not applicable

File name

X86_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7601.21683_none_398d8bebc09556f7.manifest

File version

Not applicable

File size

53,968

Date (UTC)

15-Mar-2011

Time (UTC)

04:46

Platform

Not applicable

Additional files for all supported IA-64-based versions of Windows Server 2008 R2

File name

Ia64_2850a86fb4970b33e742c548a23a4d25_31bf3856ad364e35_6.1.7600.20924_none_febf9323e735bcda.manifest

File version

Not applicable

File size

712

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Ia64_3f571ca9a0503e7237dacb8d240385b7_31bf3856ad364e35_6.1.7601.21683_none_a2300a3c85889f4b.manifest

File version

Not applicable

File size

713

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Ia64_420e022e8157c655270eb34cf442fa04_31bf3856ad364e35_6.1.7600.20924_none_35273da04f5c24d3.manifest

File version

Not applicable

File size

713

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Ia64_8af307f6bb46168b73297c12753bde72_31bf3856ad364e35_6.1.7601.21683_none_6c65c8d25d74443b.manifest

File version

Not applicable

File size

712

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

Ia64_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7600.20924_none_37eab493c33b62df.manifest

File version

Not applicable

File size

53,970

Date (UTC)

15-Mar-2011

Time (UTC)

06:43

Platform

Not applicable

File name

Ia64_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7601.21683_none_398f2fe1c0935ff3.manifest

File version

Not applicable

File size

53,970

Date (UTC)

15-Mar-2011

Time (UTC)

05:44

Platform

Not applicable

File name

Update.mum

File version

Not applicable

File size

2,183

Date (UTC)

15-Mar-2011

Time (UTC)

14:17

Platform

Not applicable

File name

X86_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7600.20924_none_37e9109dc33d59e3.manifest

File version

Not applicable

File size

53,968

Date (UTC)

15-Mar-2011

Time (UTC)

05:48

Platform

Not applicable

File name

X86_microsoft-windows-g..ppolicy-policymaker_31bf3856ad364e35_6.1.7601.21683_none_398d8bebc09556f7.manifest

File version

Not applicable

File size

53,968

Date (UTC)

15-Mar-2011

Time (UTC)

04:46

Platform

Not applicable

Need more help?

Многие пользователи обнаружили, что параметр питания отсутствует в меню «Пуск» после Windows 10 Creators Update. Все параметры питания недоступны в Windows 10 CU. Если щелкнуть параметр питания в меню «Пуск», возможно, вы больше не увидите параметр «Режим сна / Выключение / Перезагрузка». Вместо этого вы получите сообщение «В настоящее время нет доступных вариантов питания». Единственный способ перевести компьютер в спящий режим / выключить его — выйти из системы, так как параметры питания доступны на значке интерфейса. Чтобы избавиться от небезопасных вариантов питания Windows 10 и найти эти функции обратно, ниже приведены несколько хитростей для справки.

Прочитайте больше:

Исправить меню «Пуск» не работает после обновления для создателей Windows 10

Способ 1

Запустите SFC / Scannow, чтобы исправить отсутствующие проблемы с параметрами электропитания в Windows 10 Creators Update

Ошибка питания или не работающая ошибка в Windows 10 Creators Update также может быть вызвана повреждением или отсутствием системных файлов. Чтобы исключить такую возможность, вы можете запустить команду SFC (System File Checker) для восстановления проблемных системных файлов и получения параметров питания. Ниже как:

  1. Нажмите Win + X, чтобы выбрать командную строку (Admin).

  2. Введите sfc / scannow и нажмите Enter. (Не забудьте поставить пробел между «sfc» и косой чертой.)

  3. Введите powercfg –restoredefaultschemes после завершения выполнения команды sfc / scannow и нажмите Enter.

  4. Введите DISM / Online / Cleanup-Image / RestoreHealth и нажмите Enter.

  5. Перезагрузите компьютер после завершения процесса, а затем попробуйте параметр «Спящий режим», «Выключить» или «Перезагрузить» в меню питания, чтобы проверить, доступны ли теперь параметры питания.

Способ 2

Настроить редактор групповой политики для решения проблем Windows 10. После обновления создателей параметры питания недоступны

Если при выполнении команд SFC не удается исправить бесполезные параметры питания в Windows 10, попробуйте настроить редактор групповой политики, как показано в следующих руководствах.
Перед настройкой реестра лучше сначала создать резервную копию реестра, если возникнут какие-либо проблемы с системой, такие как синий экран, черный экран с курсором, Windows Hello не работает и т.д.

  1. Перейдите в Поиск, введите gpedit.msc, чтобы открыть редактор групповой политики.

  2. Перейдите по следующему пути:

Конфигурация пользователя -> Административные шаблоны -> Пуск и панель задач

  1. Дважды щелкните «Удалить и запретить доступ к команде выключения».

  2. Выберите «Не настроено» или «Отключено» и нажмите « Применить».

  3. Закройте редактор групповой политики, а затем попробуйте меню параметров питания, чтобы увидеть, работает ли сейчас опция сна / гибернации / перезапуска.

Pro Совет :

Если вы являетесь пользователем Windows 10 Home, редактор групповой политики недоступен. Но вы можете запустить regedit, чтобы открыть редактор реестра, а затем следовать приведенному ниже пути, чтобы найти недостающие параметры питания обратно:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer,

Убедитесь, что значение с именем NoClose существует со значением 0.

Перезагрузите компьютер и проверьте, исправлена ли ошибка, связанная с отсутствием параметров электропитания.

Способ 3

Добавьте права пользователя в локальные параметры безопасности, чтобы вернуть отсутствующие параметры питания

Добавление прав пользователя в локальную политику безопасности также полезно для устранения неисправности параметров питания:

  1. Нажмите клавиши Win + R и введите: secpol.msc, а затем нажмите Enter, чтобы открыть локальную политику безопасности.

  2. Перейдите: Настройки безопасности -> Локальные политики -> Назначение прав пользователя -> Завершение работы системы.

  3. Выберите « Свойства», а затем « Добавить пользователей или группу», чтобы добавить свой идентификатор пользователя или группу.

[Силовые варианты, не доступный-Windows-10-творцы-update.jpg] [4]

  1. После добавления нового пользователя или группы нажмите кнопку ОК, чтобы сохранить изменения.

  2. Выйдите из системы и перезагрузите компьютер.

  3. Войдите в систему, и вы увидите, что доступны опции «Перезагрузка и выключение».

Способ 4

Обновление драйверов для создателей Обновление для получения параметров электропитания в меню «Пуск»

Несовместимые драйверы могут привести к таким проблемам, как не отвечающее меню параметров питания, исчезновение курсора, CHKDSK / F / R не работает, зависание мыши и т.д. После Windows 10 CU. Чтобы обновить драйверы устройств в соответствии с обновлением для создателей Windows 10 и разрешить непростые параметры питания из меню «Пуск» с помощью экономии времени и энергии, мы рекомендуем использовать профессиональную утилиту обновления и управления драйверами, например Driver Talent. Driver Talent, которым пользуются миллионы людей по всему миру, обнаруживает ваши проблемные драйверы, а затем исправляет их, загружая наиболее подходящие драйверы для компьютера Windows.

Следуйте инструкциям по обновлению драйверов и устранению неполадок, связанных с параметрами электропитания, которые больше не доступны в Windows 10 CU.

Шаг 1.
Сканирование проблемных драйверов

Нажмите «Сканировать», и Driver Talent выполнит поиск всех драйверов, установленных в Windows 10 Creators Update.

Шаг 2.

Обновите наиболее подходящие драйверы

Все проблемные драйверы покажут вам после шага 1. Нажмите «Загрузить» или «Обновить», чтобы установить соответствующие драйверы и решить проблему с перебоями параметров питания для Windows 10.

Примечания: Сделайте резервную копию драйверов заранее, если вы хотите откатить драйверы в будущем.

Шаг 3.

Перезагрузите компьютер

Перезагрузите Windows 10 Creators Update на ноутбуке или настольном ПК, чтобы обновленный драйвер вступил в силу.

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

Содержание

  1. Windows не удалось применить параметры group policy local users and groups
  2. Спрашивающий
  3. Общие обсуждения
  4. Почему не применяется групповая политика к компьютеру или OU?
  5. Область действия (scope) GPO
  6. Фильтр безопасности GPO
  7. WMI фильтры GPO
  8. Статус групповой политики
  9. Делегирование GPO
  10. Наследование групповых политик
  11. Область действия и порядок применения групповых политик (LSDOU)
  12. GPO Link Enabled
  13. Замыкание групповой политики
  14. Диагностика применения GPO на стороне клиента
  15. Методика диагностики причин долгого применения GPO в Windows
  16. Блокирование наследования групповой политик
  17. Вывод подробных сообщений на экране загрузки
  18. Отчет GPResult
  19. Анализ событий от Group Policy в системных журналах Windows
  20. Отладочный журнал службы GPSVC
  21. Отладочные журналы Group Policy Preferences
  22. Windows 7 Клиентам периодически не удается применить групповую политику при запуске
  23. Симптомы
  24. Причина
  25. Решение
  26. Дополнительная информация
  27. Windows не удалось применить параметры group policy local users and groups
  28. К чему применяется групповая политика (GPO)
  29. Алгоритм устранения проблем с GPO
  30. Проверка прав на политику
  31. Инструменты диагностики групповой политики
  32. Диагностика GPO через gpresult
  33. Результаты групповой политики

Windows не удалось применить параметры group policy local users and groups

Этот форум закрыт. Спасибо за участие!

trans

Спрашивающий

trans

Общие обсуждения

trans

trans

Добрый день, проблема с отработкой групповой политики используя GPP. Групповая политика должна изменять пароль локального администратора. После применения ее на доменном ПК возникает ошибка:

Тип события: Ошибка
Источник события: Group Policy Local Users and Groups
Категория события: (2)
Код события: 8194
Дата: 14.12.2010
Время: 10:55:35
Пользователь: NT AUTHORITYSYSTEM
Компьютер: PC

Описание:
Клиентскому расширению не удалось применить параметр политики компьютер для «Security-AdministratorSettings-GPP <628d9ada-c5b0-4644-ab39-50971af1d61c>» по причине ошибки с кодом «0x80070002 Не удается найти указанный файл.» Дополнительные сведения находятся в файле трассировки..

В политике указано:

Имя пользователя Администратор (встроенная учетная запись)

Запретить смену пароля пользователем Ложь

Срок действия пароля не ограничен Истина

Учетная запись отключена Ложь

Срок действия учетной записи Никогда

Остановить обработку элементов на этом расширении, если на этом элементе возникает ошибка Нет

Удалить этот элемент, если он больше не применяется Нет

Применить один раз и не применять повторно Нет

Источник

Почему не применяется групповая политика к компьютеру или OU?

В этой обзорной статье я постараюсь разобрать типовые причины, из-за которых та или иная групповая политика может не применяться к подразделению (OU) или конкретному компьютеру / пользователю. Я думаю эта статья будет полезна как новичкам, так и профессионалам групповых политик AD для понимания принципов работы и архитектуры GPO. В первую очередь в статье я расскажу о возможных проблемах применения GPO, связанные с настройками самих политик на уровне домена, а не о траблшутинге применения GPO на клиентах. Практически все настройки, описанные в статье, выполняются в консоли редактора доменных групповых политик — Group Policy Management Console (GPMC.msc).

Область действия (scope) GPO

Если некой параметр политики не применятся на клиенте, проверьте область действия (scope) групповой политики. Если вы настраиваете параметр в секции Конфигурация компьютера (Computer Configuration), значит ваша групповая политика должна быть привязана к OU с компьютерами. Соответственно, если настраиваемый параметр относится к Конфигурация пользователя (User configuration).

oblast dejstviya scope gpo

Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.

opredelit ou obuekta v ad

Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).

Фильтр безопасности GPO

Проверьте значение фильтра безопасности политики (Security Filtering). По-умолчанию на всех новых объектах GPO в домене присутствуют разрешения для группы «Authenticated Users«. Эта группа включает в себя всех пользователей и компьютеры домена. Это означает, что данная политика будет применяться на всех пользователях и ПК, которые попадают в область ее действия.

gpo security filtering authenticated users

prava na primenenie gpo

Если вы используете нестандартные фильтры безопасности политик, проверьте, что для целевых групп нет явного запрета на применение GPO (Deny).

WMI фильтры GPO

В групповых политиках можно использовать специальные WMI фильтры. Это позволяет применить политику к компьютерам на основании некоторого WMI запроса. Например, мы можете создать WMI фильтр GPO для применения политики только к компьютерам с определенной версией Windows, к ПК в определенной IP подсети, только к ноутбукам и т.д.

wmi filtry gpo

При использовании WMI фильтров групповых политик вам нужно проверить корректность WMI запроса, который выбирает только те системы, которые вам нужны и не исключаются ваши целевые компьютеры. Вы можете протестировать WMI фильтр на компьютерах через PowerShell

Если запрос возвращает любые данные, значит WMI фильтр применится к этому компьютеру.

gwmi testirovanie wmi filtra na kompyutere

Статус групповой политики

Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.

gpo status enabled

Как вы видите, доступно 4 варианта:

Делегирование GPO

На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL

delegation gpo prava na politiki

Наследование групповых политик

Наследование это одна из основных концепции групповых политик. Политики верхнего уровня по-умолчанию применяются ко всем вложенным объектам в иерархии домена. Однако, администратор может заблокировать применение всех наследованных политик на определенный OU. Для этого в консоли GPMC нужно щелкнуть ПКМ по OU и выбрать пункт меню Block inheritance.

gruppovye politiki zablokirovat nasledovanie bl

Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.

otklyucheno nasledovanie gpo na ou

Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.

Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).

gpo enforced

Область действия и порядок применения групповых политик (LSDOU)

Чтобы запомнить особенности порядка применения групповых политик в домене, нужно запомнить аббревиатуру LSDOU. Это аббревиатура позволяет запомнить порядок применения GPO:

Последние политики имеют наивысший приоритет. Т.е. если вы включили некий параметр Windows на уровне политики домена, но на целевом OU данный параметр отключается другой политикой – это означает, что нужный параметр в результате будет отключен на клиенте (выиграет ближайшая политика к объекту в иерархии AD).

При использовании параметра Forced у GPO выигрывает та, политика находится выше в иерархии домена (например, при включении Forced у политики Default Domain Policy, она выигрывает у всех других GPO).

Кроме того, администратор может изменить порядок обработки политик (Link Order) в консоли GPMC. Для этого нужно выбрать OU и перейти на вкладку Linked Group Policy Objects. В списке содержаться список GPO, которые применяются к данной OU с указанием приоритета. Политики обрабатываются в обратном порядке (снизу-вверх). Это означает что политика с Link Order 1 выполнится последней. Вы можете изменить приоритет GPO с помощью стрелок в левом столбце, передвинув ее выше или ниже в списке.

poryadok primeneniya gruppovyh politik link order

GPO Link Enabled

У каждого объекта GPO, который привязан к организационному контейнеру AD вы можете включить или отключить связь (применение политики). Для этого нужно включить или отключить опцию Связь включена (Link Enabled) в меню политики. Если связь для политики отключена, ее иконка становится бледной. При отключении связи политика перестает применяться к клиентам, но ссылка на объект GPO не удаляется из иерархии. Вы можете активировать данную связь в любой момент.

vklyuchit svyaz gpo

Замыкание групповой политики

У этой политики есть два возможных значение:

configure user group policy loopback processing mo

Диагностика применения GPO на стороне клиента

filtr zhurnala sobytij microsoft windows grouppoli

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

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

Источник

Методика диагностики причин долгого применения GPO в Windows

Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе «Применение параметров компьютера / пользователя». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения GPO на компьютерах домена.

На самом деле причин, из-за которых на компьютере долго применяются групповые политики может быть множество: это и проблемы с DNS, доступностью и скоростью подключения к DC, неправильной настройкой сайтов AD или проблемы с репликацией, неверно настроенные групповых политики и кривые скрипты и т.п. Проблематично описать универсальный алгоритм по диагностике всех этих проблем. При решении таких проблем, как правило, большую роль имеет опыт и навыки специалиста, производящего диагностику. В этой статье мы остановимся только на диагностики проблем, связанных с самими механизмами работы GPO и клиента GPClient.

Блокирование наследования групповой политик

gpo Block InheritanceПерезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).

Вывод подробных сообщений на экране загрузки

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

Display highly detailed status messages

Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINESOFTWARE Microsoft Windows CurrentVersion PoliciesSystem параметр типа DWORD с именем verbosestatus и значением 1.

В результате на экране в процессе загрузки будут отображаться такие сообщения:

win7 verbose status messages

Отчет GPResult

Результирующую политику, которая была применена к компьютеру, стоит проанализировать с помощью HTML отчета gpresult, создать который можно такой командой, запущенной с правами администратора:

gpresult /h c:psgpreport.html

Этот отчет достаточно удобен для анализа и может содержать ссылки на различные ошибки при применении GPO.

Group Policy Files (N/A) 453 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Folders (N/A) 188 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Local Users and Groups (N/A) 328 Millisecond(s) 18.01.2017 14:10:00 View Log
Group Policy Registry (N/A) 171 Millisecond(s) 18.01.2017 14:10:01 View Log
Group Policy Scheduled Tasks (N/A) 343 Millisecond(s) 18.01.2017 14:10:01 View Log
Scripts (N/A) 156 Millisecond(s) 18.01.2017 14:09:04 View Log
Security (N/A) 3 Second(s) 495 Millisecond(s) 18.01.2017 14:09:08 View Log
Реестр (N/A) 18 Second(s) 814 Millisecond(s) 18.01.2017 14:10:00 View Log

html gpreport

Анализ событий от Group Policy в системных журналах Windows

В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:

Судя по данному событию, пользователю пришлось ждать применения групповых политик при загрузке компьютера в течении почти часа…

Для анализа времени применения политик будут полезны следующие EventID:

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

Отладочный журнал службы GPSVC

В некоторых ситуациях бывает полезным включить ведение отладочного журнала обработки GPO — gpsvc.log. С помощью временных меток в файле gpsvc.log можно найти компоненты GPO, которые долго отрабатывали.

Отладочные журналы Group Policy Preferences

GroupPolicy Logging and tracingКак вы видите, доступные индивидуальные настройки для каждого CSE. В настройках политики можно указать тип событий, записываемых в журнал (Informational, Errors, Warnings или все), максимальный размер журнала и местоположение лога:

configure gp preferences tracing

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

gpp trace logИтак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.

Источник

Windows 7 Клиентам периодически не удается применить групповую политику при запуске

В этой статье данная статья позволяет решить проблему, из-за которой Windows 7 Клиенты периодически не применяют групповой политики при запуске.

Применяется к: Windows 7 Пакет обновления 1
Исходный номер КБ: 2421599

Симптомы

Windows 7 клиентов периодически не удается обработка групповой политики при запуске или перезагрузке. В журнале событий System регистрируются следующие события:

Ошибка 9/9/2010 2:43:29 PM NETLOGON 5719 Ошибка 9/9/2010 2:43:31 PM GroupPolicy 1055

Причина

Это поведение вызвано состоянием рас между инициализацией сети, поиском контроллера домена и групповой политикой обработки. Если сеть недоступна, контроллер домена не будет расположен, а обработка групповой политики будет неудачной. После загрузки операционной системы и согласований и установленной сетевой связи обновление фонового фона групповой политики будет успешным.

Следующая последовательность событий отражает условие:

Information EventLog 6006 указывает на отключение системы
Информация e1kexpress 33 указывает на то, что установлена связь сетевого подключения с
Information EventLog 6005 указывает, что служба журнала событий запущена
Информация Dhcp-Client 50036 указывает на начало клиентской службы dhcp
Ошибка NETLOGON 5719 указывает, что netlogon не может достичь ни одного из контроллеров домена
Ошибка GroupPolicy 1055 указывает на сбой обработки групповой политики
Information GroupPolicy 1503 указывает на успешность обработки групповой политики

Это также можно подтвердить с помощью netlogon журналов:

Решение

Чтобы решить проблему, можно установить значение реестра, чтобы отложить применение групповой политики:

Откройте редактор реестра.

Расширь следующую подкайку: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Чтобы назвать новую запись, введите GpNetworkStartTimeoutPolicyValue и нажмите кнопку ENTER.

Щелкните правой GpNetworkStartTimeoutPolicyValue кнопкой мыши, а затем выберите Изменение.

В базовой статье выберите десятичной знак.

В поле Данных Значения введите 60 и выберите ОК.

Выйти из редактора реестра и перезапустить компьютер.

Если сценарий запуска групповой политики не работает, увеличите значение GpNetworkStartTimeoutPolicyValue записи реестра.

Дополнительная информация

Указанное значение должно быть достаточно длинным, чтобы обеспечить подключение. В течение периода ожидания Windows каждые две секунды проверяет состояние подключения и будет продолжать работу с запуском системы, как только подключение будет подтверждено. Поэтому рекомендуется перебиваясь на высокой стороне. Если система отключена законно (например, отключенный сетевой кабель, off-line server и так далее), Windows будет приостановлено на весь период ожидания.

Она также может быть определена с помощью групповой политики:

Расположение политики: > политики > шаблоны администратора > System > Group Policy Setting Name: Клавиша времени ожидания ожидания обработки политики запуска: HKLMSoftwarePoliciesMicrosoftWindowsSystem!GpNetworkStartTimeoutPolicyValue

Если вы определите параметр групповой политики, он переопределит параметр вручную. Если параметр ручной и групповой политики не определен, значение выбирается из следующего расположения реестра:

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

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

Источник

Windows не удалось применить параметры group policy local users and groups

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз я вам показал, как я делал досрочное погашение ипотеки Сбербанка, поделился свои жизненным опытом. Сегодня я хочу вас научить, как находить и диагностировать причины, по которым у вас может не применяться назначенная вами групповая политика к компьютеру или пользователю или целому организационному подразделению. Мы рассмотрим все этапы, через которые проходит происходит взаимодействие с GPO. Разберем утилиты, которыми должен владеть системный администратор в задачи которого входит создание и назначение политик. Уверен, что данный пост будет вам полезен и интересен.

За, что Active Directory от Microsoft получила такую популярность? Одним из ответов на данный вопрос, будет функционал групповой политики. Все администраторы, как и большинство современных людей, существа очень ленивые и любят, когда все централизованно управляется и по возможности автоматизированно. Именно объекты GPO, позволяют производить настройки десятков, сотен и тысяч компьютеров, из одного места и практически по всем направлениям, например добавление принтеров, скриптов входа, профилей WiFi и многое другое.

Очень частые ситуации, что системный администратор создал новую групповую политику, применил ее на нужный ему объект, но эффекта это не дало и нужно понять почему она не применилась и вот тут начинающие системные администраторы попадают в просак, не понимая, где и что нужно искать. Ниже мы с вами разберем алгоритм действий, который поможет вам найти причину и восстановить работу применения групповой политики на нужный объект.

К чему применяется групповая политика (GPO)

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

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

Otlichie kontejnera ot OU

Алгоритм устранения проблем с GPO

Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers«. Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.

Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.

Oblast primeneniya obekta GPO

Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта«, по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.

Poisk obekta Active Directory

Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка «Связь включена«, ее так же можно проверить на вкладке «Область» в столбце «Связь задействована», должно стоять значение «да».

Ne primenyaetsya GPO 01

Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено«, означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:

Ne primenyaetsya GPO 02
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».

Ne primenyaetsya GPO 10

Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.

Ne primenyaetsya GPO 11

Проверка прав на политику

Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе «Управление групповой политикой» выберите ваш GPO. На вкладке «Область» найдите раздел «Фильтры безопасности«, он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:

Ne primenyaetsya GPO 03

Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу «Прошедшие проверку» из фильтра безопасности, она удаляется и из вкладки делегирование.

Ne primenyaetsya GPO 04

Поэтому перейдите на вкладку «Делегирование» и проверьте наличие любой из групп «Прошедшие проверку» или «Компьютеры домена» и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку «Дополнительно», далее добавить и выберите «Прошедшие проверку».

Ne primenyaetsya GPO 05

Удостоверьтесь, что выставлена галка «Чтение».

Ne primenyaetsya GPO 06

Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.

Ne primenyaetsya GPO 07

Обратите внимание на группу «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)» данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.

Ne primenyaetsya GPO 08

Еще одним механизмом фильтрации групповой политики, может выступать WMI фильтры. Если они есть и ваш объект не соответствует его требованиям, то вы не сможете применить политику. Посмотреть, это можно в соответствующем разделе. В моем примере есть WMI фильтр для ноутбуков, который не даст применения политики на стационарные компьютеры. Подробнее, о создании WMI фильтров и механизме проверки WMI фильтров, читайте по ссылкам. Ниже я покажу, как на конечном компьютере увидеть, что он не подошел из-за фильтрации GPO по WMI.

Ne primenyaetsya GPO 09

Инструменты диагностики групповой политики

Выше мы разобрали возможные места, где могла быть проблема, но по мимо них еще есть несколько инструментов, которые могут дать системному администратору информацию, о причинах, которые мешают применению GPO к нужному объекту.

Существуют три инструмента, которые вам покажут информацию, о применяемых политиках на объекты:

Диагностика GPO через gpresult

Gpresult первое средство, которое позволит системному администратору определить на каком этапе есть проблемы с выполнением GPO. Откройте на клиентском компьютере или ноутбуке командную строку от имени администратора и введите команду:

В моем примере у меня есть политика для компьютера «Управление UIPI», поэтому я воспользуюсь gpresult для компьютера. Выполнив gpresult /r /scope:computer я вижу, что моя политика не применилась и числится в списке «Следующие политики GPO не были применены, так как они отфильтрованы». Фильтрация отказано в доступе (Безопасность). Из этого видно, что у компьютера просто нет прав на чтение политики.

Ne primenyaetsya GPO 12

Так же в логах Windows вы можете обнаружить событие с кодом ID 5313:

Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (безопасность)

Ne primenyaetsya GPO 14

А вот пример 5313, но с уже WMI фильтром:

Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (фильтр WMI)

Ne primenyaetsya GPO 15

Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.

Ne primenyaetsya GPO 13

Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.

Ne primenyaetsya GPO 16

Начнется сбор применяемых политик.

Ne primenyaetsya GPO 17

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

Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:

Ne primenyaetsya GPO 18

Результаты групповой политики

В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется «Результат моделирования групповой политики». Щелкаем по нему правым кликом и открываем мастер.

Rezultat modelirovaniya gruppovoj politiki 1

Выбираем нужный компьютер, к которому мы хотим проверить применение политики.

Vybor kompyutera v rezultatah modelirovaniya gruppovoj politiki

Если в момент добавления компьютера у вас выскочит ошибка «Сервер RPC-недоступен», то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.

Ne zapushhena sluzhba WMI

Так как я проверяю GPO для компьютера, то мне нет смысла отображать политику для пользователей.

ne otobrazhat politiku polzovatelya

Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке «Сведения» вы увидите, какие политики применены, а какие нет.

Otchet rezultatov gruppovoj politiki

Раскрыв подробнее политику, которая не смогла примениться, я вижу, что причиной всему был WMI фильтр.

Iz za chego ne otrabotala GPO

Последним удобным инструментом диагностики и моделирования групповой политики, выступает функционал GPMC, под названием «Моделирование групповой политики«. В задачи которого входит проверка применения политики в существующей ситуации, так и просто тест без реальной прилинковки к OU, указав нужный объект. В оснастке GPMC выберите пункт «Моделирование групповой политикой» и щелкните по нему правым кликом, выбрав «Мастер моделирования групповой политики».

Ne primenyaetsya GPO 19

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

Modelirovanie gruppovoj politiki

Далее вам будет предложен выбор, дабы указать нужный контроллер домена.

Vybor kontrollera domena v rsop

Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку «Обзор». Я выбрал «Client Computers»

Vybor kontejnera v RSOP

Modelirovanie gruppovoj politiki v gpmc

На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:

Vybor sajta v RSOP

Указываем в какой группе находится наш объект, к которому будет применяться политика.

Vybor gruppy bezopasnosti v rsop

далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.

Vybor filtrov WMI v rsop

Pochemu ne rabotaet gruppovaya politika

В итоге мы получаем результат моделирования групповой политики, тут можно посмотреть, что применилось, что нет.

Источник

В этом руководстве я постараюсь рассказать вам о типичных причинах, по которым объект групповой политики (GPO) не может быть применён к организационном подразделении (OU), конкретному компьютеру или пользователю домена. Думаю, эта статья будет полезна как новичкам, так и IT-специалистам для понимания работы и архитектуры GPO. Прежде всего, я расскажу о возможных проблемах применения GPO, связанных с настройками политики на уровне домена, вместо устранения проблем с GPO на клиентах. Практически все параметры, описанные в статье, настраиваются с помощью Консоли управления групповыми политиками (GPMC.msc).

Управление областью действия GPO

Если параметр политики не применяется к клиенту, проверьте область действия GPO. Если вы настраиваете параметр в разделе Computer Configuration («Конфигурация компьютера»), ваша групповая политика должна быть сопряжена с организационным подразделением (OU) объектов компьютеров. То же самое верно, если вы установите свои параметры в разделе User configuration («Конфигурации пользователя»).

Также убедитесь, что объект, к которому вы пытаетесь применить свой GPO, находится в правильном контейнере AD (OU) компьютеров или пользователей. Если у вас много объектов и вы не можете вспомнить, в каком организационном подразделении находится нужный вам пользователь или компьютер, то вы можете выполнить поиск по объектам в своём домене. После выполнения поиска, чтобы узнать, в какое организационное подразделение (OU) помещён найденный объект, дважды кликните на него, перейдите на вкладку Object («Объект»), где в поле «Каноническое имя объекта» вы увидите полный путь, включающий имя организационного подразделения.

Связанная статья: Поиск по Active Director групп и пользователей с использованием подстановочных знаков

Это означает, что целевой объект должен находиться в подразделении, с которым связана политика (или во вложенном контейнере AD).

Фильтрация безопасности в GPO

Проверьте настройки Security Filtering («фильтрации безопасности») в своей политике. По умолчанию для всех новых объектов GPO в домене включены разрешения для группы Authenticated Users («Прошедшие проверку»). В эту группу входят все пользователи и компьютеры в домене. Это означает, что политика будет применяться ко всем пользователям и компьютерам в пределах её области действия.

Если вы хотите изменить фильтрацию безопасности, чтобы применить политику только к членам определённой группы безопасности (или определенным пользователям/компьютерам), удалите «Authenticated Users» из списка фильтрации безопасности и убедитесь, что целевой объект (пользователь или компьютер) добавлен в нужную вам группу AD. Также убедитесь, что группа, которую вы добавили в фильтр безопасности, имеет разрешения Read и Apply group policy с установленным флажком Allow («Разрешить») в GPO → Delegation → кнопка Advanced (GPO → Делегирование → кнопка «Дополнительно»).

Если вы используете нестандартные фильтры безопасности GPO, убедитесь, что нет явного запрета на использование GPO для целевых групп (Deny).

Фильтрация GPO WMI

В объекте групповой политики можно использовать специальные фильтры WMI. Таким образом, вы можете применить политику к своим компьютерам на основе некоторого запроса WMI. Например, вы можете создать фильтр WMI GPO для применения политики только к компьютерам с определённой версией Windows, к компьютерам в определённой IP-подсети, только к ноутбукам и так далее.

При использовании фильтрации WMI групповой политики убедитесь, что ваш запрос WMI верен. Он должен выбирать только те системы, которые вам нужны, и ни один целевой компьютер не исключается. Вы можете протестировать свой WMI-фильтр на компьютерах с помощью PowerShell:

gwmi -Query 'select * from Win32_OperatingSystem where Version like "10.%" and ProductType="1"'

Если запрос возвращает какие-либо данные, то к этому компьютеру будет применён фильтр WMI.

Статус GPO

Проверьте статус GPO на вкладке Details свойств политики в GPMC.msc. Обратите внимание на значение в раскрывающемся списке GPO Status («Состояние объекта групповой политики»).

Как видите, доступно 4 варианта:

  1. All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
  2. Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
  3. User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
  4. Enabled (Включено) — все настройки GPO применяются к целевым объектам AD (значение по умолчанию).

Делегирование групповой политики

Разрешения, настроенные для политики, отображаются на вкладке «Делегирование» объекта групповой политики. Здесь вы можете увидеть, какие члены группы могут изменять параметры этого объекта групповой политики и применяется ли к ним политика. Вы можете предоставить права на управление GPO с этой консоли или с помощью мастера делегирования Active Directory в ADUC. Если есть разрешение на доступ Enterprise Domain Controllers («Контроллеры домена предприятия»), эта политика может быть реплицирована между контроллерами домена Active Directory (обратите внимание на это, если у вас есть какие-либо проблемы репликации политики между контроллерами домена). Обратите внимание, что разрешения на вкладке «Делегирование» соответствуют разрешениям NTFS, назначенным каталогу политики в папке SYSVOL.

Блокирование наследования и принудительное применение в ссылке групповой политики

Наследование — одна из основных концепций GPO. По умолчанию политики высокого уровня применяются ко всем вложенным объектам в иерархии домена. Однако администратор может заблокировать применение всех унаследованных политик к определённому подразделению. Для этого щёлкните правой кнопкой мыши подразделение в консоли управления групповыми политиками и выберите Block inheritance («Заблокировать наследование»).

Подразделения с включённой опцией заблокированного наследования отмечены синим восклицательным знаком в консоли.

Если политика не применяется к клиенту, проверьте, не принадлежит ли он подразделению с заблокированной опцией наследования.

Обратите внимание, что политики домена с включённым свойством Enformed применяются даже к подразделениям с заблокированным параметром наследования (вы можете увидеть унаследованные политики, применённые к контейнеру, на вкладке Group Policy Inheritance).

Область действия GPO и порядок приоритетной обработки (LSDOU)

Чтобы запомнить порядок, в котором групповые политики применяются в домене, запомните аббревиатуру LSDOU. GPO применяются к клиентам в следующем порядке:

  1. Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
  2. GPO уровня сайта (Site);
  3. GPO уровня домена (Domain).
  4. Объекты групповой политики с уровня организационного подразделения (Organizational Unit).

Последние политики имеют наивысший приоритет. Это означает, что если вы включите какой-либо параметр Windows на уровне домена, он может быть отключён другой политикой на уровне организационного подразделения (если представить иерархию AD, то чем ближе в этой иерархии групповая политика к объекту, тем выше у неё приоритет).

При использовании опции Forced («Принудительно») приоритет будет отдаваться политике, стоящей выше в иерархии домена (например, если для политики домена по умолчанию включён параметр Forced («Принудительно»), она будет иметь более высокий приоритет, чем любой другой объект групповой политики).

Администратор также может изменить порядок обработки политики с помощью консоли GPMC (Управление групповой политикой). Для этого выберите подразделение и перейдите на вкладку Linked Group Policy Objects («Связанные объекты групповой политики»). Там вы увидите список GPO, применённых к этому OU с указанным приоритетом. Политики обрабатываются в обратном порядке (снизу вверх). Это означает, что в последнюю очередь будет применяться политика с Link Order 1 (Порядком ссылки 1). Вы можете изменить приоритет GPO, используя стрелки в левом столбце, и переместить политику вверх или вниз в списке.

Link Enabled Setting («Связь включена») для GPO

Для любого объекта GPO, связанного с организационным подразделением AD, может быть включена или отключена опция Link Enabled («Связь включена»). Если связь отключена, её значок становится серым. Когда связь отключена, политика не применяется к клиентам, но ссылка на объект GPO не удаляется из иерархии домена. Вы можете включить связь в любое время.

Как включить GPO Loopback Processing Mode (режим обработки замыкания GPO)

Если вы включили Loopback Processing mode («Режим обработки замыкания»), вы можете применить настройки из раздела «Конфигурация пользователя» к объекту компьютера. Вы можете включить режим кольцевой обработки в следующем разделе редактора GPO: Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy Loopback Processing mode (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.

Этот режим обработки замыкания политики имеет два возможных значения:

  1. Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером. В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
    В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему.
  2. Replace («Замена») – к пользователю будут применяться только политики, назначенные подразделению, содержащему компьютер, на котором пользователь вошёл в систему.

Устранение неполадок GPO на стороне клиента

Вы можете диагностировать применение GPO на стороне клиента с помощью gpresult, rsop.msc или Просмотра событий Windows (eventvwr.msc).

Смотрите также: Использование инструмента GPResult для проверки того, какие объекты групповой политики применяются

Чтобы увидеть журнал событий применения групповых политик, откройте Event Viewer («Просмотр событий»), это можно сделать с помощью команды:

eventvwr.msc

В средстве просмотра событий вы можете фильтровать события по источнику для этого нажмите «Создать настраиваемое представление» и в качестве источника выберите GroupPolicy (Microsoft-Windows-GroupPolicy).

Вы увидите журнал событий, связанных с применением групповых политик:

Такого же результата вы можете достичь если в окне Event Viewer («Просмотр событий») перейдёте по пути Applications and Services Logs → Microsoft → Windows → Applications and Services Logs → Group Policy → Operational (в русскоязычной версии это Журналы приложений и служб → Microsoft → Windows → Group Policy → Operational.

Вы также можете прочитать статью «Устранение неполадок, связанных с медленной обработкой GPO и снижением скорости входа в систему», в которой описаны некоторые дополнительные принципы диагностики объектов групповой политики.

Подводя итог, я рекомендую сделать структуру GPO как можно более простой и не создавать ненужных политик. Используйте прозрачную схему именования политик: имя должно чётко указывать, для чего предназначен объект групповой политики.

Связанные статьи:

  • Использование инструмента GPResult для проверки того, какие объекты групповой политики применяются (100%)
  • Устранение неполадок, связанных с медленной обработкой GPO и снижением скорости входа в систему (100%)
  • Актуализация настроек групповой политики на компьютерах домена Windows (90.3%)
  • Настройка политики паролей домена в Active Directory (66.2%)
  • Fine-Grained Password Policy: Как создать детальную политику паролей в Active Directory (66.2%)
  • Get-ADUser: поиск сведений о пользователях и фильтр пользователей по их свойствам в Active Directory (RANDOM — 50%)

Обновлено 30.07.2021

gpo ad logoДобрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз я вам показал, как я делал досрочное погашение ипотеки Сбербанка, поделился свои жизненным опытом. Сегодня я хочу вас научить, как находить и диагностировать причины, по которым у вас может не применяться назначенная вами групповая политика к компьютеру или пользователю или целому организационному подразделению. Мы рассмотрим все этапы, через которые проходит происходит взаимодействие с GPO. Разберем утилиты, которыми должен владеть системный администратор в задачи которого входит создание и назначение политик. Уверен, что данный пост будет вам полезен и интересен.

За, что Active Directory от Microsoft получила такую популярность? Одним из ответов на данный вопрос, будет функционал групповой политики. Все администраторы, как и большинство современных людей, существа очень ленивые и любят, когда все централизованно управляется и по возможности автоматизированно. Именно объекты GPO, позволяют производить настройки десятков, сотен и тысяч компьютеров, из одного места и практически по всем направлениям, например добавление принтеров, скриптов входа, профилей WiFi и многое другое.

Очень частые ситуации, что системный администратор создал новую групповую политику, применил ее на нужный ему объект, но эффекта это не дало и нужно понять почему она не применилась и вот тут начинающие системные администраторы попадают в просак, не понимая, где и что нужно искать. Ниже мы с вами разберем алгоритм действий, который поможет вам найти причину и восстановить работу применения групповой политики на нужный объект.

К чему применяется групповая политика (GPO)

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

  • что реестр есть как для объекта компьютер
  • и реестр есть для объекта пользователь

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

  1. Это контейнер — по сути простая папка, важно, что к ней нельзя применять объекты групповой политики.
  2. Второй тип, это организационные подразделения (OU) — это специальные папки для объединения объектов AD по принципам. Именно с OU связываются объекты групповой политики, для применения их к компьютерам и пользователям. Внешне контейнер отличается от организационной утилитой, тем что у OU, есть дополнительная лычка на значке, это показано на скриншоте.

Отличие контейнера от OU

Алгоритм устранения проблем с GPO

Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers«. Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.

Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.

Область применения объекта GPO

Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта«, по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.

Поиск объекта Active Directory

Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка «Связь включена«, ее так же можно проверить на вкладке «Область» в столбце «Связь задействована», должно стоять значение «да».

проверка включения связи у GPO

Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено«, означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:

  • Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
  • Параметры конфигурации пользователя отключены (User configuration settings disabled)
  • Все параметры отключены (All setting disabled) — запретит применение политики для любого объекта

Сделано, это для ускорения применения политики к объекты. Согласитесь, что если у вас в GPO настроены изменения только для пользователя, то нет смысла проверять политику для компьютера. Поэтому системные администраторы могут отключать это, но могут и ошибиться, выключив не тот объект

вкладка ведения в gpmc
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».

Блокировать наследование

Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.

пример блокировки наследования GPO

Проверка прав на политику

Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе «Управление групповой политикой» выберите ваш GPO. На вкладке «Область» найдите раздел «Фильтры безопасности«, он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:

  • Пользователь
  • Компьютер
  • Группа безопасности

По умолчанию тут прописана группа безопасности «Прошедшие проверку (Authenticated Users)». По умолчанию в данную группу входят все доменные пользователи и доменные компьютеры

Фильтры безопасности в GPO

Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу «Прошедшие проверку» из фильтра безопасности, она удаляется и из вкладки делегирование.

Чтобы параметры групповой политики для пользователя успешно применялись, она требует наличия у каждой учетной записи компьютера разрешения на считывание данных GPO из контроллера домена. Удаление группы «Прошедшие проверку» может предотвратить обработку групповых политик для пользователя. добавьте группу безопасности «Пользователи, прошедшие проверку подлинности» или «Компьютеры домена», у которой есть по крайней мере разрешение только для чтения (https://support.microsoft.com/en-us/kb/316622)

Не применяется GPO-04

Поэтому перейдите на вкладку «Делегирование» и проверьте наличие любой из групп «Прошедшие проверку» или «Компьютеры домена» и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку «Дополнительно», далее добавить и выберите «Прошедшие проверку».

Добавление Прошедшие проверку в GPO ACL

Удостоверьтесь, что выставлена галка «Чтение».

Выставление прав на чтение GPO

Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.

Запрет применения GPO

Обратите внимание на группу «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)» данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.

КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ

Еще одним механизмом фильтрации групповой политики, может выступать WMI фильтры. Если они есть и ваш объект не соответствует его требованиям, то вы не сможете применить политику. Посмотреть, это можно в соответствующем разделе. В моем примере есть WMI фильтр для ноутбуков, который не даст применения политики на стационарные компьютеры. Подробнее, о создании WMI фильтров и механизме проверки WMI фильтров, читайте по ссылкам. Ниже я покажу, как на конечном компьютере увидеть, что он не подошел из-за фильтрации GPO по WMI.

Фильтр WMI

Инструменты диагностики групповой политики

Выше мы разобрали возможные места, где могла быть проблема, но по мимо них еще есть несколько инструментов, которые могут дать системному администратору информацию, о причинах, которые мешают применению GPO к нужному объекту.

Существуют три инструмента, которые вам покажут информацию, о применяемых политиках на объекты:

  • Утилита командной строки gpresult
  • Утилита rsop
  • Моделирование групповой политики в оснастке gpmc.msc
  • Результаты групповой политики

Диагностика GPO через gpresult

Gpresult первое средство, которое позволит системному администратору определить на каком этапе есть проблемы с выполнением GPO. Откройте на клиентском компьютере или ноутбуке командную строку от имени администратора и введите команду:

gpresult /r /scope:user (Для пользователя)
gpresult /r /scope:computer (Для компьютера)
Gpresult /r /z (Полный отчет)
Gpresult /r /z > c:gpresult.txt (Экспорт в файл)

В моем примере у меня есть политика для компьютера «Управление UIPI», поэтому я воспользуюсь gpresult для компьютера. Выполнив gpresult /r /scope:computer я вижу, что моя политика не применилась и числится в списке «Следующие политики GPO не были применены, так как они отфильтрованы». Фильтрация отказано в доступе (Безопасность). Из этого видно, что у компьютера просто нет прав на чтение политики.

Фильтрация отказано в доступе (Безопасность)

Так же в логах Windows вы можете обнаружить событие с кодом ID 5313:

Код 5313: Следующие объекты групповой политики не были применены, так как они были отфильтрованы:

Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (безопасность)

Код 5313

А вот пример 5313, но с уже WMI фильтром:

Следующие объекты групповой политики не были применены, так как они были отфильтрованы:

Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (фильтр WMI)

Код 5313

Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.

политика не применилась из-за WMI фильтра

Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.

rsop.msc

Начнется сбор применяемых политик.

Сбор rsop

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

Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:

GPResult /h c:report.html /f

На выходе вы получите удобный html отчет, о всех примененных или отфильтрованных политиках. Открыв отчет, вы легко поймете ,какие политики были применены, а какие нет и можете сразу посмотреть значения настроек.

Отклоненные объекты групповой политики

Результаты групповой политики

В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется «Результат моделирования групповой политики». Щелкаем по нему правым кликом и открываем мастер.

Результат моделирования групповой политики

Выбираем нужный компьютер, к которому мы хотим проверить применение политики.

Выбор компьютера в результатах моделирования групповой политики

Если в момент добавления компьютера у вас выскочит ошибка «Сервер RPC-недоступен», то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.

Не запущена служба WMI

Так как я проверяю GPO для компьютера, то мне нет смысла отображать политику для пользователей.

не отображать политику пользователя

Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке «Сведения» вы увидите, какие политики применены, а какие нет.

Отчет результатов групповой политики

Раскрыв подробнее политику, которая не смогла примениться, я вижу, что причиной всему был WMI фильтр.

Из-за чего не отработала GPO

Последним удобным инструментом диагностики и моделирования групповой политики, выступает функционал GPMC, под названием «Моделирование групповой политики«. В задачи которого входит проверка применения политики в существующей ситуации, так и просто тест без реальной прилинковки к OU, указав нужный объект. В оснастке GPMC выберите пункт «Моделирование групповой политикой» и щелкните по нему правым кликом, выбрав «Мастер моделирования групповой политики».

Моделирование групповой политики

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

Моделирование групповой политики

Далее вам будет предложен выбор, дабы указать нужный контроллер домена.

Выбор контроллера домена в rsop

Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку «Обзор». Я выбрал «Client Computers»

Выбор контейнера в RSOP

Нажимаем далее.

Моделирование групповой политики в gpmc

На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:

  • Медленное сетевое подключение, меньше 500 кб/с
  • Обработка петлевого адреса (Замыкание групповой политики — loopbacl policy) — это опция когда вы применяете для OU в которой находятся компьютеры, например терминальные сервера, политики для пользователя. Делается это для того, чтобы политики применяемые к пользователю на его рабочей станции или другом сервере от тех, что в данной OU. Можете подробно почитать, что такое замыкание групповой политики.
  • Выбор сайта.

Выбор сайта в RSOP

Указываем в какой группе находится наш объект, к которому будет применяться политика.

Выбор группы безопасности в rsop

далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.

Выбор фильтров WMI в rsop

Нажимаем далее.

Почему не работает групповая политика

В итоге мы получаем результат моделирования групповой политики, тут можно посмотреть, что применилось, что нет.

Результат моделирования групповой политики

На этом у меня все. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org. Надеюсь, что статья оказалась полезной.

  • Remove From My Forums
  • Question

  • I am having a problem getting Windows Group Policy Peferences to apply to machines immediately after they are imaged.  We are using Group Policy Preferences to, among other things, set a customized power plan as the default plan.  Upon logging
    into a machine after it has been imaged, I can see our customized power plan, but it is not selected as the default plan.  RSOP shows that the policy that contains the preferences is being applied.  Group Policy settings that reside in the same
    GPO as the Preferences have also been applied correctly.  Only the Prefences are not applying.

    We are using an image task sequence in SCCM to deploy the image.  The image is of Win 7 SP1 64bit.  We ran into the same problem with Win 7 64bit (not SP1) that was resolved by appling
    hotfix 2284538. We now seeing the same problem occur when imaging with Win 7 SP1, although SP1 contains this hotfix.

    If I log into the into the machine after it is imaged and delete GUID in HKLMSoftwareMicrosoftGroup PolicyClientRunOnce and then run gpupdate, the preferences are applied correctly. However, just imaging the computer and not deleting
    this value results in the preferences not being applied.

Answers

  • We finally got this working, though not entirely through GPP.  We opened a ticket with MS support.  They tested and confirmed that to deploy and enable a custom GPP, the policy needs to be applied twice.  The first time it is applied it adds
    the plan to the computer.  The second time it is applied, the custom plan is enabled.  Checking the «Apply once and do not reapply» option creates a situation where the custom plan is added to the computer but not enabled. 

    Our contention was that the whole reason to use GP prefences instead of policies was to allow users the ability to change the settings if they wanted to.  If you leave the «Apply once and do not reapply» option checked, then the plan isn’t enabled. 
    If you uncheck «Apply once and do not reapply», the plan is enabled but everytime GP refreshes on the client, any changes the user makes are undone. In essence, it becomes a Group Policy (albeit, one that users can change for a brief period of time).

    MS support stated that this behavior is by design but that they would consider the scenario and improve the power plan behavior in the future. As such, we weren’t charged for the support call.

    We fixed the problem by importing the custom power plan during our imaging process and then enabling it with GPP.

    • Marked as answer by

      Thursday, April 14, 2011 7:27 AM

  • Remove From My Forums
  • Question

  • I am having a problem getting Windows Group Policy Peferences to apply to machines immediately after they are imaged.  We are using Group Policy Preferences to, among other things, set a customized power plan as the default plan.  Upon logging
    into a machine after it has been imaged, I can see our customized power plan, but it is not selected as the default plan.  RSOP shows that the policy that contains the preferences is being applied.  Group Policy settings that reside in the same
    GPO as the Preferences have also been applied correctly.  Only the Prefences are not applying.

    We are using an image task sequence in SCCM to deploy the image.  The image is of Win 7 SP1 64bit.  We ran into the same problem with Win 7 64bit (not SP1) that was resolved by appling
    hotfix 2284538. We now seeing the same problem occur when imaging with Win 7 SP1, although SP1 contains this hotfix.

    If I log into the into the machine after it is imaged and delete GUID in HKLMSoftwareMicrosoftGroup PolicyClientRunOnce and then run gpupdate, the preferences are applied correctly. However, just imaging the computer and not deleting
    this value results in the preferences not being applied.

Answers

  • We finally got this working, though not entirely through GPP.  We opened a ticket with MS support.  They tested and confirmed that to deploy and enable a custom GPP, the policy needs to be applied twice.  The first time it is applied it adds
    the plan to the computer.  The second time it is applied, the custom plan is enabled.  Checking the «Apply once and do not reapply» option creates a situation where the custom plan is added to the computer but not enabled. 

    Our contention was that the whole reason to use GP prefences instead of policies was to allow users the ability to change the settings if they wanted to.  If you leave the «Apply once and do not reapply» option checked, then the plan isn’t enabled. 
    If you uncheck «Apply once and do not reapply», the plan is enabled but everytime GP refreshes on the client, any changes the user makes are undone. In essence, it becomes a Group Policy (albeit, one that users can change for a brief period of time).

    MS support stated that this behavior is by design but that they would consider the scenario and improve the power plan behavior in the future. As such, we weren’t charged for the support call.

    We fixed the problem by importing the custom power plan during our imaging process and then enabling it with GPP.

    • Marked as answer by

      Thursday, April 14, 2011 7:27 AM

Like this post? Please share to your friends:
  • Windows не удалось применить параметры f312195e 3d9d 447a a3f5 08dffa24735e
  • Windows не удалось применить параметры deployed printer connections
  • Windows не удалось применить параметр загрузки среды предустановки windows 10
  • Windows не удалось установить необходимые файлы код ошибки 0x8007025d
  • Windows не удалось установить необходимые файлы 0x80070570