Windows Server 2025 / Solucionar problemas de aplicación de directivas de grupo

Si una directiva de grupo no se aplica en Windows Server 2025, compruebe el valor configurado, los vínculos y el ámbito, los filtros y permisos, la conectividad del dominio y el resultado real del cliente. Use gpresult y los eventos para identificar un rechazo o la directiva que determina el valor final antes de cambiar nada. Repetir gpupdate sin localizar la causa no demuestra que el ajuste llegue al usuario o al equipo correctos.

Definir el equipo, el usuario y el ajuste afectados

Defina una combinación concreta de equipo, usuario y ajuste. Para el aviso de inicio de sesión de CLIENT1, anote el objeto de directiva de grupo (GPO), la unidad organizativa (OU) del equipo y el título esperado. Si reproduce la práctica de creación y vinculación de un GPO, compruebe Lab-Computer-Message en Lab\Workstations y el título literal Lab computer; no traduzca el valor de la práctica. Si ya retiró el aviso, revise primero cuál es ahora el estado esperado. Para una directiva de usuario, identifique en cambio al usuario realmente conectado y su OU. Distinga entre un único ajuste ausente, todos los ajustes ausentes y un fallo limitado a determinados clientes.

En CLIENT1, las consultas siguientes identifican equipo, identidad de la sesión y pertenencia al dominio. Se espera el nombre CLIENT1 y PartOfDomain = True para el laboratorio, pero esos datos no prueban que un GPO concreto se haya procesado. LOGONSERVER refleja el inicio de sesión y no determina por sí solo qué controlador proporcionó cada procesamiento posterior. Durante la réplica, distintos controladores pueden mostrar cambios en momentos diferentes. La guía de Microsoft para diagnosticar la aplicación de directivas de grupo propone contrastar resultados y eventos:

hostname
whoami
$env:LOGONSERVER
Get-CimInstance Win32_ComputerSystem | Select-Object Domain,PartOfDomain

Revisar contenido y vínculos en GPMC

1. En la Consola de administración de directivas de grupo (GPMC, gpmc.msc), abra el GPO correcto y su pestaña Configuración. Compruebe que el valor esperado esté guardado; para el ejemplo, revise el título y el texto del aviso en Configuración del equipo → Directivas → Configuración de Windows → Configuración de seguridad → Directivas locales → Opciones de seguridad.
2. Confirme si el ajuste pertenece a Configuración del equipo o Configuración de usuario. La ubicación del objeto de equipo determina el ámbito de equipo; la OU de quien administra el GPO no lo sustituye.
3. Revise el vínculo en la OU correspondiente, Vínculo habilitado y el Estado de GPO. Un vínculo deshabilitado, todo el GPO deshabilitado y solo una de sus secciones deshabilitada son situaciones distintas.
4. En Ámbito y Delegación, distinga Leer de Aplicar directiva de grupo y examine los permisos efectivos y las denegaciones. La pertenencia al grupo o poder abrir el GPO no demuestra por sí solo que pueda aplicarse.
5. Compruebe el filtro de Instrumental de administración de Windows (WMI), que se evalúa en el equipo de destino, y revise Bloquear herencia y Aplicación obligatoria. Inspeccione estas condiciones sin activarlas ni retirarlas indiscriminadamente.

Quitar Usuarios autenticados del filtrado elimina tanto Leer como Aplicar directiva de grupo y no establece por sí solo un ámbito restringido correcto. Para los usuarios destinatarios se necesitan los permisos adecuados, pero el equipo también debe poder leer el GPO de usuario. La explicación de Microsoft sobre la lectura del GPO por el equipo distingue ambos requisitos. Si la causa comprobada es esa lectura, en Delegación → Agregar conceda Leer a los equipos o al grupo previsto, según el diseño, sin conceder Aplicar a todo el dominio por comodidad. Revise denegaciones explícitas antes de añadir permisos. Los detalles de ámbito y filtrado ayudan a comprobar a quién corresponde la configuración; no cambie los filtros de producción para forzar una demostración.

Obtener los resultados reales del cliente

En CLIENT1, abra Windows PowerShell como administrador para las consultas de equipo y la creación del informe de equipo. La última línea consulta al usuario de la sesión que ejecuta el comando: solo representa al afectado si es la misma identidad. Si elevó con otra cuenta, ejecute gpresult /r /scope user por separado en la sesión real del usuario afectado, no sustituya su resultado por el del administrador. Los comandos de gpresult muestran el conjunto resultante de directivas (RSoP). Esta práctica supone un cliente x64; en Windows ARM64, Microsoft especifica el ejecutable de SysWow64 para /h:

$reportDirectory = Join-Path $env:TEMP ('gp-check-' + (Get-Date -Format 'yyyyMMdd-HHmmss'))
New-Item -ItemType Directory -Path $reportDirectory | Out-Null
gpresult /r /scope computer
gpresult /scope computer /h (Join-Path $reportDirectory 'computer.html')
gpresult /r /scope user

