Груповите политики не се прилагат в Windows 11: ръководство за IT Helpdesk (2026)

Актуализирано: 20 юни 2026

Груповите политики не се прилагат в Windows 11 най-често по три причини: прекъсната комуникация между клиента и контролера на домейн, неправилно филтриране на сигурността или WMI, или спряна услуга Group Policy Client (gpsvc). В това ръководство ще премина през цялостен процес на диагностика, от gpupdate /force и gpresult /h през Event Viewer до SYSVOL репликация и съжителство с Microsoft Intune. Имам мнение по темата за Group Policy и ще го споделя, но всяка стъпка е придружена с PowerShell, който всеки tier-1 техник може да изпълни.

• Винаги започвайте с gpresult /h C:\Temp\rsop.html, този HTML отчет показва точно кои GPO са приложени и кои са отхвърлени, заедно с причината.
• Услугата Group Policy Client (gpsvc) в Windows 11 24H2/25H2 не може да се рестартира ръчно; нужен е рестарт на машината или sc config gpsvc.
• Filtering Denied (Security) в RSoP отчета означава, че потребителят или компютърът не е в групата за сигурностно филтриране, това е причина №1 за „политиката не се прилага“.
• Грешки 1058 и 1030 в Event Viewer почти винаги сочат към SYSVOL/DFS репликация или мрежови проблем към домейн контролера, не към самата политика.
• Hybrid сценарии с Microsoft Intune Settings Catalog могат тихо да презапишат локални GPO, проверете MDM Diagnostics Tool преди да обвинявате on-prem GPO.
• За Windows 11 машини извън домейн използвайте LGPO.exe от Security Compliance Toolkit вместо ръчно редактиране на gpedit.msc.

Бърза диагностика: първите 5 минути

Преди да отворите ADUC и преди да отворите GPMC, направете следните проверки от засегнатата Windows 11 машина. Около 70% от случаите се решават на този етап, гарантирам го от опит на service desk-а.

Първо, потвърдете, че машината вижда домейн контролера. От PowerShell с административни права:

# Проверете кой контролер на домейн обслужва машината в момента
nltest /dsgetdc:contoso.local

# Тествайте DNS преди всичко - 90% от GPO проблемите са DNS проблеми
nslookup contoso.local
ping -n 2 contoso.local

# Проверете дали Kerberos билетите са валидни
klist

Ако nltest не намира домейн контролер или klist показва изтекли билети, спрете тук, нямате GPO проблем, имате проблем с DNS и комуникацията към домейна. Никаква политика няма да се приложи, докато машината не може да се удостовери в домейна.

Второ, изпълнете „чисто“ обновяване и наблюдавайте изхода внимателно, не пропускайте предупрежденията:

# Принудително обновяване на компютърни и потребителски политики
gpupdate /force /wait:600

# Ако се появи "The processing of Group Policy failed" - вижте Event Viewer
# Application and Services Logs > Microsoft > Windows > GroupPolicy > Operational

Трето, генерирайте RSoP HTML отчет. Това е най-полезният инструмент в арсенала на service desk-а и почти никой tier-1 техник не го използва правилно:

# Генерира пълен HTML отчет с приложени и отхвърлени политики
gpresult /h C:\Temp\rsop_$(hostname).html /f

# За конкретен потребител, ако работите под друг профил
gpresult /h C:\Temp\rsop_user.html /user CONTOSO\jdoe /f

Как да прочета gpresult и RSoP отчета правилно

RSoP HTML отчетът е разделен на две основни секции: Computer Configuration и User Configuration. Това разделение е критично, една политика може да е дефинирана като User-side, но прилагана към компютърна OU, и тогава просто никога няма да се изпълни. Това е грешка, която виждам поне веднъж седмично.

Под всяка секция има три ключови блока:

