GPO Não Aplica no Windows 11: Guia Completo de Troubleshooting para Helpdesk em 2026

Atualizado: 21 de julho de 2026

Quando uma GPO não aplica no Windows 11, o primeiro passo é rodar gpresult /r como Administrador para descobrir se a política foi de fato entregue, filtrada por segurança, bloqueada por um filtro WMI ou nem sequer alcançou o objeto por causa da OU errada. Este guia é o playbook que uso na minha operação para eliminar as sete causas mais comuns de GPO não aplica no Windows 11 em ambientes híbridos com Active Directory e Intune, sem chutar e sem reiniciar o cliente três vezes por precaução.

• Começe sempre por gpresult /r /scope:computer e gpresult /r /scope:user. 80% dos chamados morrem aqui.
• Filtros WMI escritos para Windows 10 (versão 10.0.19%) não casam com Windows 11 (build 10.0.22xxx ou 10.0.26xxx) e silenciosamente negam a GPO.
• Em dispositivos co-gerenciados com Intune, o padrão é GPO ganhar; o CSP MDMWinsOverGP inverte isso apenas para políticas do Policy CSP.
• O log Microsoft-Windows-GroupPolicy/Operational tem os eventos 7017, 7320 e 7013 que apontam a causa exata quando o gpresult é ambíguo.
• O serviço gpsvc parado ou em falha impede todo processamento de GPO e não é raro após updates cumulativos.
• DFS-N desabilitado no cliente quebra o acesso a SYSVOL e faz a GPO parecer que sumiu.

Diagnóstico rápido: dominando o gpresult

O gpresult.exe é a primeira ferramenta a ser aberta no cliente afetado, ponto final. Ele lê o cache local de política (Resultant Set of Policy, RSoP) e devolve exatamente quais GPOs foram aplicadas, quais foram negadas e o motivo da negação. Sem essa informação, qualquer palpite sobre "por que a GPO não aplica no Windows 11" é loteria. E, sim, você precisa rodar como Administrador; sem privilégio elevado, o escopo computer retorna ERROR: Access Denied e o técnico de tier-1 fica olhando para o console sem entender.

Na minha operação, o técnico digita três comandos, nesta ordem:

# 1) Resumo consolidado (usuário + computador); leia primeiro
gpresult /r

# 2) Isole a metade que está falhando
gpresult /r /scope:computer
gpresult /r /scope:user

# 3) Relatório HTML com detalhamento por GPO, filtro e configuração
gpresult /h C:\Temp\rsop.html /f

O relatório HTML é o entregável que anexo em todo chamado escalado. Ele mostra, por GPO, quais configurações venceram, qual OU vinculou a política, qual filtro WMI foi avaliado e (o que muita gente ignora) a hora do último processamento e o DC que respondeu. Se o campo Last time Group Policy was applied tem mais de duas horas, você já tem uma pista de conectividade antes mesmo de olhar o resto.

Duas armadilhas do gpresult que continuam pegando gente em 2026: configurações de Preferences (GPP) não aparecem no /r resumido; use /z para vê-las; e configurações aplicadas por Security Filtering em um grupo do qual o usuário virou membro agora não vão constar até um logoff/logon completo, porque o token Kerberos ainda carrega a associação antiga. Antes de escalar, faça um klist purge seguido de logoff.

Escopo, OU, herança e Enforce

A causa número um de GPO que "sumiu" continua sendo escopo. Antes de qualquer outra coisa, confirme três fatos independentes: (1) em qual OU o objeto (computador ou usuário) está de verdade agora; (2) em qual OU a GPO está vinculada; (3) se há Block Inheritance em alguma OU intermediária. O GPMC (gpmc.msc) mostra tudo isso na aba Scope da GPO. Se o objeto foi movido entre OUs, o cliente só percebe isso após um reboot completo (não basta gpupdate /force) porque a associação com a OU é resolvida no boot para o escopo de computador e no logon para o escopo de usuário.

