Групова політика не застосовується у Windows 11: діагностика gpupdate, gpresult та SYSVOL у 2026

Оновлено: 28 червня 2026

Якщо групова політика не застосовується у Windows 11, у 90% випадків винна одна з трьох речей: клієнт не бачить контролер домену через DNS, обʼєкт GPO відфільтровано через security filtering або WMI, або файл gpt.ini у SYSVOL пошкоджений. Перевіряється це за дві хвилини: gpresult /h C:\Temp\gp.html на клієнті плюс dcdiag /test:sysvolcheck на DC. Усе інше зводиться до танців навколо цих трьох причин. У цьому посібнику я розкладу повний алгоритм траблшутингу, який ми використовуємо в сервіс-деску щодня.

• Завжди починайте з gpresult /h. Він покаже, які GPO застосовані, відфільтровані та чому саме (security filtering, WMI, link disabled).
• Події 1058 і 1030 у Group Policy Operational log майже завжди означають проблему доступу до SYSVOL або NETLOGON через SMB чи DFS-N.
• Команда gpupdate /force НЕ перезапускає Computer Configuration без логауту або ребуту. Для політик користувача потрібен /logoff, для політик компʼютера /boot.
• Slow link detection (за замовчуванням 500 Кбіт/с) блокує застосування Folder Redirection, Software Installation і Scripts по VPN. Це не баг, це фіча.
• Loopback processing у режимі Replace ламає звичні політики користувача, тому використовуйте Merge у 95% випадків.
• У Windows 11 23H2+ Microsoft депрекейтнула старі ADMX для деяких функцій (наприклад Edge legacy), тож оновіть Central Store до версії 24H2.

Чому Group Policy не застосовується: 7 типових причин

Чесно скажу: за дев'ять років роботи з Active Directory я не пригадаю більше десяти унікальних причин, чому GPO не застосовується. Решта це варіації на тему. Ось перелік від найчастішого до екзотики, і саме у такому порядку я раджу tier-1 проганяти чекліст.

1. Клієнт не може долучитись до DC. DNS вказує на 8.8.8.8 замість контролера, або порт 445 закритий між підмережами. nltest /sc_query:domain.local покаже статус secure channel.
2. GPO не злінкований до правильної OU. Класика: політика лежить у Group Policy Objects, але ніхто не зробив Link Enabled на OU користувачів.
3. Security filtering виключає обʼєкт. За замовчуванням стоїть Authenticated Users, але часто хтось «безпечно» це міняє на конкретну групу й забуває додати Read.
4. WMI-фільтр не матчиться. Запит на Win32_OperatingSystem WHERE Version LIKE "10.0%" впаде на Windows 11 24H2, бо у ній build number 26100. На цій деталі згоріло пів галузі.
5. SYSVOL не реплікується. Класична проблема після міграції FRS→DFSR, що Microsoft давно зробила обовʼязковою.
6. Loopback processing у Replace. Користувацькі політики замінюються тими, що звʼязані з OU комп'ютера. Якщо їх там нема, нічого не застосується.
7. Slow link detection. Користувач підключений по VPN з мобільного хотспоту, канал менший за 500 Кбіт/с, тож Folder Redirection і Software Installation пропускаються тихо.

Якщо ви робите міграцію на Windows 11 у корпоративному середовищі, раджу паралельно глянути наш матеріал про усунення проблем оновлень Windows 11, там багато перетину з GPO для оновлень WUfB.

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

Перше, що я запускаю на машині користувача, це gpresult. Не gpupdate, не Event Viewer, а саме gpresult. Він читає WMI-провайдер RSoP (Resultant Set of Policy) і показує, що насправді склалося на клієнті, з повним поясненням, чому конкретна GPO відфільтрована.

# Запустіть від адміністратора у консолі користувача:
# /h згенерує HTML-звіт; /scope обираємо ділянку (computer чи user).
gpresult /h C:\Temp\gp_report.html /f

# Швидкий текстовий summary без HTML:
gpresult /r /scope:computer
gpresult /r /scope:user

# Якщо звіт потрібен для іншого користувача (напр., при шейр-сесії):
gpresult /h C:\Temp\gp_user.html /user DOMAIN\jdoe /f

