- 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.
При этом в журнале 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.
Получается, что к компьютеру не применяются только GPO с настройками клиентских расширений групповых политик CSE (client-side extension), которые отвечают за управление ключами реестра через GPO.
Расширение Registry client-side не смогло прочитать файл registry.pol. Скорее всего файл это поврежден (рекомендуем проверить файловую систему на ошибки с помощью chkdsk). Чтобы пересоздать этот файл, перейдите в каталог c:WindowsSystem32GroupPolicyMachine и переименуйте его в registry.bak.
Можно переименовать файл из командой строки:
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, указанной в ошибке.
Скопируйте 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.20xxxWindows 7 and Windows Server 2008 R2
RTM
LDR
6.1.760
1.21xxxWindows 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) для восстановления проблемных системных файлов и получения параметров питания. Ниже как:
-
Нажмите Win + X, чтобы выбрать командную строку (Admin).
-
Введите sfc / scannow и нажмите Enter. (Не забудьте поставить пробел между «sfc» и косой чертой.)
-
Введите powercfg –restoredefaultschemes после завершения выполнения команды sfc / scannow и нажмите Enter.
-
Введите DISM / Online / Cleanup-Image / RestoreHealth и нажмите Enter.
-
Перезагрузите компьютер после завершения процесса, а затем попробуйте параметр «Спящий режим», «Выключить» или «Перезагрузить» в меню питания, чтобы проверить, доступны ли теперь параметры питания.
Способ 2
Настроить редактор групповой политики для решения проблем Windows 10. После обновления создателей параметры питания недоступны
Если при выполнении команд SFC не удается исправить бесполезные параметры питания в Windows 10, попробуйте настроить редактор групповой политики, как показано в следующих руководствах.
Перед настройкой реестра лучше сначала создать резервную копию реестра, если возникнут какие-либо проблемы с системой, такие как синий экран, черный экран с курсором, Windows Hello не работает и т.д.
-
Перейдите в Поиск, введите gpedit.msc, чтобы открыть редактор групповой политики.
-
Перейдите по следующему пути:
Конфигурация пользователя -> Административные шаблоны -> Пуск и панель задач
-
Дважды щелкните «Удалить и запретить доступ к команде выключения».
-
Выберите «Не настроено» или «Отключено» и нажмите « Применить».
-
Закройте редактор групповой политики, а затем попробуйте меню параметров питания, чтобы увидеть, работает ли сейчас опция сна / гибернации / перезапуска.
Pro Совет :
Если вы являетесь пользователем Windows 10 Home, редактор групповой политики недоступен. Но вы можете запустить regedit, чтобы открыть редактор реестра, а затем следовать приведенному ниже пути, чтобы найти недостающие параметры питания обратно:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer,
Убедитесь, что значение с именем NoClose существует со значением 0.
Перезагрузите компьютер и проверьте, исправлена ли ошибка, связанная с отсутствием параметров электропитания.
Способ 3
Добавьте права пользователя в локальные параметры безопасности, чтобы вернуть отсутствующие параметры питания
Добавление прав пользователя в локальную политику безопасности также полезно для устранения неисправности параметров питания:
-
Нажмите клавиши Win + R и введите: secpol.msc, а затем нажмите Enter, чтобы открыть локальную политику безопасности.
-
Перейдите: Настройки безопасности -> Локальные политики -> Назначение прав пользователя -> Завершение работы системы.
-
Выберите « Свойства», а затем « Добавить пользователей или группу», чтобы добавить свой идентификатор пользователя или группу.
[Силовые варианты, не доступный-Windows-10-творцы-update.jpg] [4]
-
После добавления нового пользователя или группы нажмите кнопку ОК, чтобы сохранить изменения.
-
Выйдите из системы и перезагрузите компьютер.
-
Войдите в систему, и вы увидите, что доступны опции «Перезагрузка и выключение».
Способ 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 для дальнейшего обсуждения через левое меню на странице.
Содержание
- Windows не удалось применить параметры group policy local users and groups
- Спрашивающий
- Общие обсуждения
- Почему не применяется групповая политика к компьютеру или OU?
- Область действия (scope) GPO
- Фильтр безопасности GPO
- WMI фильтры GPO
- Статус групповой политики
- Делегирование GPO
- Наследование групповых политик
- Область действия и порядок применения групповых политик (LSDOU)
- GPO Link Enabled
- Замыкание групповой политики
- Диагностика применения GPO на стороне клиента
- Методика диагностики причин долгого применения GPO в Windows
- Блокирование наследования групповой политик
- Вывод подробных сообщений на экране загрузки
- Отчет GPResult
- Анализ событий от Group Policy в системных журналах Windows
- Отладочный журнал службы GPSVC
- Отладочные журналы Group Policy Preferences
- Windows 7 Клиентам периодически не удается применить групповую политику при запуске
- Симптомы
- Причина
- Решение
- Дополнительная информация
- Windows не удалось применить параметры group policy local users and groups
- К чему применяется групповая политика (GPO)
- Алгоритм устранения проблем с GPO
- Проверка прав на политику
- Инструменты диагностики групповой политики
- Диагностика GPO через gpresult
- Результаты групповой политики
Windows не удалось применить параметры group policy local users and groups
Этот форум закрыт. Спасибо за участие!
Спрашивающий
Общие обсуждения
Добрый день, проблема с отработкой групповой политики используя 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).
Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.
Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).
Фильтр безопасности GPO
Проверьте значение фильтра безопасности политики (Security Filtering). По-умолчанию на всех новых объектах GPO в домене присутствуют разрешения для группы «Authenticated Users«. Эта группа включает в себя всех пользователей и компьютеры домена. Это означает, что данная политика будет применяться на всех пользователях и ПК, которые попадают в область ее действия.
Если вы используете нестандартные фильтры безопасности политик, проверьте, что для целевых групп нет явного запрета на применение GPO (Deny).
WMI фильтры GPO
В групповых политиках можно использовать специальные WMI фильтры. Это позволяет применить политику к компьютерам на основании некоторого WMI запроса. Например, мы можете создать WMI фильтр GPO для применения политики только к компьютерам с определенной версией Windows, к ПК в определенной IP подсети, только к ноутбукам и т.д.
При использовании WMI фильтров групповых политик вам нужно проверить корректность WMI запроса, который выбирает только те системы, которые вам нужны и не исключаются ваши целевые компьютеры. Вы можете протестировать WMI фильтр на компьютерах через PowerShell
Если запрос возвращает любые данные, значит WMI фильтр применится к этому компьютеру.
Статус групповой политики
Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.
Как вы видите, доступно 4 варианта:
Делегирование GPO
На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL
Наследование групповых политик
Наследование это одна из основных концепции групповых политик. Политики верхнего уровня по-умолчанию применяются ко всем вложенным объектам в иерархии домена. Однако, администратор может заблокировать применение всех наследованных политик на определенный OU. Для этого в консоли GPMC нужно щелкнуть ПКМ по OU и выбрать пункт меню Block inheritance.
Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.
Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.
Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).
Область действия и порядок применения групповых политик (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 с помощью стрелок в левом столбце, передвинув ее выше или ниже в списке.
GPO Link Enabled
У каждого объекта GPO, который привязан к организационному контейнеру AD вы можете включить или отключить связь (применение политики). Для этого нужно включить или отключить опцию Связь включена (Link Enabled) в меню политики. Если связь для политики отключена, ее иконка становится бледной. При отключении связи политика перестает применяться к клиентам, но ссылка на объект GPO не удаляется из иерархии. Вы можете активировать данную связь в любой момент.
Замыкание групповой политики
У этой политики есть два возможных значение:
Диагностика применения GPO на стороне клиента
Также можете познакомиться со статей, описывающей принципы диагностики при слишком долгом применении политик на клиентах.
В заключении хочется сказать, что следует держать структуру групповых политик как можно более простым и не создавать лишние политик без необходимости. Используйте единую схему именование политик, имя GPO должно давать однозначное понимание того, для чего она нужна.
Источник
Методика диагностики причин долгого применения GPO в Windows
Медленная загрузка компьютера, вызванная долгим применением групповых политик, является одной из частых проблем в домене, на которые жалуются пользователи. С точки зрения пользователя компьютер загружается очень долго, и как будто зависает на несколько минут на этапе «Применение параметров компьютера / пользователя». В этой статье я попробую собрать полезные диагностические инструменты и приемы, позволяющие администратору выявить причины медленного применения GPO на компьютерах домена.
На самом деле причин, из-за которых на компьютере долго применяются групповые политики может быть множество: это и проблемы с DNS, доступностью и скоростью подключения к DC, неправильной настройкой сайтов AD или проблемы с репликацией, неверно настроенные групповых политики и кривые скрипты и т.п. Проблематично описать универсальный алгоритм по диагностике всех этих проблем. При решении таких проблем, как правило, большую роль имеет опыт и навыки специалиста, производящего диагностику. В этой статье мы остановимся только на диагностики проблем, связанных с самими механизмами работы GPO и клиента GPClient.
Блокирование наследования групповой политик
Перезагрузите компьютер и проверьте, сохранилась ли проблема с долгим применением GPO. Если сохранилась, вероятнее всего проблема с самим компьютером или локальными политиками (попробуйте их сбросить на дефолтные).
Вывод подробных сообщений на экране загрузки
В Windows на экране загрузки системы можно включить отображение расширенной статусной информации, позволяющей пользователям и администратору визуально понять на каком этапе загрузки компьютера наблюдается наибольшая задержка. При включении данной политики, в том числе, начинает отображаться информация о применяемых компонентах GPO.
Включить эту политику можно в следующем разделе GPO:
Этот же параметр можно активировать через реестр, создав в ветке HKEY_LOCAL_MACHINESOFTWARE Microsoft Windows CurrentVersion PoliciesSystem параметр типа DWORD с именем verbosestatus и значением 1.
В результате на экране в процессе загрузки будут отображаться такие сообщения:
Отчет 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
Анализ событий от Group Policy в системных журналах Windows
В журнале приложений о медленном применении политик может свидетельствовать событие с EventID 6006 от источника Winlogon с текстом:
Судя по данному событию, пользователю пришлось ждать применения групповых политик при загрузке компьютера в течении почти часа…
Для анализа времени применения политик будут полезны следующие EventID:
При анализе журнала стоит также обращать на время, прошедшее между двумя соседними событиями, это может помочь обнаружить проблемный компонент.
Отладочный журнал службы GPSVC
В некоторых ситуациях бывает полезным включить ведение отладочного журнала обработки GPO — gpsvc.log. С помощью временных меток в файле gpsvc.log можно найти компоненты GPO, которые долго отрабатывали.
Отладочные журналы Group Policy Preferences
Как вы видите, доступные индивидуальные настройки для каждого CSE. В настройках политики можно указать тип событий, записываемых в журнал (Informational, Errors, Warnings или все), максимальный размер журнала и местоположение лога:
После сбора логов нужно проанализировать их на ошибки, а также попытаться найти соседние события, время между которыми отличается на несколько минут.
Итак, в этой статье мы рассмотрели основные способы диагностики проблем долгого применения групповых политик на компьютерах домена. Надеюсь, статья будет полезной.
Источник
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 объекты пользователей и компьютеров не лежат просто так, а располагаются в двух видах папок:
Алгоритм устранения проблем с GPO
Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers«. Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.
Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.
Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта«, по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.
Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка «Связь включена«, ее так же можно проверить на вкладке «Область» в столбце «Связь задействована», должно стоять значение «да».
Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено«, означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».
Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.
Проверка прав на политику
Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе «Управление групповой политикой» выберите ваш GPO. На вкладке «Область» найдите раздел «Фильтры безопасности«, он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:
Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу «Прошедшие проверку» из фильтра безопасности, она удаляется и из вкладки делегирование.
Поэтому перейдите на вкладку «Делегирование» и проверьте наличие любой из групп «Прошедшие проверку» или «Компьютеры домена» и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку «Дополнительно», далее добавить и выберите «Прошедшие проверку».
Удостоверьтесь, что выставлена галка «Чтение».
Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.
Обратите внимание на группу «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)» данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.
Еще одним механизмом фильтрации групповой политики, может выступать WMI фильтры. Если они есть и ваш объект не соответствует его требованиям, то вы не сможете применить политику. Посмотреть, это можно в соответствующем разделе. В моем примере есть WMI фильтр для ноутбуков, который не даст применения политики на стационарные компьютеры. Подробнее, о создании WMI фильтров и механизме проверки WMI фильтров, читайте по ссылкам. Ниже я покажу, как на конечном компьютере увидеть, что он не подошел из-за фильтрации GPO по WMI.
Инструменты диагностики групповой политики
Выше мы разобрали возможные места, где могла быть проблема, но по мимо них еще есть несколько инструментов, которые могут дать системному администратору информацию, о причинах, которые мешают применению GPO к нужному объекту.
Существуют три инструмента, которые вам покажут информацию, о применяемых политиках на объекты:
Диагностика GPO через gpresult
Gpresult первое средство, которое позволит системному администратору определить на каком этапе есть проблемы с выполнением GPO. Откройте на клиентском компьютере или ноутбуке командную строку от имени администратора и введите команду:
В моем примере у меня есть политика для компьютера «Управление UIPI», поэтому я воспользуюсь gpresult для компьютера. Выполнив gpresult /r /scope:computer я вижу, что моя политика не применилась и числится в списке «Следующие политики GPO не были применены, так как они отфильтрованы». Фильтрация отказано в доступе (Безопасность). Из этого видно, что у компьютера просто нет прав на чтение политики.
Так же в логах Windows вы можете обнаружить событие с кодом ID 5313:
Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (безопасность)
А вот пример 5313, но с уже WMI фильтром:
Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (фильтр WMI)
Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.
Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.
Начнется сбор применяемых политик.
По результатам, у вас откроется окно результирующей политики. Похожее на то, где вы редактируете политику GPO. Тут вы можете перемещаться по веткам и смотреть текущие значения.
Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:
Результаты групповой политики
В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется «Результат моделирования групповой политики». Щелкаем по нему правым кликом и открываем мастер.
Выбираем нужный компьютер, к которому мы хотим проверить применение политики.
Если в момент добавления компьютера у вас выскочит ошибка «Сервер RPC-недоступен», то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.
Так как я проверяю GPO для компьютера, то мне нет смысла отображать политику для пользователей.
Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке «Сведения» вы увидите, какие политики применены, а какие нет.
Раскрыв подробнее политику, которая не смогла примениться, я вижу, что причиной всему был WMI фильтр.
Последним удобным инструментом диагностики и моделирования групповой политики, выступает функционал GPMC, под названием «Моделирование групповой политики«. В задачи которого входит проверка применения политики в существующей ситуации, так и просто тест без реальной прилинковки к OU, указав нужный объект. В оснастке GPMC выберите пункт «Моделирование групповой политикой» и щелкните по нему правым кликом, выбрав «Мастер моделирования групповой политики».
На первом шаге мастера моделирования групповой политики, будет простое уведомление, что к чему, нажимаем далее.
Далее вам будет предложен выбор, дабы указать нужный контроллер домена.
Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку «Обзор». Я выбрал «Client Computers»
На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:
Указываем в какой группе находится наш объект, к которому будет применяться политика.
далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.
В итоге мы получаем результат моделирования групповой политики, тут можно посмотреть, что применилось, что нет.
Источник
В этом руководстве я постараюсь рассказать вам о типичных причинах, по которым объект групповой политики (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 варианта:
- All settings disabled (Все настройки отключены) — все настройки политики отключены (GPO не применяется);
- Computer configuration settings disabled (Параметры конфигурации компьютера отключены) — параметры только из конфигурации компьютера вашего GPO не применяются;
- User configuration settings disabled (Параметры конфигурации пользователя отключены) — параметры из раздела конфигурации пользователя не применяются;
- 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 применяются к клиентам в следующем порядке:
- Политики локального компьютера (Local), настроенные в gpedit.msc (Редактор локальной групповой политики);
- GPO уровня сайта (Site);
- GPO уровня домена (Domain).
- Объекты групповой политики с уровня организационного подразделения (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 (в русифицированной версии Конфигурация компьютера → Политики → Административные шаблоны → Система → Групповая политика → Настройка режима обработки замыкания пользовательской групповой политики). Например, если вы включите обработку обратной связи политики, зададите некоторые параметры в разделе «Конфигурация пользователя» и свяжете политику с подразделением с объектами компьютеров, эти параметры политики будут применены к выполнившим вход пользователям.
Этот режим обработки замыкания политики имеет два возможных значения:
-
Merge («Слияние») – сначала к пользователю применяется объект групповой политики на основе местоположения пользователя, а затем применяется объект групповой политики, связанный с компьютером. В случае конфликта политик OU пользователя и компьютера, политика компьютера будет иметь более высокий приоритет.
В этом режиме политика запускается дважды, обратите внимание на это при использовании сценариев входа в систему. - 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
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз я вам показал, как я делал досрочное погашение ипотеки Сбербанка, поделился свои жизненным опытом. Сегодня я хочу вас научить, как находить и диагностировать причины, по которым у вас может не применяться назначенная вами групповая политика к компьютеру или пользователю или целому организационному подразделению. Мы рассмотрим все этапы, через которые проходит происходит взаимодействие с GPO. Разберем утилиты, которыми должен владеть системный администратор в задачи которого входит создание и назначение политик. Уверен, что данный пост будет вам полезен и интересен.
За, что Active Directory от Microsoft получила такую популярность? Одним из ответов на данный вопрос, будет функционал групповой политики. Все администраторы, как и большинство современных людей, существа очень ленивые и любят, когда все централизованно управляется и по возможности автоматизированно. Именно объекты GPO, позволяют производить настройки десятков, сотен и тысяч компьютеров, из одного места и практически по всем направлениям, например добавление принтеров, скриптов входа, профилей WiFi и многое другое.
Очень частые ситуации, что системный администратор создал новую групповую политику, применил ее на нужный ему объект, но эффекта это не дало и нужно понять почему она не применилась и вот тут начинающие системные администраторы попадают в просак, не понимая, где и что нужно искать. Ниже мы с вами разберем алгоритм действий, который поможет вам найти причину и восстановить работу применения групповой политики на нужный объект.
К чему применяется групповая политика (GPO)
Первое, на что я хочу обратить внимание, это ответить, что делает групповая политика. Все мы прекрасно знаем, что операционная система Windows, это набор служб и ключей реестра. Все настройки, которые вы видите и меняете в графическом режиме, по сути меняют ключи реестра. Понимая, это сразу можно сделать вывод:
- что реестр есть как для объекта компьютер
- и реестр есть для объекта пользователь
Именно эту две сущности являются конечными объектами в политике GPO. В Active Directory объекты пользователей и компьютеров не лежат просто так, а располагаются в двух видах папок:
- Это контейнер — по сути простая папка, важно, что к ней нельзя применять объекты групповой политики.
- Второй тип, это организационные подразделения (OU) — это специальные папки для объединения объектов AD по принципам. Именно с OU связываются объекты групповой политики, для применения их к компьютерам и пользователям. Внешне контейнер отличается от организационной утилитой, тем что у OU, есть дополнительная лычка на значке, это показано на скриншоте.
Алгоритм устранения проблем с GPO
Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers«. Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.
Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики. В моем случае, это путь root.pyatilistnik.org/Client Computers.
Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта«, по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.
Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка «Связь включена«, ее так же можно проверить на вкладке «Область» в столбце «Связь задействована», должно стоять значение «да».
Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено«, означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:
- Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
- Параметры конфигурации пользователя отключены (User configuration settings disabled)
- Все параметры отключены (All setting disabled) — запретит применение политики для любого объекта
Сделано, это для ускорения применения политики к объекты. Согласитесь, что если у вас в GPO настроены изменения только для пользователя, то нет смысла проверять политику для компьютера. Поэтому системные администраторы могут отключать это, но могут и ошибиться, выключив не тот объект
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».
Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.
Проверка прав на политику
Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе «Управление групповой политикой» выберите ваш GPO. На вкладке «Область» найдите раздел «Фильтры безопасности«, он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:
- Пользователь
- Компьютер
- Группа безопасности
По умолчанию тут прописана группа безопасности «Прошедшие проверку (Authenticated Users)». По умолчанию в данную группу входят все доменные пользователи и доменные компьютеры
Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу «Прошедшие проверку» из фильтра безопасности, она удаляется и из вкладки делегирование.
Чтобы параметры групповой политики для пользователя успешно применялись, она требует наличия у каждой учетной записи компьютера разрешения на считывание данных GPO из контроллера домена. Удаление группы «Прошедшие проверку» может предотвратить обработку групповых политик для пользователя. добавьте группу безопасности «Пользователи, прошедшие проверку подлинности» или «Компьютеры домена», у которой есть по крайней мере разрешение только для чтения (https://support.microsoft.com/en-us/kb/316622)
Поэтому перейдите на вкладку «Делегирование» и проверьте наличие любой из групп «Прошедшие проверку» или «Компьютеры домена» и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку «Дополнительно», далее добавить и выберите «Прошедшие проверку».
Удостоверьтесь, что выставлена галка «Чтение».
Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.
Обратите внимание на группу «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)» данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы.
Еще одним механизмом фильтрации групповой политики, может выступать WMI фильтры. Если они есть и ваш объект не соответствует его требованиям, то вы не сможете применить политику. Посмотреть, это можно в соответствующем разделе. В моем примере есть WMI фильтр для ноутбуков, который не даст применения политики на стационарные компьютеры. Подробнее, о создании WMI фильтров и механизме проверки WMI фильтров, читайте по ссылкам. Ниже я покажу, как на конечном компьютере увидеть, что он не подошел из-за фильтрации GPO по 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, но с уже WMI фильтром:
Следующие объекты групповой политики не были применены, так как они были отфильтрованы:
Local Group Policy
Не применяется (пусто)
Управление UIPI
Отказано (фильтр WMI)
Я для исключаю его из запрета применения и пробую новую попытку применения политики. Я делаю для начала обновление групповой политики через gpupdate /force и затем снова выполняю команду gpresult /r /scope:computer, где теперь вижу, что политика не применилась из-за WMI фильтра. Теперь уже понятно куда копать.
Получение данных GPResult с удаленного компьютера GPResult /s server01 /r, поможет администратору или технической поддержке собрать диагностические данные. Аналогичные действия вы можете выполнять и для пользователя, тут все аналогично. Теперь воспользуемся утилитой RSOP. Откройте окно выполнить и введите rsop.msc.
Начнется сбор применяемых политик.
По результатам, у вас откроется окно результирующей политики. Похожее на то, где вы редактируете политику GPO. Тут вы можете перемещаться по веткам и смотреть текущие значения.
Но это не удобно и мы можем совместить две утилиты gpresult и Resultant Set of Policies (RSoP), получив выгодный симбиоз. В командной строке введите:
GPResult /h c:report.html /f
На выходе вы получите удобный html отчет, о всех примененных или отфильтрованных политиках. Открыв отчет, вы легко поймете ,какие политики были применены, а какие нет и можете сразу посмотреть значения настроек.
Результаты групповой политики
В оснастке GPMC есть возможность посмотреть какие политики применяются к нужному объекту групповой политики. Данный мастер называется «Результат моделирования групповой политики». Щелкаем по нему правым кликом и открываем мастер.
Выбираем нужный компьютер, к которому мы хотим проверить применение политики.
Если в момент добавления компьютера у вас выскочит ошибка «Сервер RPC-недоступен», то проверьте, что у вас запущена на нем служба WMI и в брандмауэре открыты порты для подключения к ней.
Так как я проверяю GPO для компьютера, то мне нет смысла отображать политику для пользователей.
Нажимаем далее. У вас появится отчет. Раскрыв его на вкладке «Сведения» вы увидите, какие политики применены, а какие нет.
Раскрыв подробнее политику, которая не смогла примениться, я вижу, что причиной всему был WMI фильтр.
Последним удобным инструментом диагностики и моделирования групповой политики, выступает функционал GPMC, под названием «Моделирование групповой политики«. В задачи которого входит проверка применения политики в существующей ситуации, так и просто тест без реальной прилинковки к OU, указав нужный объект. В оснастке GPMC выберите пункт «Моделирование групповой политикой» и щелкните по нему правым кликом, выбрав «Мастер моделирования групповой политики».
На первом шаге мастера моделирования групповой политики, будет простое уведомление, что к чему, нажимаем далее.
Далее вам будет предложен выбор, дабы указать нужный контроллер домена.
Теперь выбираем нужную OU, для которой мы будем тестировать групповую политику. Делается все через кнопку «Обзор». Я выбрал «Client Computers»
Нажимаем далее.
На следующем шаге мастера моделирования групповой политики, вам предоставят сэмулировать таки параметры:
- Медленное сетевое подключение, меньше 500 кб/с
- Обработка петлевого адреса (Замыкание групповой политики — loopbacl policy) — это опция когда вы применяете для OU в которой находятся компьютеры, например терминальные сервера, политики для пользователя. Делается это для того, чтобы политики применяемые к пользователю на его рабочей станции или другом сервере от тех, что в данной OU. Можете подробно почитать, что такое замыкание групповой политики.
- Выбор сайта.
Указываем в какой группе находится наш объект, к которому будет применяться политика.
далее вы можете применить любой из фильтров WMI, который вы хотите тестировать.
Нажимаем далее.
В итоге мы получаем результат моделирования групповой политики, тут можно посмотреть, что применилось, что нет.
На этом у меня все. С вами был Иван Семин, автор и создатель 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
-
Marked as answer by
- 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
-
Marked as answer by