Falha WMI ao editar RAP no Remote Desktop Gateway (Windows Server 2022): causas, diagnóstico e correções

Ao editar as Resource Authorization Policies (RAP) no Remote Desktop Gateway no Windows Server 2022, surge o erro “Unable to Update Resource Access Policy” relacionado ao WMI. Este guia explica as causas reais, mostra como corrigi-las com segurança e oferece um roteiro prático para evitar recorrências.

Índice

Visão geral do problema

Em ambientes com Serviços de Área de Trabalho Remota (RDS) ativados pelo modo Quick Start e a função Remote Desktop Gateway (RD Gateway) habilitada, alguns administradores encontram uma falha ao tentar alterar uma RAP. A mensagem geralmente é apresentada no RD Gateway Manager e faz referência a WMI (Windows Management Instrumentation). O resultado prático é a impossibilidade de criar, editar ou guardar alterações na política.

O RD Gateway utiliza WMI e chamadas COM/DCOM para ler e gravar a configuração local. Se o subsistema WMI encontra restrições de ambiente (por exemplo, variáveis TEMP/TMP redirecionadas) ou inconsistências de objetos referenciados na política, a operação de atualização falha — mesmo quando todos os serviços RDS parecem operacionais.

Ambiente típico afetado

Windows Server 2022 Datacenter (virtualizado em Hyper‑V ou plataforma similar).
RDS instalado via Quick Start (collection de sessão única, autenticação padrão).
Função Remote Desktop Gateway instalada no mesmo host.
Administração feita localmente via RD Gateway Manager (tsgateway.msc).

Como o WMI e o RD Gateway interagem

Para persistir a configuração, o RD Gateway aciona componentes que dependem de WMI, a qual, por sua vez, cria e lê ficheiros temporários e carrega providers a partir de diretórios do sistema. A pasta C:\Windows\Temp é um local crítico. Quando variáveis de ambiente do sistema (TEMP/TMP) são alteradas para outro volume, ou quando permissões nessa pasta se tornam restritivas para as contas internas (SYSTEM e NETWORK SERVICE), o pipeline WMI/COM fica instável e a gravação da RAP falha.

Outro fator frequente é a “higiene” da própria RAP: se a sua lista de “recursos de destino” contém nomes de computadores que já não existem no Active Directory ou não são resolvíveis via DNS, o processo de validação interna devolve erro.

Causas conhecidas e soluções comprovadas

#	Causa	Solução resumida	Observações práticas
1	Variável de ambiente TEMP redirecionada O RD Gateway necessita de acesso a `C:\Windows\Temp` para operações internas via WMI. Alterar TEMP/TMP para outro volume (ex.: `S:\Temp`) faz a chamada WMI falhar.	Restaurar TEMP/TMP para o valor padrão `C:\Windows\Temp` (Sistema e Utilizador), reiniciar os serviços RDS ou o servidor.	Ajustar permissões da pasta para incluir `SYSTEM` e `NETWORK SERVICE` com controlo total, se necessário.
2	Entradas de computadores obsoletos na lista de recursos das RAPs. O Gateway verifica cada nome; se o objeto computador não existir mais no AD ou DNS, a chamada WMI devolve erro.	Remover máquinas desativadas/descartadas da lista antes de guardar a RAP.	Útil quando a pasta TEMP já está correta e o erro persiste.
3	Problemas genéricos no subsistema WMI (serviço parado, repositório corrompido, namespace com permissões incorretas).	Confirmar que o serviço Windows Management Instrumentation e dependências estão em execução. Consultar logs em Applications and Services Logs → Microsoft → Windows → WMI‑Activity. Executar a WMI Diagnosis Utility para obter relatório e instruções de correção.	Evite recriar o repositório WMI como primeira medida; pode danificar componentes RDS e outros serviços.

Procedimento recomendado

Abaixo, um roteiro passo a passo para restaurar a capacidade de editar as RAPs com segurança.

Verificar e padronizar variáveis TEMP e TMP

Valide os valores atuais (nível de Máquina e Utilizador) e normalize para C:\Windows\Temp. Em seguida, reinicie o RD Gateway ou o servidor.