У HTML-звіті дивіться розділ Denied GPOs. Поряд з кожним обʼєктом буде причина: Empty, Filtering: Denied (Security), Filtering: Denied (WMI Filter), Disabled Link. Це економить години догадок. У 8 з 10 кейсів причина видно одразу.

RSoP-консоль для глибокого аналізу

Для офлайн-аналізу планування політик (наприклад «що буде, якщо я перенесу юзера в іншу OU») у складі RSAT досі живе rsop.msc і Planning Mode у GPMC. Так, вони архаїчні, але працюють. У 2026 Microsoft нарешті додала Modern RSoP у Intune Admin Center для гібридних сценаріїв, але для чистого AD класична консоль швидша.

Як правильно форсити gpupdate /force

Найпоширеніша помилка tier-1: запустили gpupdate /force, побачили User Policy update has completed successfully, пішли пити каву і думають, що все застосувалось. Не застосувалось. Багато категорій політик (Folder Redirection, Software Installation, Drive Maps під час логону, скрипти Startup/Logon) потребують логауту користувача або ребуту машини. gpupdate їх просто пропустить з логом The Group Policy CSE will be invoked at the next logon.

# Правильний синтаксис із автоматичним логаутом юзера:
gpupdate /target:user /force /logoff

# Правильний синтаксис з автоматичним ребутом машини (Computer Configuration):
gpupdate /target:computer /force /boot

# Обидва одразу, без додаткових питань:
gpupdate /force /boot

# Із PowerShell для віддаленої машини (RSAT):
Invoke-GPUpdate -Computer "WS-IT-042" -Target "Computer" -Force -RandomDelayInMinutes 0

Параметр /sync у Windows 11 теж робить корисну річ: він примушує наступне застосування політики бути синхронним, тобто без foreground/background обходу. У сесіях з RDP це часто рятує від випадків, коли drive map не зʼявляється до першого логауту.

Події 1058 і 1030: що з SYSVOL не так

Якщо ви бачите у журналі Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational події 1058 (The processing of Group Policy failed. Windows attempted to read the file...) і 1030 (The processing of Group Policy failed. Windows could not obtain the name of a domain controller), у 99% випадків причина у SYSVOL. Або клієнт не дотягується по SMB, або DFS Namespace для \\domain.local\SYSVOL віддає мертвий referral, або сам файл gpt.ini побитий.

Алгоритм перевірки на DC:

# 1. Перевірте, що SYSVOL змонтований і реплікується (DFSR):
dcdiag /test:sysvolcheck /test:netlogons /v

