Guía práctica de la directiva de grupo (GPO) — funcionamiento, verificación de la aplicación y cuándo usar Intune

«Esta configuración se distribuye por GPO», «los PC del cliente están atados por la directiva de grupo»… Si trabaja con sistemas empresariales sobre Windows, el término «GPO» aparece constantemente en las conversaciones. Sin embargo, cuando le toca a uno mismo asumir la operación del área de sistemas de un entorno AD o implantar una aplicación en un PC unido a un dominio en las instalaciones de un cliente, son sorprendentemente pocos quienes pueden explicar con precisión cuándo, desde dónde y con qué orden de prioridad se aplica la directiva de grupo.

«Cambié la configuración pero no se aplica», «me dijeron que ejecutara gpupdate pero no sé qué está pasando», «una aplicación que funciona en la máquina de desarrollo solo falla en el cliente, y al investigar resultó ser una GPO»… Este artículo está dirigido a los desarrolladores de aplicaciones empresariales que se topan con estas situaciones y a los responsables de sistemas de pymes que han heredado un entorno AD, y organiza, a partir de fuentes primarias vigentes en agosto de 2026, el funcionamiento de la directiva de grupo (el orden de aplicación LSDOU), el momento en que se aplica, el diagnóstico con gpresult y el registro de eventos, ADMX y el almacén central, y cómo elegir entre esto e Intune (MDM).

1. Conclusión inicial

• La directiva de grupo funciona con el criterio de “gana la última procesada”. Se procesa en el orden local → sitio → dominio → OU (LSDOU), y la GPO procesada más tarde tiene prioridad en caso de conflicto. La GPO local (gpedit.msc) es la capa más débil.¹
• El momento de aplicación combina “primer plano + segundo plano”. La configuración de equipo se aplica siempre al arrancar y la de usuario siempre al iniciar sesión, y además, por defecto, hay una actualización en segundo plano cada 90 minutos aproximadamente más un desfase aleatorio de 0 a 30 minutos (5 minutos en los controladores de dominio).²
• gpupdate /force “reaplica todos los ajustes”, pero no es una solución universal. Hay configuraciones, como la instalación de software o la redirección de carpetas, que solo se procesan al iniciar sesión o al reiniciar (por eso existen las opciones /logoff y /boot).³
• El punto de partida del diagnóstico es el informe RSoP de gpresult /h. Muestra las GPO aplicadas y las GPO denegadas (con su motivo). Para profundizar se usa el registro operativo de GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• Las directivas de las plantillas administrativas se escriben, por regla general, en las claves del Registro reservadas para directivas (Software\Policies, etc.). El valor de la directiva tiene prioridad sobre la configuración propia de la aplicación, y “No configurado” no escribe nada. Aun así, existen algunas directivas que escriben fuera de esas claves reservadas (capítulo 5).⁶
• El almacén central de ADMX es la carpeta PolicyDefinitions dentro de SYSVOL. Al crearla, GPMC pasa a consultar las definiciones de plantillas comunes a todo el dominio.⁷
• La elección entre GPO e Intune se decide por la infraestructura de identidad del dispositivo. Configurar el mismo ajuste en ambos no garantiza el resultado. Para estudiar la migración puede usarse Group Policy analytics.⁸⁹
• Para un desarrollador, la GPO es una causa clásica de “solo falla en el cliente”. La directiva de ejecución, la deshabilitación de la fusión de reglas locales del firewall, la configuración de proxy y de unidades, entre otras, son ajustes que cambian las premisas de la aplicación y se distribuyen mediante administración centralizada.¹⁰¹¹

2. Qué es la directiva de grupo — GPO local y GPO de dominio

La directiva de grupo es el mecanismo por el cual un administrador define de forma centralizada la configuración de Windows y la fuerza sobre los equipos y usuarios objetivo. A cada conjunto de configuraciones se le llama GPO (objeto de directiva de grupo). Las GPO tienen dos ubicaciones posibles.

Los PC en grupo de trabajo (no unidos a un dominio) solo procesan la GPO local.¹ Es decir, cuando en la práctica se dice “administrado por GPO”, casi siempre se refiere a una GPO de dominio.

flowchart TB
    accTitle: GPO que procesan un PC en grupo de trabajo y un PC unido al dominio
    accDescr: Un PC en grupo de trabajo solo procesa la GPO local, mientras que un PC unido al dominio procesa además la GPO de dominio distribuida desde Active Directory
    pc{"¿Cuál es la forma de pertenencia del PC?"}
    pc -->|Grupo de trabajo| wg["Solo procesa la GPO local"]
    pc -->|Unido al dominio| dom["GPO local + GPO de dominio"]
    dom -.-> note["En la práctica, casi toda GPO es GPO de dominio"]

Figura 1: un PC en grupo de trabajo solo procesa la GPO local, mientras que uno unido al dominio también procesa la GPO de dominio.

En cualquier GPO, el contenido se divide a grandes rasgos en dos ramas.

• Configuración de equipo: ajustes que afectan a cualquiera que inicie sesión en ese PC. Se aplican al arrancar.
• Configuración de usuario: ajustes que afectan a ese usuario, en cualquier PC en el que inicie sesión. Se aplican al iniciar sesión.

El eje de “si el ajuste está ligado al PC o a la persona” aparece de forma constante tanto en el orden de aplicación como en la verificación de la aplicación que veremos más adelante. Hay ajustes que existen en ambas ramas con el mismo nombre, así que al buscar una configuración conviene revisar siempre las dos.

flowchart TB
    accTitle: Las dos ramas del contenido de una GPO
    accDescr: Toda GPO tiene dos ramas, la configuración de equipo y la configuración de usuario; la configuración de equipo se aplica al arrancar y afecta a cualquiera que inicie sesión en el PC, y la configuración de usuario se aplica al iniciar sesión y afecta a ese usuario en cualquier PC
    gpo["Contenido de la GPO"] --> comp["Configuración de equipo"]
    gpo --> user["Configuración de usuario"]
    comp --> boot["Se aplica al arrancar"]
    user --> logon["Se aplica al iniciar sesión"]
    boot -.-> anyone["Afecta a cualquiera que inicie sesión"]
    logon -.-> anypc["Afecta en cualquier PC"]

