Cómo diagnosticar y solucionar problemas de WMI filters en Group Policy

Problema

En entornos con Active Directory, los filtros WMI se usan para limitar la aplicación de un GPO a equipos que cumplen una condición. Cuando se elimina un filtro sin antes desvincularlo de los GPO que lo usan, esos GPO quedan con una referencia interna (gPCWQLFilter) que apunta a un objeto inexistente. El resultado típico es que la política aparece como “Denied” en gpresult o en el visor de eventos, con el mensaje “WMI filter”. El GPO sigue existiendo, pero nunca se aplica porque el motor de Group Policy interpreta la referencia faltante como una denegación implícita.

Este comportamiento no es exclusivo de un caso puntual; cualquier administrador que limpie filtros WMI de forma apresurada puede encontrarse con GPOs “fantasma” que dejan de funcionar sin una causa evidente en la consola de GPMC.

Causa

1. Eliminación directa del objeto WMI – Cuando se borra el contenedor WMI Filters en AD o se usa Remove-Item en PowerShell, el atributo gPCWQLFilter de los GPO que lo referenciaban no se actualiza automáticamente.
2. Falta de desasignación previa – La UI de GPMC permite “None” como valor, pero solo si se selecciona explícitamente antes de borrar el filtro. Saltarse este paso deja la referencia huérfana.
3. Replicación incompleta – En dominios con varios controladores, la eliminación puede propagarse antes de que la desasignación se haya replicado, creando una ventana donde los GPO están incoherentes.
4. Ediciones manuales en ADSIEdit – Cambiar atributos sin actualizar los enlaces cruzados produce el mismo síntoma.

En la práctica, la causa más frecuente es la combinación de los dos primeros puntos: borrar el filtro directamente desde la consola de AD o PowerShell sin pasar por la pantalla de asignación.

Solución

1. Detectar GPOs con filtros huérfanos

Utiliza PowerShell para comparar la lista de filtros existentes con la referencia almacenada en cada GPO. El script a continuación devuelve los GPO que apuntan a un filtro que ya no existe.

# PowerShell script ejecutado desde una consola con privilegios de dominio
Import-Module GroupPolicy

# Obtener todos los filtros WMI actuales (distinguishName)
$existingFilters = Get-ADObject -Filter {ObjectClass -eq "msWMI-Filter"} -Properties distinguishedName |
    Select-Object -ExpandProperty distinguishedName

# Recorrer cada GPO y comprobar su atributo gPCWQLFilter
Get-GPO -All | ForEach-Object {
    $gpo = $_
    $filterDN = (Get-ADObject -Identity $gpo.ID -Properties gPCWQLFilter).gPCWQLFilter
    if ($filterDN -and -not ($existingFilters -contains $filterDN)) {
        [PSCustomObject]@{
            GPOName   = $gpo.DisplayName
            GPOGuid   = $gpo.ID
            FilterDN  = $filterDN
        }
    }
}

El resultado muestra el nombre del GPO, su GUID y el DN del filtro que falta.

2. Corregir la referencia

Hay tres caminos prácticos:

Ejemplo para borrar la referencia con PowerShell:

# Reemplaza la referencia por $null
$gpoGuid = "GUID-DEL-GPO"
Set-ADObject -Identity $gpoGuid -Clear "gPCWQLFilter"

3. Validar la corrección

Después de aplicar la solución, ejecuta:

gpresult /h result.html /scope:computer

Abre result.html y verifica que el GPO ya no aparece como denegado por “WMI filter”. También revisa el Visor de eventos bajo System → GroupPolicy para confirmar que no hay errores 1502/1503 relacionados con filtros.

Cuándo aplicar esta solución

• Síntomas: gpresult muestra “Denied (WMI filter)”, el visor de eventos registra errores de filtro, o GPOs que deberían aplicar no lo hacen sin razón aparente.
• Entorno: Dominio Windows Server (cualquier versión que soporte GPMC), con políticas que usan filtros WMI.
• No aplica: Si el GPO está deshabilitado o la política está vinculada a una OU que ya no contiene equipos objetivo; en esos casos el filtro no es la causa.

Código

Import-Module GroupPolicy
$existingFilters = Get-ADObject -Filter {ObjectClass -eq "msWMI-Filter"} -Properties distinguishedName |
    Select-Object -ExpandProperty distinguishedName

Get-GPO -All | ForEach-Object {
    $gpo = $_
    $filterDN = (Get-ADObject -Identity $gpo.ID -Properties gPCWQLFilter).gPCWQLFilter
    if ($filterDN -and -not ($existingFilters -contains $filterDN)) {
        [PSCustomObject]@{
            GPOName   = $gpo.DisplayName
            GPOGuid   = $gpo.ID
            FilterDN  = $filterDN
        }
    }
}

Verificación

1. Ejecuta el script anterior y anota los GPO listados.
2. Aplica la corrección elegida (UI o PowerShell).
3. Fuerza una actualización de políticas: gpupdate /force.
4. Revisa gpresult /r o el informe HTML para confirmar que el GPO aparece bajo Applied Group Policy Objects sin la marca “Denied”.
5. Busca en el Visor de eventos (fuente GroupPolicy) los IDs 1502/1503; la ausencia de estos indica que la referencia al filtro ya no genera errores.

Notas adicionales

• Respaldos: Antes de tocar atributos de AD, exporta los GPO con Backup-GPO.
• Replicación: En dominios con varios DC, espera a que la replicación se complete antes de validar, o usa repadmin /syncall.
• Permisos: Necesitas derechos de Domain Admin o Enterprise Admin para modificar gPCWQLFilter.
• Automatización: El script puede integrarse en un job de PowerShell que se ejecute periódicamente y envíe un correo si detecta referencias huérfanas.
• Buenas prácticas: Siempre elimina un filtro desde la pantalla de asignación del GPO; la UI se encarga de limpiar la referencia automáticamente.

Con estos pasos, los filtros WMI dejan de ser un punto ciego y los GPO vuelven a aplicar de forma predecible.