# 2. Подивіться backlog DFSR (повинен бути 0 або мінімальний):
dfsrdiag Backlog /RGName:"Domain System Volume" /RFName:SYSVOL Share `
    /SMem:DC01 /RMem:DC02

# 3. Перевірте, чи файл gpt.ini читається через SMB:
Test-Path "\\domain.local\SYSVOL\domain.local\Policies\{GUID}\gpt.ini"
Get-Content "\\domain.local\SYSVOL\domain.local\Policies\{GUID}\gpt.ini"

Якщо dcdiag бачить SYSVOL not shared, це симптом застряглого DFSR initial sync. На MS-форумах за останні два роки накопичилася гора case-ів, де лікується це примусовим non-authoritative sync через виставлення msDFSR-Enabled=FALSE на DC, що відстав, з наступним перезапуском DFSR. Деталі є у офіційному гайді Microsoft Learn щодо authoritative DFSR sync.

Якщо у вас уже виникала схожа симптоматика з реплікацією, перечитайте наш повний посібник з діагностики Active Directory, там детально розписано repadmin /showrepl та інші діагностичні команди.

Security filtering, WMI-фільтри та delegation

З 2016 року, коли Microsoft випустила MS16-072, security filtering на групах перестав «просто працювати». Тепер кожна GPO має мати дозвіл Read для групи Domain Computers або Authenticated Users на рівні delegation, інакше клієнт банально не зможе прочитати обʼєкт у LDAP. Це досі ламає налаштування у компаній, що мігрують з Windows Server 2012. Я особисто хапав цю граблю двічі за 2025 рік.

Як перевірити правильно

1. У GPMC відкрийте GPO, перейдіть на закладку Delegation → Advanced.
2. Переконайтесь, що Authenticated Users має Read (без Apply Group Policy, і це нормально).
3. Якщо ви замінили Authenticated Users на конкретну групу (наприклад SG-Marketing-Workstations), додайте Domain Computers з правом Read.

Для WMI-фільтрів є окрема пастка у 2026: запит SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0%" матчить і Windows 10, і Windows 11, бо обидві системи декларують себе як 10.0. Якщо ви хочете обмежити фільтр тільки Windows 11, використовуйте BuildNumber.

-- WMI-фільтр для Windows 11 22H2 і новіших (build 22621+):
SELECT BuildNumber FROM Win32_OperatingSystem
WHERE BuildNumber >= "22621"

-- Тільки Windows 11 24H2 (build 26100):
SELECT BuildNumber FROM Win32_OperatingSystem
WHERE BuildNumber = "26100"

-- Виключно Enterprise/Education SKU:
SELECT * FROM Win32_OperatingSystem
WHERE OperatingSystemSKU = 4 OR OperatingSystemSKU = 121

Перевірити, який Build видасть машина, можна командою (Get-CimInstance Win32_OperatingSystem).BuildNumber. Якщо WMI-репозиторій корумпований, машина просто не пройде жоден фільтр. Лікується winmgmt /verifyrepository з подальшим winmgmt /salvagerepository.

Loopback processing і Folder Redirection

Loopback processing це механізм, коли user-side політики GPO застосовуються на основі OU комп'ютера, а не OU користувача. Класичний сценарій: термінальний сервер, де треба підмінити Start Menu й заблокувати Control Panel незалежно від того, який юзер логіниться. Налаштування знаходиться у Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode.

Є два режими:

• Merge: спершу застосовуються «нормальні» політики юзера, потім зверху накладаються політики, звʼязані з OU компʼютера. У разі конфлікту виграє той, що з OU компʼютера.
• Replace: політики, звʼязані з OU користувача, ігноруються повністю. Застосовуються тільки ті, що з OU компʼютера.

У 95% реальних кейсів вам потрібен Merge. Replace має сенс лише на кіосках і термінальних серверах, де користувач не має нічого «свого». Помилка номер один: увімкнути Replace на ноутбуках віддалених працівників, після чого зникає Drive Map, Folder Redirection і Outlook profile. Потім сервіс-деск ловить тікети тиждень. Сам цю помилку зробив у 2018 на пілотному впровадженні, з того часу беру за правило двічі перепитати при включенні Replace.

ADMX-шаблони та Central Store у 2026

Якщо у вашому домені досі немає Central Store для ADMX-шаблонів, ви живете у 2008 році. Без Central Store GPMC показує тільки шаблони, фізично присутні на машині адміністратора, що породжує парадокси «у мене ця політика є, у колеги нема». Створюється сховище за пʼять хвилин.

# На контролері домену з-під адміністратора:
# 1. Створіть PolicyDefinitions у SYSVOL:
$dest = "\\domain.local\SYSVOL\domain.local\Policies\PolicyDefinitions"
New-Item -ItemType Directory -Path $dest -Force

# 2. Скопіюйте поточні ADMX з локальної машини:
Copy-Item "C:\Windows\PolicyDefinitions\*" -Destination $dest -Recurse -Force

# 3. Завантажте оновлений пакет Windows 11 24H2 Administrative Templates
#    з Microsoft Download Center і розпакуйте у Central Store:
# https://www.microsoft.com/download (шукайте "Administrative Templates 24H2")

У 2026 актуальні версії, які варто мати у Central Store:

• Windows 11 24H2: base ADMX, найновіші параметри безпеки.
• Microsoft Edge 130+: окремий пакет, оновлюється раз на 4 тижні. Без свіжих ADMX не побачите параметрів для нових AI-фічей.
• Microsoft 365 Apps: окремий пакет, єдине джерело Office GPO (стара назва, Office Administrative Templates).
• OneDrive: окремі ADMX, з'являються лише у нових збірках. Для KFM (Known Folder Move) обовʼязково.

Свіжі релізи Microsoft публікує на сторінці Windows 11 group policy management на Microsoft Learn. Туди вшито посилання на актуальні Administrative Templates ZIP-файли по версіях.

PowerShell-скрипт для масового аудиту GPO

Коли ви успадковуєте «зрілий» AD з 400+ обʼєктами GPO, перше завдання це побачити, що з цього взагалі активне. Я тримаю ось такий скрипт у репозиторії сервіс-деску. Він видає CSV з усіма GPO, їхніми лінками, security filtering і часом останньої модифікації. Tier-1 запускає його щомісяця, щоб ловити політики-сироти.

# Потрібен RSAT: Install-WindowsFeature -Name RSAT-AD-PowerShell, GPMC
Import-Module GroupPolicy
Import-Module ActiveDirectory

# Збираємо всі GPO у домені:
$gpos = Get-GPO -All

$report = foreach ($gpo in $gpos) {
    # Дістаємо XML-репорт для аналізу лінків:
    [xml]$xml = Get-GPOReport -Guid $gpo.Id -ReportType Xml

    # Шукаємо, до яких SOM (Scope of Management) злінкована політика:
    $links = $xml.GPO.LinksTo | ForEach-Object { $_.SOMPath }

    # Security filtering — хто має Apply Group Policy:
    $secFilter = (Get-GPPermissions -Guid $gpo.Id -All |
        Where-Object { $_.Permission -eq 'GpoApply' }).Trustee.Name -join ';'

    [PSCustomObject]@{
        Name             = $gpo.DisplayName
        Id               = $gpo.Id
        CreationTime     = $gpo.CreationTime
        ModificationTime = $gpo.ModificationTime
        LinkedTo         = ($links -join ' | ')
        IsLinked         = [bool]$links
        SecurityFilter   = $secFilter
        WmiFilter        = $gpo.WmiFilter.Name
        UserVersion      = $gpo.User.DSVersion
        ComputerVersion  = $gpo.Computer.DSVersion
    }
}

# Експорт у CSV для аналізу в Excel:
$report | Export-Csv -Path "C:\Temp\GPO_Audit_$(Get-Date -Format yyyyMMdd).csv" `
    -NoTypeInformation -Encoding UTF8