1. Applied GPOs, списък на всички политики, които са се приложили успешно, с приоритет. По-нисък номер означава по-висок приоритет. Local Group Policy винаги е с приоритет 1 и почти винаги се презаписва от домейн GPO.
2. Denied GPOs, политиките, които системата е разгледала, но е отхвърлила, с причината. Това е златната секция. Възможните причини са: Empty, Disabled Link, Inaccessible, Filtering: Denied (Security), Filtering: Denied (WMI), Not Applied (Empty).
3. Component Status, показва грешки в обработката на отделни Client-Side Extensions (CSE), например Group Policy Drive Maps или Software Installation. Ако CSE-то се срине, всички настройки от тази категория се пропускат тихо.

За най-бърз преглед от PowerShell без браузър:

# Текстов изход - удобен за поставяне в тикет
gpresult /r /scope:computer
gpresult /r /scope:user

# Само показва приложените GPO в табличен вид
(gpresult /r) -match "Applied Group Policy Objects" -or $_ -match "    "

Ако в Denied GPOs виждате Filtering: Denied (Security), проверката е завършила, потребителят/компютърът не е член на групата за сигурностно филтриране на тази GPO. Стъпката, която следва тогава, не е „опитай отново“, а Active Directory Users and Computers + проверка на членството. Между другото, вижте и нашето ръководство за заключени Active Directory акаунти, защото заключен акаунт също води до неприложими политики.

Защо моята групова политика не се прилага?

Това е въпросът, който получавам най-често от tier-1, и почти винаги отговорът е една от шест конкретни причини. Подреждам ги по честота от моя service desk:

1. Грешен Link на GPO-то. Политиката е свързана към OU, в която компютърът/потребителят не е. Проверете в ADUC точното Distinguished Name на обекта и в GPMC точно върху коя OU виси Link-ът. Виждам това поне три пъти седмично, особено след премествания на акаунти между OU.
2. Security Filtering изключва обекта. Когато премахнете Authenticated Users от Security Filtering без да добавите Domain Computers с Read право (изискване от KB4565793 от 2020 насам), политиката се игнорира тихо.
3. Block Inheritance + не-Enforced. Някоя горна OU блокира наследяването, а вие не сте маркирали Link-а като Enforced. RSoP ще покаже причина Disabled Link.
4. Loopback Processing не е конфигуриран правилно. Класически проблем при Terminal Server / RDS среди, User настройки от една OU трябва да се приложат на компютри в друга OU. Без Loopback те просто няма да се изпълнят.
5. Услугата gpsvc е спряна или повредена. Виж следващата секция.
6. SYSVOL не може да се достигне или е извън синхрон между DC-та. Клиентът удря локалния DC, но GPT (Group Policy Template) частта в SYSVOL е стара версия, резултат: настройките се прилагат частично или изобщо не.

Услугата Group Policy Client (gpsvc) и нейните проблеми в Windows 11

Group Policy Client (gpsvc) е услугата, която прилага политиките на клиента. В Windows 11 24H2 и по-нови версии Microsoft заключи тази услуга, не може да бъде спирана или стартирана от services.msc, не може да бъде убита през taskkill, дори с SYSTEM привилегии. Това е по дизайн, не е бъг.

Симптом, който виждаме: при логин се появява съобщението „The Group Policy Client service failed the sign-in. Access is denied.“ или политиките просто не се прилагат до следващ рестарт.

За проверка на здравето на услугата:

# Проверете състоянието и зависимостите на услугата
Get-Service gpsvc | Format-List Name, Status, StartType, DependentServices, ServicesDependedOn

# Конфигурация - трябва да е auto и да стартира под svchost netsvcs група
sc qc gpsvc

# Регистърен ключ, от който услугата зависи
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost" | Select-Object netsvcs

Ако ключът HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost\GPSvcGroup липсва, услугата няма да може да стартира. Това е известен сценарий след агресивно „почистване“ на регистъра с инструменти от трети страни, забрана №1 в моя service desk.