# Verificar valores atuais
[Environment]::GetEnvironmentVariable("TEMP","Machine")
[Environment]::GetEnvironmentVariable("TMP","Machine")
[Environment]::GetEnvironmentVariable("TEMP","User")
[Environment]::GetEnvironmentVariable("TMP","User")

Definir TEMP/TMP no nível de Máquina

setx TEMP "C:\Windows\Temp" /M
setx TMP  "C:\Windows\Temp" /M

(Opcional) Definir também no nível de Utilizador atual

setx TEMP "C:\Windows\Temp"
setx TMP  "C:\Windows\Temp"

Em seguida, confirme as permissões NTFS da pasta TEMP:

# Ver ACLs efetivas
icacls C:\Windows\Temp

Ajustar para incluir SYSTEM e NETWORK SERVICE com controlo total

icacls C:\Windows\Temp /grant SYSTEM:(OI)(CI)(F) "NT AUTHORITY\NETWORK SERVICE":(OI)(CI)(F)

Reinicie os serviços relevantes:

# Reiniciar o RD Gateway e WMI com atenção às dependências
Restart-Service -Name TSGateway -Force
Restart-Service -Name Winmgmt -Force

(Se necessário) Reiniciar serviços RDS adicionais

Restart-Service -Name TermService -Force

Nota: se políticas de grupo (GPO) definem TEMP/TMP, ajuste-as na origem e force a atualização com gpupdate /force.

Higienizar recursos inexistentes nas RAPs

No RD Gateway Manager, abra Resource Authorization Policies, edite a RAP problemática e remova todos os nomes de computadores que não resolvem. Antes de gravar, valide cada entrada:

# Testar resolução DNS e conectividade ICMP
$targets = @("SRV-APP01","SRV-DB02","PC-USUARIO-ANTIGO")  # substitua pelos seus
foreach ($t in $targets) {
  try {
    $res = Resolve-DnsName -Name $t -ErrorAction Stop
    Write-Host "OK DNS → $t → $($res.IPAddress)"
  } catch {
    Write-Warning "FALHA DNS → $t (remover ou corrigir)"
  }
  Test-Connection -ComputerName $t -Count 1 -Quiet | ForEach-Object {
    if ($_){ Write-Host "Ping OK → $t" } else { Write-Warning "Ping falhou → $t"}
  }
}

Em domínios AD, pode confirmar a existência do objeto de computador (se tiver os módulos RSAT):

# Requer RSAT-AD-PowerShell
Get-ADComputer -Identity "SRV-APP01" -ErrorAction Stop

Após limpar a lista, tente salvar novamente a RAP.

Checar estado do serviço WMI e logs

Confirme que o serviço está ativo e verifique os registos operacionais do WMI‑Activity e de DCOM.

# Estado do serviço WMI
Get-Service -Name Winmgmt

Últimos erros do WMI-Activity (Operational)

Get-WinEvent -LogName "Microsoft-Windows-WMI-Activity/Operational" -MaxEvents 25 |
Select-Object TimeCreated, Id, LevelDisplayName, Message

Eventos DCOM comuns

Get-WinEvent -LogName "System" -MaxEvents 200 |
Where-Object { $.ProviderName -like "DistributedCOM" -and ($.Id -in 10009,10010) } |
Select-Object TimeCreated, Id, Message

Se o log indicar falhas de provider ou namespace inválido, analise o detalhe da mensagem antes de considerar medidas destrutivas no repositório WMI.

Usar a WMI Diagnosis Utility como último recurso inicial

Quando as etapas anteriores não resolvem, a WMI Diagnosis Utility fornece um relatório abrangente sugerindo correções para permissões, registo e inconsistências. Execute-a com privilégios elevados e siga as recomendações específicas. Evite “resetar” o repositório WMI sem um plano de reversão.

Fluxo de diagnóstico sugerido

Confirmar TEMP/TMP em Máquina e Utilizador, e ACLs de C:\Windows\Temp.
Reiniciar serviços TSGateway e Winmgmt.
Validar cada recurso listado na RAP (DNS/AD/alcance de rede).
Inspecionar logs WMI‑Activity e DCOM à procura de IDs 5858, 5857, 10009, 10010.
Executar WMI Diagnosis Utility e aplicar correções pontuais.
Evitar reconstruir WMI sem backup e janela de manutenção.