Figura 2: toda GPO tiene dos ramas: la configuración de equipo, ligada al PC, y la configuración de usuario, ligada a la persona.

3. Cómo funciona la aplicación — el “gana el último” de LSDOU y el control de la herencia

3.1. LSDOU: local → sitio → dominio → OU

En un PC unido al dominio, las GPO se procesan en el siguiente orden.¹

1. GPO local
2. GPO vinculadas al sitio
3. GPO vinculadas al dominio
4. GPO vinculadas a la OU (unidad organizativa) — se procesan desde la OU superior hacia abajo, y por último se procesa la GPO de la OU a la que pertenece directamente el equipo o usuario objetivo

Este orden se conoce por sus siglas en inglés, LSDOU. Lo importante es que no es “el orden de mayor a menor prioridad”, sino el orden en que se procesa. Cuando varias GPO configuran el mismo ajuste, gana la GPO procesada más tarde (los ajustes que no entran en conflicto simplemente se suman).¹ Es decir, la GPO de la OU más cercana al objetivo es la más fuerte, y la GPO local es la más débil. Que “lo que arreglé en gpedit.msc vuelva a su estado anterior” no es una avería, sino el comportamiento previsto según esta especificación.

flowchart TB
    accTitle: Orden de procesamiento de LSDOU y el criterio de gana el último
    accDescr: Las GPO se procesan en el orden local, sitio, dominio y OU, y en caso de conflicto gana la GPO procesada más tarde, por lo que la GPO de la OU más cercana al objetivo es la más fuerte y la GPO local es la más débil
    l["1. GPO local"] --> s["2. Sitio"]
    s --> d["3. Dominio"]
    d --> ou["4. OU (de la superior a la inferior)"]
    ou --> win["En conflicto, gana la última"]
    win -.-> strongest["La GPO de la OU más cercana es la más fuerte"]
    win -.-> weakest["La GPO local es la más débil"]

Figura 3: LSDOU es el orden en que se procesa, y cuando el mismo ajuste entra en conflicto, gana la GPO procesada más tarde.

Cuando hay varias GPO vinculadas al mismo sitio, dominio u OU, el orden se decide por el orden de vínculo de la pestaña “Objetos de directiva de grupo vinculados” de GPMC. La GPO con el número de orden de vínculo más bajo se procesa la última y es la de mayor prioridad.¹

flowchart TB
    accTitle: Orden de vínculo cuando hay varias GPO en la misma ubicación
    accDescr: Cuando varias GPO están vinculadas al mismo sitio, dominio u OU, el orden de procesamiento se decide por el orden de vínculo de GPMC, y la GPO con el número más bajo se procesa la última y tiene la máxima prioridad
    multi["Varias GPO en la misma ubicación"] --> tab["Se decide por el orden de vínculo de GPMC"]
    tab --> last["La GPO con el número más bajo se procesa la última"]
    last --> win["Gana por ser la última procesada"]

Figura 4: en una misma ubicación de vínculo, la GPO con el número de orden de vínculo más bajo se procesa la última y gana.

3.2. Bloqueo de herencia y forzado (Enforced)

Se pueden crear excepciones al orden predeterminado.¹

• Bloqueo de herencia: al configurarlo en un dominio o una OU, se detiene la herencia de las GPO provenientes de niveles superiores. Es la herramienta para casos como “esta OU en concreto no debe recibir el estándar de toda la empresa”.
• Forzado (Enforced, antes llamado “no anular”): al configurarlo en el vínculo de una GPO, esa GPO siempre se aplica aunque esté bloqueada la herencia en un nivel inferior, y deja de poder ser sobrescrita por GPO de niveles inferiores. Cuando el bloqueo de herencia y el forzado entran en conflicto, gana el forzado.¹

flowchart TB
    accTitle: Relación entre el bloqueo de herencia y el forzado
    accDescr: El bloqueo de herencia detiene la herencia de las GPO provenientes de niveles superiores, pero una GPO forzada se aplica siempre aunque haya bloqueo de herencia en un nivel inferior, y tampoco es sobrescrita por las GPO de niveles inferiores
    upper["GPO de un nivel superior"] --> blocked{"¿Hay bloqueo de herencia en un nivel inferior?"}
    blocked -->|No| inherit["Se hereda tal cual"]
    blocked -->|Sí| enforced{"¿La GPO tiene forzado?"}
    enforced -->|No| stop["La herencia se detiene"]
    enforced -->|Sí| apply["Se aplica siempre"]
    apply -.-> noover["No la sobrescriben las GPO de niveles inferiores"]

Figura 5: el bloqueo de herencia detiene la herencia desde niveles superiores, pero una GPO forzada se aplica siempre, incluso atravesando el bloqueo.

El forzado rompe el principio de “gana el último”, así que si se usa en exceso, la lectura del RSoP producirá cada vez más resultados contraintuitivos. Lo habitual es reservarlo exclusivamente para los ajustes de seguridad que deben cumplirse obligatoriamente en toda la empresa.

3.3. Filtrado de seguridad

No solo se puede acotar por la ubicación del vínculo: a quién se aplica también puede restringirse GPO por GPO. Para que una GPO se aplique, el usuario o el equipo objetivo debe tener sobre esa GPO ambos permisos, “Leer” y “Aplicar directiva de grupo”. De forma predeterminada, Usuarios autentificados (que incluye tanto usuarios como equipos) tiene ambos permisos concedidos, por lo que se aplica a todos los que estén bajo la ubicación vinculada. Restringir esto a un grupo de seguridad concreto es el filtrado de seguridad. El filtro afecta a la GPO completa; no se puede variar ajuste por ajuste dentro de una misma GPO.¹³