Поправката, която Microsoft официално поддържа за повреден gpsvc в Windows 11 (виж статията от Microsoft Learn за gpsvc грешки):

# Регистрирайте отново DLL-овете, които обслужват Group Policy
regsvr32 /s userenv.dll
regsvr32 /s scecli.dll
regsvr32 /s gpkcsvc.dll
regsvr32 /s gptext.dll
regsvr32 /s wlgpclnt.dll

# Принудителен рестарт на услугата чрез SYSTEM context (изисква PsExec или Task Scheduler)
schtasks /create /tn "Restart gpsvc" /tr "powershell.exe -Command Restart-Service gpsvc -Force" /sc once /st 23:59 /ru SYSTEM /rl HIGHEST /f
schtasks /run /tn "Restart gpsvc"
schtasks /delete /tn "Restart gpsvc" /f

SYSVOL, DFS репликация и грешки 1058/1030

Когато в Event Viewer (Application log) виждате двойка Event ID 1058 („The processing of Group Policy failed“) и Event ID 1030 („Windows cannot query for the list of Group Policy objects“), 95% от случаите проблемът не е на клиента, той е в SYSVOL папката на домейн контролера.

SYSVOL съдържа GPT (Group Policy Template) частта на всяка политика, самите ADM/ADMX файлове, скриптове, registry.pol файлове. Ако SYSVOL се реплицира с DFS-R (стандарт от Windows Server 2008 насам, FRS отдавна е deprecated) и репликацията е блокирана, различни DC-та обслужват различни версии на политиката.

Бърза диагностика от Windows 11 клиент:

# Тест за достъп до SYSVOL share
Test-Path "\\contoso.local\sysvol\contoso.local\Policies"

# Списък на GPO папките със съответните GUID-ове
Get-ChildItem "\\contoso.local\sysvol\contoso.local\Policies" | Select-Object Name, LastWriteTime

# Проверка на версията на GPT.ini за конкретна политика
Get-Content "\\contoso.local\sysvol\contoso.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\GPT.ini"

Версията в GPT.ini трябва да съвпада с версионния номер, който виждате в GPMC за същата политика. Ако не съвпада, имате репликационен проблем. От домейн контролер:

# Здраве на DFS репликацията за SYSVOL
dfsrdiag replicationstate /member:DC01

# Проверете backlog между DC-та
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC01 /rmem:DC02

Филтриране на сигурността, WMI филтри и Item-Level Targeting

Когато RSoP показва Filtering: Denied (Security), отидете в GPMC → конкретната GPO → таб Delegation и проверете точните разрешения. Минималното изискване след KB4565793 е следното:

Принципал	Минимални права	Бележка
Authenticated Users	Read (НЕ Apply Group Policy)	Задължително от 2020 г., без това GPO се пропуска тихо
Целева група (напр. „HR Workstations“)	Read + Apply Group Policy	Това определя на кого се прилага политиката
Domain Admins	Edit, Delete, Modify Security	Стандартно по подразбиране
SYSTEM	Edit, Delete, Modify Security	Без това няма обновявания през Schedule
Domain Computers (при компютърни политики)	Read	Алтернатива на Authenticated Users след KB4565793

WMI филтри са следващата гадост. Класически пример, филтър „само за Windows 11“ написан като Select * from Win32_OperatingSystem where Version like "10.0%" ще съвпадне и с Windows 10, защото Windows 11 също докладва Version 10.0. Винаги тествайте WMI заявката директно:

# Тествайте WMI заявката от целевия Windows 11 клиент
Get-CimInstance -Query "Select * from Win32_OperatingSystem where BuildNumber >= 22000"

# Правилен WMI филтър за само Windows 11 (build 22000+)
# Select * from Win32_OperatingSystem where BuildNumber >= "22000" and ProductType = "1"