Uma checklist rápida que dou aos técnicos: um Get-ADComputer <nome> -Properties DistinguishedName no lado do DC prova a OU real do objeto; um Get-GPInheritance -Target "OU=..." mostra herança bloqueada; e um Get-GPO -All | Where-Object { $_.DisplayName -match "..." } confirma que a GPO existe com o nome que o usuário jurou ter visto. Se GpoInheritanceBlocked vier True, suas GPOs de segurança do domínio não descem até aquela OU, a menos que estejam com Enforced marcado, o que ignora o bloqueio.

Não confunda escopo com aplicação. Uma configuração dentro de Computer Configuration só se aplica se a GPO estiver vinculada a uma OU que contenha objetos de computador; uma configuração dentro de User Configuration exige OU com objetos de usuário. Vejo semanalmente helpdesk vinculando GPO com configuração de computador a OU de usuários e depois abrindo ticket para o time de infraestrutura. Isole executando gpresult /r /scope computer e /scope user separadamente: se uma metade está limpa e a outra vazia, o problema é escopo, não filtragem.

Filtragem de Segurança e permissões Read/Apply

A aba Delegation da GPO define quem tem Read e Apply group policy. Sem essas duas permissões conjuntas, o cliente lê a GPO mas não a executa, e ela aparece como Denied (Security) no gpresult. Por padrão, Authenticated Users tem ambas, o que resolve a maioria dos casos. O problema começa quando alguém remove Authenticated Users para "restringir" a GPO a um grupo específico e esquece que o computador também precisa ter permissão de leitura para carregar o CSE (Client-Side Extension).

Desde o KB3163622 (2016, sim, ainda relevante em 2026 porque o comportamento nunca foi revertido), o cliente processa a GPO no contexto da máquina, não do usuário, mesmo para configurações de usuário. Se você trocou Authenticated Users por um grupo de usuários, os computadores param de conseguir ler a GPO e ela some silenciosamente. A correção é adicionar Domain Computers (ou Authenticated Users) com permissão de leitura, e deixar a filtragem de segurança específica só com Apply. Este comportamento está documentado no guia de troubleshooting de Group Policy do Microsoft Learn e é o principal motivo pelo qual GPOs "funcionavam ontem" e param depois de uma revisão de segurança.

Para inspecionar rapidamente as permissões via PowerShell:

# Lista permissões da GPO. Procure por "Apply Group Policy" e "Read"
# para os principals corretos (Authenticated Users, grupo alvo, Domain Computers)
Get-GPPermission -Name "GPO-Politicas-Seguranca" -All |
  Select-Object Trustee, Permission, Inherited |
  Format-Table -AutoSize

Filtros WMI e a armadilha do Windows 11

Filtros WMI são elegantes no papel e catastróficos na prática quando alguém escreve uma query para "Windows 10 apenas" e esquece de revisar depois de uma migração. Um filtro clássico como Select * from Win32_OperatingSystem Where Version LIKE "10.0.19%" parece razoável (casa com builds 19041 a 19045 do Windows 10). Só que o Windows 11 é internamente 10.0.22000, 10.0.22621, 10.0.22631 e, a partir do 24H2, 10.0.26100. Nenhuma dessas versões começa com 10.0.19. Resultado: a GPO é Denied (WMI Filter) em todo Windows 11 do parque.

Antes de acusar a rede ou o DC, valide a query no próprio cliente:

# Reproduz exatamente a avaliação que o cliente faz no processamento de GPO
# Se retornar objeto, a GPO se aplica; se retornar vazio, é filtrada
Get-CimInstance -Query 'Select * from Win32_OperatingSystem Where Version LIKE "10.0.19%"'

# Query correta para casar Windows 10 e Windows 11 simultaneamente
Get-CimInstance -Query 'Select * from Win32_OperatingSystem Where ProductType = 1'

# Ou explicite Windows 11: build major 22000+
Get-CimInstance -Query 'Select * from Win32_OperatingSystem Where BuildNumber >= "22000"'