Hay una precaución importante. Al restringir a quién se aplica, no se debe quitar el permiso “Leer” al grupo predeterminado Usuarios autentificados. Desde la actualización de seguridad MS16-072 (2016), la directiva orientada a usuario se obtiene con el contexto de seguridad del equipo, de modo que si la cuenta de equipo no puede leer la GPO, esta no se aplicará a las directivas de usuario aunque se hayan concedido ambos permisos al usuario objetivo.¹⁴ Al restringir el alcance, lo correcto es conceder “Leer + Aplicar directiva de grupo” al grupo objetivo y dejar solo “Leer” para Usuarios autentificados (o Equipos del dominio).¹⁴

flowchart TB
    accTitle: Criterio de aplicación del filtrado de seguridad
    accDescr: Para que se aplique una GPO, el usuario o el equipo objetivo debe tener ambos permisos de leer y aplicar directiva de grupo, y en las GPO orientadas a usuario además se necesita que la cuenta de equipo pueda leerla
    target["Objetivo bajo la ubicación vinculada de la GPO"] --> perm{"¿Tiene ambos permisos de leer y aplicar?"}
    perm -->|No| deny["Denegada por filtro"]
    perm -->|Sí| usergpo{"¿Es una GPO orientada a usuario?"}
    usergpo -->|No| apply["Se aplica"]
    usergpo -->|Sí| comp{"¿El equipo puede leerla?"}
    comp -->|Sí| apply
    comp -->|No| deny2["No se aplica (MS16-072)"]

Figura 6: aplicar requiere tanto “Leer” como “Aplicar directiva de grupo”, y en las GPO orientadas a usuario también hace falta que la cuenta de equipo pueda leerla.

En la práctica, los tropiezos clásicos son “lo añadí al grupo pero no se aplica (era un ajuste de equipo pero solo se añadió al usuario al grupo)” o “lo quité del grupo pero se sigue aplicando”. Este segundo caso no se resuelve esperando a la actualización en segundo plano. La pertenencia a grupos se evalúa con el token de seguridad creado al iniciar sesión, así que un cambio de grupo de usuario requiere cerrar e iniciar sesión de nuevo, y un cambio de grupo de equipo requiere reiniciar, para que se genere un token nuevo y recién entonces se refleje en el filtro.

flowchart TB
    accTitle: Hasta que un cambio de grupo se refleja en el filtro
    accDescr: La pertenencia a grupos se evalúa con el token de seguridad creado al iniciar sesión, por lo que un cambio de usuario requiere volver a iniciar sesión y un cambio de equipo requiere reiniciar, para que con el token nuevo se refleje recién entonces en el filtro
    change["Se cambia la pertenencia a un grupo"] --> old["Con el token antiguo no se refleja"]
    old --> u["El usuario debe volver a iniciar sesión"]
    old --> c["El equipo debe reiniciar"]
    u --> token["Se evalúa con el token nuevo"]
    c --> token
    token --> ok["Se refleja en el filtro"]
    old -.-> bg["La actualización en segundo plano no lo resuelve"]

Figura 7: un cambio de grupo solo se refleja en el filtro cuando se genera un token nuevo, al cerrar e iniciar sesión o al reiniciar.

Además, para situaciones como PC compartidos o servidores de escritorio remoto donde se quiere “sustituir la configuración de usuario para todo el que inicie sesión en ese PC”, existe un modo especial llamado procesamiento de bucle invertido (loopback) (un mecanismo que aplica la configuración de usuario en función de la ubicación del equipo, con dos modos: reemplazo y combinación).¹⁵ Es una función avanzada que se usa en quioscos o PC de aula, así que en este artículo nos limitamos a presentar su existencia.

flowchart TB
    accTitle: Idea del procesamiento de bucle invertido
    accDescr: El procesamiento de bucle invertido es un modo especial que aplica la configuración de usuario en función de la ubicación del equipo, con dos modos, reemplazo y combinación, y se usa en situaciones como PC compartidos o quioscos donde se quiere que todos los que inicien sesión reciban la misma configuración de usuario
    shared["PC compartido, quiosco, etc."] --> lb["Procesamiento de bucle invertido"]
    lb --> base["Se decide por la ubicación del equipo"]
    base --> rep["Modo de reemplazo"]
    base --> mrg["Modo de combinación"]
    lb -.-> aim["Afecta a todos los que inicien sesión"]

Figura 8: el procesamiento de bucle invertido es un modo especial que aplica la configuración de usuario según la ubicación del equipo, con los modos de reemplazo y de combinación.

4. Cuándo se aplica — procesamiento en primer plano y actualización en segundo plano

La mitad de los casos de “lo configuré pero no se aplica” se deben simplemente a que todavía no ha llegado el momento de aplicación. Hay dos tipos de aplicación.²

Es decir, en un equipo en funcionamiento que puede llegar al controlador de dominio, aunque no se haga nada tras cambiar una GPO, los ajustes compatibles con la actualización en segundo plano se propagan en unas 2 horas aproximadamente. A un equipo sin conexión o a un portátil sin VPN conectada no le llegarán hasta la próxima vez que se conecte al DC. Los ajustes que solo se aplican en el procesamiento en primer plano tendrán que esperar además a un arranque o inicio de sesión. Si hay prisa, se ejecuta gpupdate en el PC objetivo. Por defecto se aplican solo los ajustes que hayan cambiado, y con /force se reaplican todos los ajustes, hayan cambiado o no.³

rem Actualizar solo lo que cambió (normalmente es suficiente)
gpupdate

rem Reaplicar todos los ajustes (cuando se sospecha de un estado cacheado)
gpupdate /force

flowchart TB
    accTitle: Posibilidad de alcanzar el DC y cómo llega la aplicación
    accDescr: A un equipo en funcionamiento que puede alcanzar el controlador de dominio le llegan en unas 2 horas los ajustes compatibles con la actualización en segundo plano, pero a un portátil sin conexión o sin VPN no le llegan hasta la próxima vez que se conecte al DC
    pc{"¿Puede alcanzar el DC?"}
    pc -->|Sí| ok["Llega en unas 2 horas"]
    pc -->|No| ng["No llega hasta conectar"]
    ng -.-> ex["Portátil sin conexión o sin VPN"]