Group Policy Preferences имат и собствено филтриране, Item-Level Targeting. То се прилага извън стандартния RSoP поток и често обърква диагностиката, защото отчетът ще покаже, че GPO-то е приложено, но конкретната Preference няма да я има на клиента. За тях вижте Event Viewer → Applications and Services Logs → Microsoft → Windows → Group Policy → Operational и търсете събития от съответния CSE.

Как да форсирам обновяване на груповите политики?

Командата gpupdate /force прави това, което повечето tier-1 техници мислят, че прави, но има няколко неща, които ще ви спестят часове, ако ги знаете:

# Принудително пълно обновяване и на двете - компютър и потребител
gpupdate /force

# Само компютърни политики (полезно при тестване на нова security baseline)
gpupdate /target:computer /force

# Само потребителски политики
gpupdate /target:user /force

# Принудителен logoff или рестарт, ако политиката го изисква (напр. Folder Redirection)
gpupdate /force /boot       # ще рестартира машината
gpupdate /force /logoff     # ще излезе от профила

За масово обновяване на множество клиенти едновременно, например след критична security политика, използвайте Invoke-GPUpdate от Group Policy PowerShell модула:

# Изисква RSAT - Group Policy Management Tools
Import-Module GroupPolicy

# Обнови всички компютри в дадена OU - произволно забавяне 0-10 мин за избягване на DC претоварване
Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=contoso,DC=local" | ForEach-Object {
    Invoke-GPUpdate -Computer $_.Name -RandomDelayInMinutes 10 -Force
}

Group Policy срещу Microsoft Intune: коя печели?

През 2026 повечето организации, които поддържам, са в хибриден режим, част от настройките идват от on-prem GPO, част от Microsoft Intune Settings Catalog. Кратък отговор на въпроса „коя печели?“, Intune печели почти винаги, когато двете дефинират една и съща настройка.

Точното правило е заложено в Windows CSP processor: при конфликт MDM канала надделява над Group Policy, освен ако изрично не активирате политиката „MDM Wins over GP“ или нейната обратна версия. Това е документирано в CSP документацията на Microsoft за Policy Conflict.

За диагностика на Intune страната използвайте MDM Diagnostics Tool, който е вграден в Windows 11:

# Събира пълен MDM диагностичен пакет в ZIP
MdmDiagnosticsTool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip C:\Temp\mdm.zip

# Бърз преглед кои политики идват от MDM
Get-CimInstance -Namespace root/cimv2/mdm/dmmap -ClassName MDM_Policy_Result01_*

Моят съвет за хибридни среди, водете един жив документ кой канал управлява коя настройка и не разрешавайте дублирания. Конкуриращи се канали са най-сериозната оперативна тежест на helpdesk-а, по-лоша от лошия hardware.

PowerShell диагностични скриптове за tier-1

Стандартизирах следния скрипт за моя service desk. Tier-1 техникът го пуска от засегнатия Windows 11 клиент, ZIP файлът се качва в тикета и tier-2 има всичко, което му трябва, за да диагностицира за под 5 минути.

# GPO-Diag.ps1 - Бърза диагностика на Group Policy за Windows 11 (Helpdesk Hero, 2026)
# Изпълнете от PowerShell с административни права

$out = "C:\Temp\GPODiag_$(hostname)_$(Get-Date -Format yyyyMMddHHmm)"
New-Item -ItemType Directory -Path $out -Force | Out-Null

# 1. RSoP HTML отчет - най-важният артефакт
gpresult /h "$out\rsop.html" /f

# 2. Текстов изход за бърз прочит в тикет
gpresult /r /z > "$out\gpresult.txt"

# 3. Domain controller, който обслужва машината в момента
nltest /dsgetdc:$env:USERDNSDOMAIN > "$out\dc.txt"

# 4. Kerberos билети - изтекли билети = няма политики
klist > "$out\klist.txt"
klist tgt >> "$out\klist.txt"