El bloque crea un directorio gp-check con fecha y hora dentro de la carpeta temporal y guarda computer.html allí; no abre el navegador. Consulte el valor de $reportDirectory para localizarlo y abra ese archivo con el navegador. Si falla la creación del directorio o gpresult informa un error, deténgase y no interprete un informe antiguo como resultado actual. Compruebe equipo, ámbito y hora de recopilación en el informe. El resumen de usuario de la última línea se muestra en consola y no se guarda en computer.html.

Que un GPO aparezca en la lista de aplicados no garantiza que cada ajuste tenga el efecto esperado. En computer.html localice el ajuste exacto y su GPO de origen; compare con los criterios de la tabla. Compruebe versión del sistema, plantillas administrativas, sección de equipo o usuario y errores de la extensión que procesa ese ajuste. La guía de resultados de directiva de grupo distingue el resultado observado de una simulación de modelado. Si otro GPO aporta el valor final, examine la precedencia con la lección sobre orden e herencia en vez de marcar Aplicación obligatoria sin diagnóstico.

Relacionar DNS, SYSVOL, réplica y eventos

Ejecute estas consultas de diagnóstico en CLIENT1 con permisos para leer el registro. Resolve-DnsName usa la configuración DNS del cliente: debe poder localizar los servicios del dominio de laboratorio, sin sustituir su DNS por uno público. Test-Path devuelve solo si la ruta consultada es accesible; True no demuestra que todos los archivos de cada GPO y sus permisos sean correctos. False tampoco identifica por sí solo la causa: puede haber problemas de resolución, acceso o conectividad. El último comando muestra una muestra de los 30 eventos más recientes y puede omitir el ciclo que se está investigando. No desactive el firewall para que una comprobación responda.

Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.test' -Type SRV
Test-Path '\\ad.example.test\SYSVOL'
Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 30 | Select-Object TimeCreated,Id,LevelDisplayName,Message

En el Visor de eventos de CLIENT1, abra Registros de Windows → Sistema y localice el error o advertencia GroupPolicy del momento afectado. En Detalles consulte ActivityID y el controlador mencionado. Luego abra Registros de aplicaciones y servicios → Microsoft → Windows → GroupPolicy → Operational para relacionar los eventos de ese mismo ciclo. La selección del comando anterior no incluye ActivityID, por lo que debe abrir los detalles para verlo. Una actualización posterior genera otro identificador: no mezcle ciclos ni confunda un éxito antiguo con la prueba recién repetida. Si los últimos 30 eventos no abarcan la hora pertinente, amplíe la revisión al intervalo correcto.

Un GPO tiene una parte en Active Directory (AD) y otra en SYSVOL, el recurso que contiene archivos de directivas y scripts del dominio. Compruebe qué controlador aparece en el evento y si los cambios pertinentes han llegado a DC1 y DC2. La lección sobre réplica de AD ayuda a revisar la parte de directorio; eso no demuestra por sí solo que los archivos de SYSVOL también se hayan replicado. Examine los eventos y el estado correspondiente de replicación del sistema de archivos distribuido (DFS Replication). No copie a la fuerza una versión antigua de un controlador ni elimine SYSVOL como reparación genérica.

Corregir una causa y comprobar de nuevo

Corrija una causa confirmada y anote exactamente el cambio y el valor anterior. Para el caso de equipo de CLIENT1, actualice solo ese ámbito con el comando siguiente. Si la causa pertenece a una directiva de usuario, trate su ámbito en la sesión adecuada. Cierre e inicie sesión o reinicie solo cuando el ajuste lo requiera; por ejemplo, el aviso del laboratorio se observa en el siguiente inicio de sesión y no justifica reiniciar el servidor indiscriminadamente:

gpupdate /target:computer /force

Después de la corrección, vuelva a generar el informe en un directorio nuevo y compare el valor esperado, el GPO de origen final y el comportamiento real. La salida de gpupdate no basta para confirmar todo lo anterior. Las condiciones de procesamiento de las directivas incluyen extensiones que requieren inicio de sesión o arranque, y el procesamiento de usuario puede usar bucle invertido (loopback), que combina o sustituye las directivas del usuario con las asociadas al equipo en escenarios expresamente configurados. No lo habilite como arreglo general. Si no se resuelve, revierta únicamente el cambio que hizo y conserve el error pendiente, la hora y la identidad con que obtuvo la evidencia.

Los informes HTML y eventos pueden contener usuarios, equipos, dominios y rutas internas. Guárdelos en una ubicación de acceso limitado, revise qué necesita compartir y oculte datos innecesarios antes de publicar diagnósticos. No incluya contraseñas ni habilite registros detallados de depuración de forma permanente solo para ampliar la recopilación.