Figura 9: a un equipo en funcionamiento que alcanza el DC le llega en unas 2 horas, pero a uno sin conexión no le llega hasta que se conecte al DC.

Conviene notar que hay ajustes que gpupdate no aplica. La instalación de software orientada a usuario y la redirección de carpetas solo se procesan al iniciar sesión, y la instalación de software orientada a equipo solo se procesa al arrancar. Para esto, gpupdate dispone de las opciones /logoff (cerrar sesión tras la actualización) y /boot (reiniciar tras la actualización).³ Antes de alarmarse porque “ejecuté gpupdate /force y no entró”, compruebe si ese ajuste es del tipo que requiere reinicio o inicio de sesión.

flowchart TB
    accTitle: Vía por la que se aplica un ajuste
    accDescr: Un cambio de GPO llega en unos 90 minutos más un desfase de 0 a 30 minutos si el ajuste admite actualización en segundo plano, y los ajustes que solo se aplican en primer plano deben esperar al arranque o al inicio de sesión; si se usa gpupdate para ir más rápido, los ajustes de primer plano también necesitan /logoff o /boot
    change["Se cambia una GPO"] --> kind{"¿Admite actualización en segundo plano?"}
    kind -->|Sí| bg["Se actualiza en unos 90 min + 0-30 min"]
    kind -->|No| fg["Se aplica al arrancar o iniciar sesión"]
    bg --> done["Aplicado"]
    fg --> done
    rush["Si hay prisa"] -.-> upd["Se ejecuta gpupdate"]
    upd -.-> force["Con /force se reaplica todo"]
    upd -.-> reboot["Lo de primer plano necesita /logoff o /boot"]

Figura 10: la actualización en segundo plano solo trae los ajustes compatibles, y los que solo se aplican en primer plano necesitan cerrar sesión o reiniciar aun después de gpupdate.

5. Diagnóstico cuando no se aplica — gpresult, registro de eventos y el Registro

5.1. Comprobar el RSoP con gpresult /h

La herramienta estándar para verificar el resultado final cuando se superponen varias GPO (RSoP: conjunto resultante de directivas) es gpresult. La forma más legible es generar un informe HTML desde un símbolo del sistema con privilegios de administrador.⁴⁵

rem Genera un informe HTML con el RSoP de usuario y de equipo
gpresult /h C:\temp\gp-report.html /f

rem Para ver solo un resumen en la consola
gpresult /r
gpresult /scope computer /r

En el informe, lo primero que hay que revisar son estos tres puntos.

1. La lista de GPO aplicadas — si la GPO buscada está incluida
2. La lista de GPO denegadas y su motivo — se muestran los motivos de no aplicación, como el filtrado de seguridad, el filtro WMI o una GPO vacía⁵
3. La “GPO que prevalece” en cada ajuste — con qué GPO quedó decidido el valor del ajuste buscado. Si otra GPO está ganando, hay que revisar el orden de prioridad del capítulo 3

flowchart TB
    accTitle: Los tres puntos que se revisan primero en el informe RSoP
    accDescr: En el informe de gpresult primero se comprueba si la GPO buscada está en la lista de GPO aplicadas, después se revisa la lista de GPO denegadas con su motivo, y por último se identifica en la GPO que prevalece de cada ajuste cuál GPO ganó
    rep["Abrir el informe RSoP"] --> one["1. Lista de GPO aplicadas"]
    one --> two["2. GPO denegadas y motivo"]
    two --> three["3. GPO que prevalece en cada ajuste"]
    three -.-> review["Si gana otra GPO, revisar el orden"]

Figura 11: el informe RSoP se lee en el orden de GPO aplicadas, GPO denegadas con motivo, y la GPO que prevalece en cada ajuste.

5.2. Registro operativo de GroupPolicy

Cuando gpresult no basta (el procesamiento falla directamente, tarda demasiado, etc.), se revisa el registro operativo de GroupPolicy en el Visor de eventos. Su ubicación es “Registros de aplicaciones y servicios > Microsoft > Windows > GroupPolicy > Operational” (nombre del registro Microsoft-Windows-GroupPolicy/Operational). Aquí queda registrado, desde el inicio hasta el fin del procesamiento de directivas, junto con la lista de GPO aplicadas y la lista de GPO denegadas (con su motivo). A cada instancia del procesamiento de directivas se le asigna un ActivityID único, por lo que el procedimiento recomendado por Microsoft es tomar el ActivityID de las advertencias o errores del registro del sistema y usar una vista personalizada para acotar solo esa instancia.⁵

flowchart TB
    accTitle: Procedimiento para acotar el registro operativo de GroupPolicy
    accDescr: En el registro operativo de GroupPolicy se asigna un ActivityID único a cada instancia del procesamiento de directivas, así que se toma el ActivityID de las advertencias o errores del registro del sistema y se usa una vista personalizada para acotar solo los eventos de esa instancia
    sys["Advertencias/errores del registro del sistema"] --> aid["Se toma el ActivityID"]
    aid --> cv["Se acota con una vista personalizada"]
    cv --> one["Se leen los eventos de una sola instancia"]
    one -.-> rec["Las listas de GPO aplicadas y denegadas con su motivo"]

Figura 12: el registro operativo se lee tomando el ActivityID del registro del sistema y acotando con una vista personalizada a una sola instancia del procesamiento.

5.3. Relación con la clave Policies del Registro

Las directivas de las plantillas administrativas (siguiente capítulo) terminan escribiéndose como valores del Registro. El destino de escritura, por regla general, son las siguientes claves reservadas para directivas.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (configuración de equipo; ubicación recomendada)
• HKEY_CURRENT_USER\Software\Policies (configuración de usuario; ubicación recomendada)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Aquí hay una filosofía de diseño importante. Una aplicación compatible con directivas primero lee la clave Policies, y si hay un valor le da prioridad; si no lo hay, usa su propia configuración (preferencia) o el valor predeterminado. Una directiva “No configurada” no escribe nada en el Registro.⁶ Es decir, la directiva de una plantilla administrativa no reescribe la configuración propia de la aplicación dejando un “tatuaje” (tattooing), sino que funciona con el mecanismo de que un valor forzado ubicado en otro lugar se consulta con prioridad. Si se deja de configurar la directiva, la aplicación puede volver a regirse por su propio valor de configuración.