# 5. Релевантни Event Viewer събития от последните 24 часа
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1058,1030,1006,1500,1085; StartTime=(Get-Date).AddHours(-24)} -ErrorAction SilentlyContinue |
    Export-Csv "$out\events_system.csv" -NoTypeInformation

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-GroupPolicy/Operational'; StartTime=(Get-Date).AddHours(-24)} -ErrorAction SilentlyContinue |
    Export-Csv "$out\events_gpo_operational.csv" -NoTypeInformation

# 6. Здраве на gpsvc услугата
Get-Service gpsvc | Format-List * | Out-File "$out\gpsvc_status.txt"

# 7. MDM политики (за хибридни Intune среди)
Get-CimInstance -Namespace root/cimv2/mdm/dmmap -ClassName MDM_Policy_Result01_* -ErrorAction SilentlyContinue |
    Format-List | Out-File "$out\mdm_policies.txt"

# 8. Опаковка в ZIP за качване в тикета
Compress-Archive -Path "$out\*" -DestinationPath "$out.zip" -Force
Write-Host "Готово: $out.zip - качете в тикета" -ForegroundColor Green

Този скрипт е безопасен за изпълнение на която и да е продуктивна машина, само чете и изнася. Никога не променя политики и не рестартира услуги. След като минете през него, имате 90% от данните, необходими за решение. За останалите 10%, обикновено намесват и VPN маршрутизация към домейн контролерите или мрежови сегментации.

За дълбок анализ на самата CSE обработка прочетете и официалното ръководство на Microsoft за Group Policy processing, то документира точните стъпки, през които клиентът преминава, и грешките, които можете да очаквате на всеки етап.

Често задавани въпроси

Защо gpupdate /force показва „The processing of Group Policy failed“?

В 95% от случаите причината е мрежова, клиентът не може да достигне SYSVOL share-а на домейн контролера. Проверете DNS резолюцията на домейна, тествайте Test-Path "\\domain\sysvol" и погледнете Event ID 1058 в System log за точната грешка с код. Често е свързано с VPN tunnel, който не маршрутизира SMB.

Колко често Windows 11 обновява груповите политики автоматично?

На всеки 90 минути за компютърни и потребителски политики, плюс произволно отместване от 0 до 30 минути за избягване на едновременни заявки към DC-тата. Домейн контролерите се обновяват на всеки 5 минути. Тези стойности са конфигурируеми чрез Computer Configuration → Administrative Templates → System → Group Policy.

Как да проверя коя GPO променя дадена настройка?

Отворете RSoP HTML отчета (gpresult /h), намерете настройката в таблиците под Computer или User Configuration. До всяка настройка е изброена точната GPO и приоритетът ѝ. Алтернатива е rsop.msc снапин-ът, но HTML версията е по-четима за тикети.

Може ли Group Policy да работи без Active Directory?

Да, чрез Local Group Policy Editor (gpedit.msc) или за по-голям контрол, LGPO.exe от Microsoft Security Compliance Toolkit. Локалните политики се запазват в %SystemRoot%\System32\GroupPolicy и се прилагат и при работа извън домейн. За управление на много машини без AD предпочитайте Microsoft Intune.

Защо моята нова GPO се прилага на едни машини, а на други не?

Най-честата причина в 2026 е SYSVOL репликация, машините, които ударят DC с актуална SYSVOL версия, виждат политиката, останалите не. Стартирайте dfsrdiag backlog между домейн контролерите. Втора честа причина е Security Filtering, която включва само част от целевите обекти, или прекаран WMI филтър, който не съвпада на всички машини.

Трябва ли да мигрирам от Group Policy към Microsoft Intune?

За нови Windows 11 устройства, особено дистанционни, да. Intune Settings Catalog покрива над 90% от настройките, които ползвахте в GPO, и работи без VPN до домейна. Не премахвайте on-prem GPO от сървърни и стари клиентски OS изведнъж, водете план за съ-съществуване и помнете, че MDM канал надделява при конфликт.