Serviço gpsvc, DFS-N e conectividade com o DC

Se o gpresult retorna The user does not have RSOP data ou gpupdate trava, o problema não é política, é infraestrutura. O serviço Group Policy Client (gpsvc) tem que estar rodando; após alguns updates cumulativos ele ficou marcado como Manual (Trigger Start) em builds do 24H2 e não subiu no boot em máquinas com hibernação agressiva. Confirme com Get-Service gpsvc. Se estiver Stopped, um Start-Service gpsvc resolve, mas trate a causa raiz nas configurações de energia.

Conectividade com o Domain Controller é a segunda camada. O cliente precisa resolver _ldap._tcp.dc._msdcs.<dominio> via DNS, autenticar via Kerberos e ler o \\<dominio>\SYSVOL via DFS Namespaces. Se o cliente DFS foi desabilitado (via GPO ancestral, ironicamente, ou por algum "endurecimento" de segurança), o caminho \\dominio\SYSVOL falha e nenhuma GPO baixa. Teste com:

# 1) DNS resolvendo os DCs do domínio
nltest /dsgetdc:seudominio.local

# 2) Canal seguro do computador com o domínio
Test-ComputerSecureChannel -Verbose

# 3) SYSVOL acessível. O cliente precisa listar Policies
Test-Path "\\seudominio.local\SYSVOL\seudominio.local\Policies"

# 4) DFS-N Client habilitado (deve retornar Start=2 automatic)
Get-Service Dfs* | Format-Table Name, Status, StartType

Em ambientes com VPN, a GPO só processa quando o túnel está aberto e o DC alcançável, o que na prática significa que usuários remotos sem Always On VPN podem ficar semanas sem receber política nova. Se esse é o cenário, revise o design do seu acesso remoto seguindo o mesmo raciocínio que apliquei no guia de troubleshooting de VPN corporativa no Windows 11: sem canal com o DC, não há Group Policy.

Event Viewer: eventos 7017, 7320 e 7013

Quando o gpresult mostra "denied" sem motivo claro, o log operacional de Group Policy é onde a verdade mora. Abra o Event Viewer e navegue até Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational. Cada ciclo de processamento gera uma cadeia de eventos com o mesmo ActivityID; filtre por esse ID para ver o ciclo completo, do começo (evento 4001) ao fim (evento 8001).

Os três eventos que resolvem a maioria dos chamados:

• Evento 7017: falha ao processar uma GPO específica. A mensagem inclui o GUID da GPO e um código de erro Win32; converta com net helpmsg <codigo> para linguagem humana.
• Evento 7320: filtragem de segurança bloqueou a aplicação. O SID do objeto e o SID exigido pela GPO estão no corpo do evento, o que permite comparar contra a associação real de grupos.
• Evento 7013: o cliente não conseguiu contatar o DC para ler os dados da GPO. É problema de rede, DNS ou canal seguro, não de política.

Combine o log com o System. Se você vê NETLOGON 5719 e W32Time 47 pouco antes dos eventos 7013, o cliente perdeu contato com o DC (ou o relógio drifting derrubou Kerberos). Kerberos tolera até 5 minutos de skew por padrão; máquinas em VMs com clock não sincronizado passam desse limite com facilidade.

Conflitos MDM/Intune e MDMWinsOverGP

No Windows 11 co-gerenciado com Intune, o mundo ficou mais complicado. Tanto GPO quanto o Policy CSP escrevem em ramos de registro semelhantes, muitas vezes HKLM\Software\Policies\... versus HKLM\Software\Microsoft\PolicyManager\current\.... Por padrão, GPO vence: o Group Policy CSE roda a cada 90 minutos e sobrescreve o valor entregue pelo MDM. Se sua política do Intune "some" horas depois da aplicação, é isso.