Mapa rápido de eventos úteis

Origem/Log	ID	Indicação típica	Ação recomendada
WMI‑Activity (Operational)	5858	Erro em chamada de método/consulta WMI	Ver TEMP/TMP e permissões; analisar mensagem completa para provider envolvido
WMI‑Activity (Operational)	5857	Acesso negado ou namespace inválido	Rever ACLs de WMI e grupos de administradores
DistributedCOM (System)	10010	Servidor COM não respondeu em tempo útil	Reiniciar serviços afetados; verificar dependências
DistributedCOM (System)	10009	Não foi possível comunicar com o computador alvo	Validar DNS/firewall; remover recursos obsoletos

Boas práticas antes de alterar RAPs

Exportar políticas: faça backup de CAPs e RAPs antes de alterações extensas, permitindo reversão rápida.
Janela de manutenção: agende mudanças fora do horário crítico para reduzir impacto.
Monitorização: crie alertas para os eventos 10010 (DCOM) e 5858 (WMI‑Activity) para detetar regressões.
Antivírus/EDR: garanta que não há bloqueio a operaçõs do WMI ou ao acesso à pasta C:\Windows\Temp pelo NETWORK SERVICE.
Documentação interna: registe a razão e a data de qualquer redirecionamento de TEMP/TMP.

Dicas adicionais específicas para GPO

Se a sua organização aplica o redirecionamento de TEMP/TMP por GPO (para discos dedicados ou perfis de utilizador), alinhe o design com estas regras:

Mantenha o nível Machine em C:\Windows\Temp para preservar a operação de serviços do sistema.
Se necessário, use um local alternativo apenas para TEMP/TMP de User, sem afetar contas de serviço.
Valide o resultado efetivo com set em cmd ou os cmdlets mostrados acima, e aplique gpupdate /force após mudanças.

Checklist de validação pós‑correção

Consegue abrir a RAP, adicionar/remover um recurso e guardar sem erros.
icacls C:\Windows\Temp mostra SYSTEM e NETWORK SERVICE com permissões de controlo total.
Get-Service Winmgmt e Get-Service TSGateway retornam Running.
Logs WMI‑Activity sem novos erros nas últimas tentativas.
Todas as entradas da RAP resolvem em DNS/AD e respondem a Test-Connection (ou estão documentadamente offline).

Automatização segura (exemplo de script)

Use o script abaixo (executado como Administrador) para auditar e corrigir o ambiente de forma idempotente.

$ErrorActionPreference = "Stop"

function Ensure-TempDefaults {
param([string]$Path = "C:\Windows\Temp")

$machineTemp = [Environment]::GetEnvironmentVariable("TEMP","Machine")
$machineTmp  = [Environment]::GetEnvironmentVariable("TMP","Machine")

if ($machineTemp -ne $Path) { setx TEMP $Path /M | Out-Null }
if ($machineTmp  -ne $Path) { setx TMP  $Path /M | Out-Null }

Garantir ACLs básicas

icacls $Path /grant SYSTEM:(OI)(CI)(F) "NT AUTHORITY\NETWORK SERVICE":(OI)(CI)(F) | Out-Null
}

function Restart-CoreServices {
$services = "TSGateway","Winmgmt"
foreach ($s in $services) {
if (Get-Service -Name $s -ErrorAction SilentlyContinue) {
Restart-Service -Name $s -Force
}
}
}

Write-Host "→ Verificando TEMP/TMP do sistema..." -ForegroundColor Cyan
Ensure-TempDefaults

Write-Host "→ Reiniciando serviços principais..." -ForegroundColor Cyan
Restart-CoreServices

Write-Host "→ Coletando últimos eventos WMI/DCOM..." -ForegroundColor Cyan
$wmi = Get-WinEvent -LogName "Microsoft-Windows-WMI-Activity/Operational" -MaxEvents 10 |
Select TimeCreated, Id, Message
$dcom = Get-WinEvent -LogName "System" -MaxEvents 200 |
Where-Object { $.ProviderName -like "DistributedCOM" -and ($.Id -in 10009,10010) } |
Select TimeCreated, Id, Message