flowchart TB
    accTitle: Relación de prioridad entre el valor de la directiva y la configuración de la aplicación
    accDescr: Una aplicación compatible con directivas primero lee la clave Policies y, si hay un valor, le da prioridad; si no lo hay, usa su propia configuración o el valor predeterminado, y una directiva no configurada no escribe nada en el Registro
    app["La aplicación compatible lee su configuración"] --> haspol{"¿Hay un valor en la clave Policies?"}
    haspol -->|Sí| pol["Da prioridad al valor de la directiva"]
    haspol -->|No| pref["Usa su propia configuración o el predeterminado"]
    notconf["Directiva no configurada"] -.-> nowrite["No escribe nada en el Registro"]

Figura 13: la directiva no reescribe la configuración propia de la aplicación, sino que funciona mediante un valor forzado ubicado en otro sitio que se consulta con prioridad.

Sin embargo, no todas las directivas escriben en la clave reservada. Algunos ajustes integrados en el propio sistema operativo (por ejemplo, “Habilitar rutas largas de Win32” escribe en LongPathsEnabled, dentro de HKLM\SYSTEM\CurrentControlSet\Control\FileSystem), así como algunas plantillas antiguas o de terceros, escriben en rutas arbitrarias fuera de la clave reservada. En este tipo de ajustes, el valor permanece aunque se deje de configurar la directiva. Para saber en qué clave escribe realmente un ajuste concreto, consulte la definición de ADMX, la descripción del ajuste o el informe de gpresult.

Dicho de otro modo, el buen comportamiento descrito antes se limita al marco de las plantillas administrativas (claves reservadas para directivas). Un valor que un script o las Preferencias de directiva de grupo (Preferences) escriban fuera de la clave Policies es un valor de Registro normal, y este marco no incluye ningún mecanismo que lo revierta automáticamente al dejar de distribuirlo. En el diagnóstico práctico, lo más rápido y fiable es comprobar directamente “si el ajuste buscado está escrito en la clave Policies”.

# Ejemplo para comprobar directamente un valor distribuido por directiva (la mayoría se escribe bajo Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Procedimiento de diagnóstico cuando no se aplica
    accDescr: Primero se comprueban las GPO aplicadas y denegadas con el informe RSoP de gpresult, si no basta se acota el registro operativo de GroupPolicy por ActivityID, y el valor realmente distribuido se verifica directamente en la clave Policies del Registro
    start["El ajuste no se aplica"] --> rsop["Comprobar el RSoP con gpresult /h"]
    rsop --> found{"¿Se entiende el motivo de aplicación y denegación?"}
    found -->|Sí| fix["Revisar el orden de prioridad o los filtros"]
    found -->|No| oplog["Revisar el registro operativo de GroupPolicy"]
    oplog -.-> aid["Acotar a una instancia por ActivityID"]
    rsop -.-> reg["Verificar directamente el valor real en la clave Policies"]

Figura 14: el diagnóstico avanza de forma sistemática partiendo de gpresult /h, y si no basta, con el registro operativo de GroupPolicy, verificando el valor real en la clave Policies.

6. Plantillas administrativas (ADMX) y el almacén central

Las definiciones de los elementos de configuración que aparecen en “Plantillas administrativas” de GPMC se describen mediante los archivos ADMX (el cuerpo de la definición del ajuste) y ADML (las cadenas de texto mostradas, por idioma). Cada PC tiene en C:\Windows\PolicyDefinitions las definiciones incluidas con el sistema operativo, y las herramientas de administración las cargan para construir la pantalla de configuración.⁷

Si se opera a nivel de dominio, lo básico es crear un almacén central. Al crear una carpeta PolicyDefinitions bajo SYSVOL en el controlador de dominio (por ejemplo, \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), su contenido se replica a todos los controladores de dominio del dominio, y las herramientas de directiva de grupo pasan a consultar el almacén central de forma predeterminada.⁷ Con esto desaparece el problema de “la versión de la plantilla difiere según el equipo de administración usado para editar, y los elementos de configuración visibles no coinciden”. Los ADML se colocan en subcarpetas por idioma (ja-JP para japonés).⁷