A partir do Windows 10 1803, existe o CSP ControlPolicyConflict/MDMWinsOverGP que inverte a precedência para políticas do Policy CSP. No Intune, você o configura em Devices → Configuration profiles → Settings Catalog → Control Policy Conflict → MDM Wins Over GP → "The MDM policy is used and the GP policy is blocked". Depois do sync (que pode levar 30+ minutos, mesmo forçado via Settings → Accounts → Access work or school → Sync), o Windows passa a preferir o MDM. Consulte a documentação oficial do Policy CSP ControlPolicyConflict para as ressalvas.

Ressalvas que você precisa gravar: MDMWinsOverGP vale apenas para políticas dentro do Policy CSP; não vale para Windows Update for Business, Defender, BitLocker e vários outros CSPs específicos. Nesses casos, se você tem GPO configurando Windows Update e uma configuração de Update Ring no Intune, a GPO ganha e o Update Ring silenciosamente vira decoração no console do Intune. A recomendação oficial da Microsoft, e a que eu sigo, é não configurar a mesma política em dois lugares. Escolha um plano de autoridade por área (identidade e updates no Intune, políticas legadas de aplicação no GPO, por exemplo) e desabilite o outro lado explicitamente.

Para investigar em campo se o Intune está "ganhando" ou "perdendo" de uma GPO, cruze a fonte no registro:

# Valor entregue por GPO (fonte legada)
Get-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\AU" -ErrorAction SilentlyContinue

# Valor entregue por MDM/Intune (Policy CSP)
Get-ItemProperty "HKLM:\Software\Microsoft\PolicyManager\current\device\Update" -ErrorAction SilentlyContinue

# Estado atual do MDMWinsOverGP
Get-ItemProperty "HKLM:\Software\Microsoft\PolicyManager\current\device\ControlPolicyConflict" -ErrorAction SilentlyContinue

Se você está gerenciando identidade em paralelo com AD local e Entra ID, revise o guia de troubleshooting de Active Directory e Entra ID antes de mexer em GPO em máquinas híbridas. Meia dúzia de sintomas que parecem "GPO não aplica" são, na verdade, sincronização quebrada do Entra Connect.

Script PowerShell de triagem para tier-1

Este é o script que rodo nos primeiros dois minutos de qualquer chamado de "minha política não aplicou". Ele é intencionalmente conservador (sem gpupdate /force automático, sem alterar registro) e comentado linha a linha para tier-1 acompanhar. Salve como Get-GPTriage.ps1 e execute como Administrador.

# =====================================================================
# Get-GPTriage.ps1: coleta o essencial para diagnosticar GPO no cliente
# Rodar como Administrador. Sem parâmetros: coleta tudo em C:\Temp\GP.
# =====================================================================

$Out = "C:\Temp\GP-$(Get-Date -Format yyyyMMdd-HHmmss)"
New-Item -ItemType Directory -Path $Out -Force | Out-Null

# 1) Serviço gpsvc: precisa estar Running e Automatic
Get-Service gpsvc |
  Format-List Name, Status, StartType |
  Out-File "$Out\01-gpsvc.txt"

# 2) Última vez que a GPO processou (ambos os escopos)
gpresult /r        | Out-File "$Out\02-gpresult-r.txt"
gpresult /r /scope:computer | Out-File "$Out\03-gpresult-computer.txt"
gpresult /r /scope:user     | Out-File "$Out\04-gpresult-user.txt"

# 3) Relatório HTML completo com filtros e configurações vencedoras
gpresult /h "$Out\05-rsop.html" /f

# 4) Canal seguro com o domínio. Sem isso, GPO nao baixa
Test-ComputerSecureChannel -Verbose *>&1 |
  Out-File "$Out\06-secure-channel.txt"

# 5) DC descoberto por DNS/Netlogon
nltest /dsgetdc:$env:USERDNSDOMAIN |
  Out-File "$Out\07-dsgetdc.txt"