$wmi
$dcom

Write-Host "Concluído. Tente editar a RAP novamente." -ForegroundColor Green

Perguntas frequentes

Alterar TEMP/TMP do sistema é sempre um problema?
Não necessariamente, mas mover TEMP/TMP do nível de Machine para outro volume costuma quebrar componentes que assumem C:\Windows\Temp, como WMI e alguns serviços de sistema. Mantenha o padrão no nível de Máquina.

Posso apenas recriar o repositório WMI para resolver de vez?
Não recomendado como primeira ação. O reset do WMI pode causar efeitos colaterais em RDS, Hyper‑V e outros papéis do Windows. Priorize correções de ambiente (TEMP/TMP, permissões, validação de recursos) e use a ferramenta de diagnóstico para orientações específicas.

Entradas antigas na RAP realmente impedem a gravação?
Sim. A validação processa cada alvo. Se um recurso já não existe ou não resolve, o fluxo pode falhar, e o RD Gateway aborta a atualização.

Que permissões são necessárias em C:\Windows\Temp?
Além das predefinidas, garanta SYSTEM e NETWORK SERVICE com controlo total herdado (OI/CI). Evite remover entradas padrão ou aplicar negações explícitas.

Como diferenciar problema de WMI vs. DCOM?
Erros 585x no WMI‑Activity apontam para WMI. Eventos 10009/10010 de DistributedCOM indicam problemas em chamadas COM/DCOM (tempo de resposta, comunicação, registo). Muitas vezes coexistem quando TEMP/TMP ou permissões estão incorretas.

Prevenção e governança

Política de TEMP/TMP corporativa: defina que o nível de Máquina permanece em C:\Windows\Temp. Use local alternativo apenas para perfis de utilizador, se necessário.
Auditoria trimestral: varrer RAPs à procura de recursos que não resolvem e removê‑los.
Baselines de segurança: após aplicar hardening, revalidar WMI e RD Gateway (testes de leitura/escrita de RAP).
Monitorização de eventos: configure alertas para 5858 (WMI‑Activity) e 10010 (DCOM) com detalhe da mensagem anexada.

Resumo operacional

Na maioria dos casos, restaurar TEMP/TMP do sistema para C:\Windows\Temp, ajustar permissões NTFS e limpar recursos obsoletos nas RAPs resolve de imediato o erro “Unable to Update Resource Access Policy”. Quando necessário, a análise de logs WMI/DCOM aponta o componente exato em falha. Seguindo o procedimento proposto, os administradores evitam medidas invasivas como a reinstalação do RD Gateway ou a reconstrução do repositório WMI.

Conteúdo de referência rápida

Comandos principais:
- setx TEMP "C:\Windows\Temp" /M, setx TMP "C:\Windows\Temp" /M
- icacls C:\Windows\Temp /grant SYSTEM:(OI)(CI)(F) "NT AUTHORITY\NETWORK SERVICE":(OI)(CI)(F)
- Restart-Service TSGateway, Restart-Service Winmgmt
- Resolve-DnsName, Test-Connection para validar alvos da RAP
- Get-WinEvent para WMI‑Activity e DistributedCOM
Locais de log:
- Applications and Services Logs → Microsoft → Windows → WMI‑Activity → Operational
- Windows Logs → System → DistributedCOM
Não recomendado:
- Redefinir WMI sem diagnóstico prévio e backup.
- Aplicar ACLs restritivas a C:\Windows\Temp sem validar serviços dependentes.

Conclusão

Erros de WMI ao editar RAP no RD Gateway são sintoma, não causa. O ajuste de variáveis TEMP/TMP ao padrão, a correção de permissões em C:\Windows\Temp, a eliminação de recursos inválidos e a verificação guiada pelos logs resolvem a maioria dos cenários. Com práticas de prevenção simples — auditorias de RAP e monitorização de eventos — a plataforma permanece estável e previsível.