flowchart TB
    accTitle: Funcionamiento del almacén central
    accDescr: Al crear una carpeta PolicyDefinitions bajo SYSVOL en el controlador de dominio, el contenido se replica a todos los controladores de dominio y las herramientas de directiva de grupo la consultan por defecto, con lo que desaparecen las discrepancias de definiciones entre equipos de administración
    create["Se crea bajo SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["Se replica a todos los DC"]
    cs --> ref["Las herramientas de directiva la consultan por defecto"]
    ref -.-> benefit["Desaparecen las discrepancias entre equipos"]
    cs -.-> adml["Los ADML van en carpetas por idioma"]

Figura 15: PolicyDefinitions en SYSVOL se replica a todos los controladores de dominio, y las herramientas de directiva de grupo la consultan por defecto.

Hay dos precauciones operativas. Primero, Microsoft distribuye los ADMX para cada nueva versión de Windows por separado, y al actualizarlos hay que sustituir el lado del almacén central. No es compatible sustituir el C:\Windows\PolicyDefinitions de cada PC con la versión descargada.⁷ Segundo, al actualizar un almacén central existente, en lugar de sobrescribir directamente la carpeta PolicyDefinitions de producción, se recomienda reunir el juego completo de ADMX del sistema operativo y de las aplicaciones (Office, Edge, etc.) en una carpeta de trabajo con nombre de versión, como PolicyDefinitions-24H2, renombrar la carpeta actual a algo como PolicyDefinitions-23H2 para dejarla como respaldo, y por último renombrar la carpeta de trabajo a PolicyDefinitions para ponerla en producción.⁷ Como las herramientas de directiva de grupo solo consultan la carpeta llamada exactamente PolicyDefinitions, con solo colocarla en una carpeta con nombre de versión no se refleja. Si surge algún problema, la ventaja de este método es poder volver a la carpeta anterior que se dejó como respaldo.⁷

flowchart TB
    accTitle: Procedimiento de actualización del almacén central
    accDescr: La actualización consiste en reunir el juego de ADMX del sistema operativo y de las aplicaciones en una carpeta de trabajo con nombre de versión, renombrar la carpeta actual para dejarla como respaldo, renombrar la carpeta de trabajo al nombre de producción PolicyDefinitions, y si surge algún problema volver a la carpeta anterior guardada como respaldo
    work["Carpeta de trabajo con nombre de versión"] --> gather["Se reúne el ADMX del SO y las apps"]
    gather --> evac["Se renombra la actual como respaldo"]
    evac --> rename["Se renombra la de trabajo al nombre de producción"]
    rename --> live["Pasa a ser la consultada en producción"]
    live -.-> back["Ante un problema, se vuelve a la carpeta anterior"]

Figura 16: la actualización reúne el juego completo en una carpeta de trabajo, deja la carpeta actual como respaldo y pone en producción mediante el renombrado.

7. GPO frente a Intune (MDM/CSP) frente a distribución manual o por script — tabla de decisión

Las opciones para administrar la configuración de los equipos Windows ya no se limitan a la GPO. Intune, como representante de las soluciones MDM, configura los ajustes del sistema operativo a través de un mecanismo llamado CSP (proveedor de servicios de configuración). Esta es la tabla de decisión sobre en cuál apoyarse.

El eje de decisión es simple: la infraestructura de identidad del equipo (AD o Microsoft Entra) y dónde se encuentra el equipo. Para un conjunto de PC fijos en la oficina totalmente unidos a un AD local, la GPO es lo más fiable, y para un PC portátil unido a Entra, la GPO ni siquiera llega.

En la realidad, las pymes suelen estar en un punto intermedio, es decir, en un entorno híbrido (unido al dominio + registrado en Intune), y lo peor en este caso es “configurar el mismo ajuste tanto en GPO como en MDM”. El Policy CSP dispone de una directiva llamada MDMWinsOverGP que hace que gane el MDM cuando GPO y MDM entran en conflicto, pero su alcance se limita a las directivas compatibles dentro de Policy CSP. Microsoft mismo advierte explícitamente que configurar en GPO y MDM a la vez un ajuste fuera de este control produce un estado de conflicto cuyo ganador no está garantizado, y recomienda evitar la doble configuración.⁸ El primer principio de una operación híbrida es decidir, por área de configuración, “esto va por GPO, esto por Intune” y volcarse en un solo lado.

flowchart TB
    accTitle: Cuándo usar GPO y cuándo Intune
    accDescr: Si la infraestructura y ubicación del equipo son AD local con presencia permanente en la oficina conviene GPO, si es unión a Entra o fuera de la oficina conviene Intune, y en entornos híbridos se evita la doble configuración del mismo ajuste y se vuelca cada área en un solo lado
    q{"¿Cuál es la infraestructura y ubicación del equipo?"}
    q -->|AD, permanente en la oficina| gpo["GPO es fiable y con granularidad fina"]
    q -->|Entra o fuera de la oficina| intune["Intune llega también fuera de la oficina"]
    q -->|Híbrido| split["Se vuelca cada área en un solo lado"]
    split -.-> warn["La doble configuración no garantiza el resultado"]
    split -.-> ana["Group Policy analytics ayuda a clasificar"]

Figura 17: la elección se decide por la infraestructura de identidad y la ubicación del equipo, y en un entorno híbrido no se configura el mismo ajuste a la vez en GPO y MDM.

En la fase de plantearse migrar de GPO a Intune, la puerta de entrada es Group Policy analytics de Intune. Al importar una GPO exportada desde GPMC (en XML), se puede analizar si cada ajuste es compatible con MDM, o si está en desuso o no es compatible, y los ajustes compatibles se pueden migrar a una directiva de catálogo de configuración de Intune.⁹ Conviene entenderlo no como “migrar todo”, sino como una herramienta para “clasificar lo que se puede migrar, lo que no y lo que se descarta”, lo cual se ajusta más a la realidad. La administración de Windows Update también se está reorganizando en este mismo contexto; consulte también «Administración de Windows Update tras la obsolescencia de WSUS».

flowchart TB
    accTitle: Clasificación mediante Group Policy analytics
    accDescr: Al importar en Group Policy analytics una GPO exportada en XML desde GPMC se puede clasificar cada ajuste según sea compatible con MDM o esté en desuso o no sea compatible, y los ajustes compatibles se pueden migrar a una directiva de catálogo de configuración
    exp["Exportar desde GPMC en XML"] --> imp["Importar en analytics"]
    imp --> ana["Analizar el estado de compatibilidad de cada ajuste"]
    ana --> ok["Compatible con MDM"]
    ana --> dep["En desuso o no compatible"]
    ok --> mig["Migrar a una directiva de catálogo de configuración"]

Figura 18: Group Policy analytics importa la GPO exportada y clasifica los ajustes que se pueden migrar a MDM de los que no.

8. Trampas desde la perspectiva del desarrollador — cuando la GPO del cliente cambia el comportamiento de la aplicación

Por último, un tema que hay que tener presente desde la posición del desarrollo por encargo. La GPO del cliente reescribe silenciosamente las premisas de su aplicación. Como causa de “funciona en la máquina de desarrollo pero no en el cliente”, la GPO es tan habitual como el firewall o el antivirus. Van ejemplos concretos.

• Directiva de ejecución de PowerShell: la directiva de ejecución se puede configurar de forma centralizada por GPO, y los ámbitos MachinePolicy/UserPolicy provenientes de GPO siempre tienen prioridad sobre el valor configurado localmente o en el proceso.¹⁰ Si un instalador o un script operativo se construyó bajo la premisa de que “con añadir -ExecutionPolicy Bypass debería funcionar”, bajo administración por GPO ni siquiera llegará a arrancar. Para más detalle, consulte «Directiva de ejecución de PowerShell y firma de scripts».
• Deshabilitación de la fusión de reglas locales del firewall: en entornos donde el firewall se administra de forma centralizada mediante GPO/Intune, se puede deshabilitar por perfil la “fusión de reglas locales” (AllowLocalPolicyMerge). Cuando está deshabilitada, las reglas de entrada que un instalador registró localmente existen pero no se aplican.¹¹ Es un punto que hay que verificar sin falta antes de implantar una aplicación de tipo servidor, y se trata en detalle en «El firewall de Windows y las aplicaciones empresariales».
• Configuración del entorno como asignación de unidades o proxy: es habitual distribuir la asignación de unidades de red, impresoras, etc. mediante las Preferencias de directiva de grupo (Preferences).¹⁶ Premisas del entorno como “debería existir la unidad Z” o “el proxy debería ser conexión directa” se vienen abajo según el usuario que inicie sesión o la OU a la que pertenezca el PC. También suele pasarse por alto, en las aplicaciones residentes, que un ajuste distribuido en la configuración de usuario no se aplica, como es natural, a la cuenta con la que se ejecutan servicios o tareas.
• Y de entrada, el ajuste “no se puede revertir”: es habitual que los ajustes provenientes de una plantilla administrativa dejen de poder cambiarse desde la pantalla por el usuario (el campo aparece atenuado). Que “pedir al cliente que cambie el ajuste desde su lado” no funcione es algo que condiciona el diseño de la estrategia de respuesta.

flowchart TB
    accTitle: Las premisas de la aplicación que cambia la GPO del cliente
    accDescr: La GPO del cliente cambia las premisas de la aplicación mediante el forzado de la directiva de ejecución, la deshabilitación de la fusión de reglas locales del firewall, la distribución de unidades y proxy, y el estado en que el usuario no puede revertir el ajuste, siendo una causa de que la aplicación solo falle en el cliente
    gpo["GPO del cliente"] --> ep["Forzado de la directiva de ejecución"]
    gpo --> fw["Fusión de reglas locales deshabilitada"]
    gpo --> env["Distribución de unidades y proxy"]
    gpo --> lock["No se puede revertir el ajuste"]
    ep --> sym["Causa de que solo falle en el cliente"]
    fw --> sym
    env --> sym
    lock --> sym

Figura 19: la GPO del cliente reescribe silenciosamente premisas de la aplicación como la directiva de ejecución, el firewall o la configuración del entorno.

Las medidas prácticas para el lado del desarrollo son tres. Primero, documentar como requisito de implantación las premisas del entorno de las que depende la aplicación (directiva de ejecución, puerto de escucha, carpeta de escritura, ruta de proxy, etc.) y pedir al departamento de sistemas del cliente que lo verifique antes de la implantación. Segundo, ante un problema, en lugar de especular, verificar el informe de gpresult /h y los valores reales bajo HKLM\Software\Policies (capítulo 5). Tercero, separar desde la fase de diseño los procesos que requieren privilegios de administrador de los que no (esta línea se trata en «Cuándo se necesitan realmente los privilegios de administrador en Windows»). La GPO no es un enemigo, sino una especificación del entorno. Tratada como tal, el diagnóstico se puede hacer de forma sistemática.

flowchart TB
    accTitle: Las tres medidas del lado del desarrollo
    accDescr: Las medidas del lado del desarrollo son documentar las premisas del entorno de las que depende la aplicación como requisito de implantación y pedir al cliente que lo verifique antes, verificar con el informe de gpresult y los valores reales de la clave Policies ante un problema, y separar desde el diseño los procesos que requieren privilegios de administrador
    dev["Medidas del lado del desarrollo"] --> doc["1. Documentar las premisas del entorno"]
    dev --> chk["2. Verificar con gpresult y valores reales"]
    dev --> priv["3. Separar en el diseño la necesidad de privilegios"]
    doc -.-> ask["Pedir verificación al cliente antes de implantar"]

Figura 20: las medidas del desarrollo son documentar las premisas del entorno, verificar con gpresult y los valores reales, y separar en el diseño la necesidad de privilegios de administrador.

9. Resumen

• La directiva de grupo es un mecanismo que procesa los ajustes de cada GPO en el orden local → sitio → dominio → OU (LSDOU), y los conflictos los gana el último procesado. La GPO de la OU más cercana al objetivo es la más fuerte, y la GPO local es la capa más débil.
• El bloqueo de herencia, el forzado (Enforced) y el filtrado de seguridad permiten controlar el flujo predeterminado. El forzado gana incluso al bloqueo de herencia, así que abusar de él es desaconsejable.
• La aplicación combina el procesamiento en primer plano al arrancar y al iniciar sesión con la actualización en segundo plano de unos 90 minutos por defecto más un desfase aleatorio. gpupdate /force reaplica todos los ajustes, pero no surte efecto en los que solo se procesan al iniciar sesión o al reiniciar.
• Cuando no se aplica, el diagnóstico avanza de forma sistemática por el orden gpresult /h → registro operativo de GroupPolicy → clave Policies del Registro. Las GPO denegadas muestran su motivo.
• Las definiciones de las plantillas administrativas son ADMX/ADML, y en la operación de dominio se centralizan en el almacén central de SYSVOL. Al actualizar, se sustituye el lado del almacén central, no el PolicyDefinitions local.
• Entre GPO e Intune se decide por la infraestructura de identidad y la ubicación del equipo, y en un entorno híbrido se evita la doble configuración del mismo ajuste, volcando la administración en un solo lado. Para clasificar la migración puede usarse Group Policy analytics.
• Para un desarrollador, la GPO del cliente forma parte de la especificación del entorno. Si se documentan las premisas como la directiva de ejecución, el firewall o la configuración de unidades y proxy, y se dispone de un procedimiento de verificación con gpresult, la mayoría de los casos de “solo falla en el cliente” dejan de ser temibles.

Artículos relacionados

• El firewall de Windows y las aplicaciones empresariales — las reglas de entrada se registran desde el instalador
• Administración de Windows Update tras la obsolescencia de WSUS — cómo elegir entre WUfB, Autopatch e Intune
• Directiva de ejecución de PowerShell y firma de scripts — guía práctica para dejar atrás la operación de “tapar con Bypass”
• Automatizar el kitting de PC con winget + PowerShell — convertir el manual de procedimientos en algo ejecutable
• Guía para dejar atrás la dependencia del modo IE
• Cuándo se necesitan realmente los privilegios de administrador en Windows: UAC, áreas protegidas y cómo distinguirlo en el diseño

Áreas de consultoría relacionadas

KomuraSoft LLC atiende la investigación de causas cuando una aplicación empresarial no funciona en un entorno de cliente administrado por GPO, la organización de los requisitos de implantación (directiva de ejecución, firewall, premisas de red) y la consultoría técnica sobre inventario de directivas y estrategia de uso combinado con Intune para responsables de sistemas que han heredado un entorno AD. Puede empezar desde una etapa tan temprana como “quiero que revisemos juntos el informe de gpresult”.

• Consultoría técnica y revisión de diseño
• Investigación de fallos y análisis de causas
• Desarrollo de aplicaciones Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Ejecuté gpupdate /force pero la configuración no se aplica. ¿Por qué?

Primero compruebe si esa configuración pertenece al tipo que "no se aplica mediante la actualización en segundo plano". La instalación de software orientada a usuarios y la redirección de carpetas solo se procesan al iniciar sesión, y la instalación de software orientada a equipos solo se procesa al arrancar, por lo que tras completar gpupdate suele hacer falta cerrar sesión (/logoff) o reiniciar (/boot). A continuación, genere un informe RSoP con gpresult /h y verifique si esa GPO figura entre las "GPO aplicadas" o si aparece entre las "GPO denegadas" con un motivo. Si la GPO está aplicada pero el comportamiento no cambia, sospeche que otra GPO con mayor prioridad está sobrescribiendo la misma configuración (gana la última procesada). El informe muestra la "GPO que prevalece" para cada configuración, por lo que puede identificar exactamente cuál está ganando.

¿Qué significa que gpresult muestre "denegada por filtro"?

Significa que esa GPO sí está entre los objetivos por su ubicación de vínculo, pero quedó excluida de la aplicación por el procesamiento de filtros. La causa más habitual es el filtrado de seguridad: para que se aplique una GPO, el usuario o el equipo debe tener los dos permisos "Leer" y "Aplicar directiva de grupo" sobre esa GPO. De forma predeterminada ambos permisos se conceden a Usuarios autentificados, pero si su organización restringe la aplicación a grupos concretos, un olvido al añadir el grupo o al incluir la cuenta de equipo provoca la denegación. Además, en las GPO orientadas a usuarios no basta con conceder ambos permisos solo al usuario objetivo: desde MS16-072, la directiva de usuario se obtiene con el contexto de seguridad del equipo, por lo que hay que dejar el permiso "Leer" (no hace falta "Aplicar") a Usuarios autentificados o a Equipos del dominio. También puede deberse a que no coincidan las condiciones de un filtro WMI, o a que la propia GPO tenga deshabilitada la parte de usuario o de equipo. El motivo de la denegación queda registrado tanto en el informe de gpresult como en el registro operativo de GroupPolicy.

¿Debo administrar con GPO o con Intune?

Lo básico es ajustarse a la infraestructura de identidad del dispositivo. Si predominan los equipos unidos a un AD local y conectados permanentemente a la red interna, la GPO es la opción más fiable y con mayor granularidad. Si aumentan los dispositivos unidos a Microsoft Entra o los equipos domésticos que no se conectan a un controlador de dominio, Intune (MDM/CSP), que puede llegar incluso fuera de la oficina, resulta más adecuado. En entornos híbridos donde coexisten ambos, configurar el mismo ajuste tanto en GPO como en MDM genera conflictos cuyo resultado no está garantizado, por lo que el principio es decidir, ajuste por ajuste, cuál de los dos lo administra y volcarse en uno solo. En la fase de estudiar la migración, importar las GPO existentes en Group Policy analytics de Intune permite clasificar qué configuraciones ya son compatibles con MDM y cuáles no lo son o están en desuso.

El contenido que configuré en la directiva de grupo local (gpedit.msc) se sobrescribe con la configuración del dominio. ¿Es así por diseño?

Sí, es el comportamiento previsto. La directiva de grupo se procesa en el orden local → sitio → dominio → OU (LSDOU), y lo procesado más tarde gana en caso de conflicto, por lo que la GPO local es la capa más débil. Si la GPO de dominio configura el mismo ajuste, el cambio local siempre queda sobrescrito. A la inversa, si el lado del dominio deja ese ajuste como "No configurado", el valor de la GPO local sí surte efecto. Aunque para pruebas quiera dar prioridad al ajuste local a toda costa, no existe forma de invertir este orden de prioridad en un PC unido al dominio, así que lo realista es crear una OU de pruebas y ajustar la GPO del lado del dominio, o bien usar un equipo de pruebas no unido al dominio.

La aplicación empresarial que desarrollamos no funciona solo en el entorno del cliente. ¿Hay forma de comprobar si la causa es una GPO?

El primer paso es pedir al administrador del cliente que ejecute gpresult /h report.html desde un símbolo del sistema con privilegios de administrador en el PC problemático y revisar el informe RSoP. Compruebe si hay aplicada alguna configuración que altere el comportamiento de la aplicación: detención de scripts por la directiva de ejecución, deshabilitación de la fusión de reglas locales del firewall, configuración de proxy o de asignación de unidades, etc. Junto con eso, revisar si en el Registro, bajo HKLM\Software\Policies y HKCU\Software\Policies, hay valores de directiva relacionados con el producto en cuestión permite detectar de forma sistemática las configuraciones forzadas procedentes de plantillas administrativas. Como medida preventiva desde el lado del desarrollo, conviene documentar en el manual de instalación los requisitos de los que depende la aplicación (directiva de ejecución, puertos de escucha, carpetas de escritura, etc.) y pedir al departamento de sistemas del cliente que los verifique antes de la implantación.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.