# Швидкий summary у консоль — політики-сироти без жодного лінка:
$report | Where-Object { -not $_.IsLinked } |
    Select-Object Name, ModificationTime | Format-Table -AutoSize

Експортований CSV відкривається в Excel за секунди. Сортуєте по IsLinked = False і отримуєте перелік сиріт, які зазвичай тягнуться з 2015 року «бо раптом знадобиться». Бекапіть через Backup-GPO і видаляйте. Менше обʼєктів означає швидший logon, особливо на повільних каналах.

Часті запитання

Чому Group Policy не застосовується після gpupdate /force?

Частина CSE (client-side extensions), а саме Folder Redirection, Software Installation, Logon Scripts, застосовуються тільки під час логону або старту компʼютера. gpupdate /force їх пропустить. Використовуйте gpupdate /force /logoff для політик користувача або /boot для політик машини.

Як перевірити, які GPO застосовані на компʼютері?

Запустіть gpresult /h C:\Temp\gp.html /f з-під адміністратора у консолі цільового користувача. Відкрийте HTML: у розділі Applied GPOs побачите ті, що спрацювали, у Denied GPOs відфільтровані з зазначенням причини (security, WMI, link disabled).

Що означають події 1058 і 1030 у журналі Group Policy?

1058 означає, що клієнт не зміг прочитати файл gpt.ini з SYSVOL. 1030 означає, що клієнт не зміг знайти контролер домену для застосування GPO. Обидві майже завжди вказують на проблему з SMB-доступом до SYSVOL, DFS-N referral або реплікацією DFSR.

Яка різниця між gpupdate і gpupdate /force?

Звичайний gpupdate застосовує тільки ті політики, що змінилися з минулого циклу (за відмітками версії). /force повторно застосовує абсолютно всі політики, навіть якщо вони не мінялися. Корисно під час траблшутингу, але не запускайте на проді на всіх машинах одночасно, бо створює навантаження на DC.

Як виправити WMI-фільтр, що не матчиться на Windows 11 24H2?

У 24H2 BuildNumber змінився на 26100. Якщо ваш фільтр використовує Version LIKE "10.0%", він буде матчити, але це некоректно. Перепишіть на SELECT BuildNumber FROM Win32_OperatingSystem WHERE BuildNumber >= "22621" для всіх Windows 11, або порівнюйте на конкретне значення BuildNumber для точного релізу.