# 6) SYSVOL acessivel? (falso = DFS ou permissao)
"SYSVOL reachable: $(Test-Path "\\$env:USERDNSDOMAIN\SYSVOL")" |
  Out-File "$Out\08-sysvol.txt"

# 7) Ultimos 100 eventos operacionais de Group Policy
Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" `
             -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Export-Csv "$Out\09-gp-events.csv" -NoTypeInformation -Encoding UTF8

# 8) Registro de precedencia MDM x GPO
Get-ItemProperty "HKLM:\Software\Microsoft\PolicyManager\current\device\ControlPolicyConflict" `
  -ErrorAction SilentlyContinue |
  Out-File "$Out\10-mdm-wins-over-gp.txt"

Write-Host "Triagem salva em: $Out"

O que fazer com o resultado: abra 05-rsop.html primeiro, pule para a seção Denied GPOs e leia o motivo. Se todos os denials são Security, o problema é filtragem/permissão. Se são WMI Filter, valide a query no cliente. Se o arquivo 02-gpresult-r.txt nem lista GPOs, olhe 06-secure-channel.txt e 08-sysvol.txt. O problema é infraestrutura. Se algo está aplicando errado em máquinas que estão travando com BSOD após reboot forçado por GPO, cruze com o guia de troubleshooting de tela azul no Windows 11 antes de reverter a política inteira.

Para times que querem ir além do gpresult, a Group Policy Management Console (GPMC) via RSAT ainda é a ferramenta oficial para o Group Policy Results Wizard, que roda o mesmo RSoP remotamente contra qualquer computador do domínio, sem precisar de acesso interativo à máquina do usuário. Combine com o script acima e você resolve 90% dos chamados no primeiro contato.

Perguntas frequentes

Por que a GPO aparece em gpresult mas não faz efeito no Windows 11?

Aparecer em Applied Group Policy Objects significa que a GPO foi baixada e o CSE correspondente rodou, mas uma configuração individual pode estar sendo sobrescrita por outra GPO com maior precedência (ordem de link, Enforced, Block Inheritance) ou pelo próprio MDM/Intune. Gere o relatório HTML com gpresult /h e vá até a configuração específica: o campo Winning GPO mostra qual política ganhou.

Qual a diferença entre gpupdate e gpupdate /force?

O gpupdate normal reprocessa apenas as GPOs que mudaram no DC desde o último ciclo, é rápido e é o que o cliente faz a cada 90 minutos. O gpupdate /force ignora o cache de versão e reaplica todas as GPOs, útil quando você suspeita que uma configuração local foi alterada e precisa ser revertida. Use com moderação em massa; força reprocessamento pesado de CSEs como Software Installation e Folder Redirection.

Como saber se um filtro WMI está bloqueando minha GPO?

No gpresult /h, GPOs bloqueadas por WMI aparecem em Denied GPOs com o motivo WMI Filter. Para reproduzir a avaliação, rode a query WMI diretamente no cliente com Get-CimInstance -Query '<sua-query>'. Se o resultado vier vazio, a GPO é negada. Filtros para Windows 10 que verificam Version LIKE "10.0.19%" nunca casam com Windows 11.

MDM ou GPO ganha em dispositivos co-gerenciados com Intune?

Por padrão, GPO ganha. Para inverter, habilite o CSP ControlPolicyConflict/MDMWinsOverGP via Intune, o que faz o MDM prevalecer para políticas do Policy CSP. Essa inversão não se aplica a Windows Update for Business, Defender ou BitLocker. Nesses CSPs, a GPO continua vencendo. A recomendação da Microsoft é não configurar a mesma política nos dois lados.

Preciso reiniciar o Windows 11 depois de gpupdate /force?

Depende do CSE. Configurações de Software Installation, Folder Redirection e algumas políticas de segurança (Rights Assignment, Audit Policy) pedem logoff ou reboot para tomar efeito completo. O próprio gpupdate avisa e pergunta se quer reiniciar (/boot) ou fazer logoff (/logoff). Para políticas de registro simples, o reboot é desnecessário.