Guía práctica de la directiva de grupo (GPO) — cómo funciona, cómo comprobar la aplicación y cómo elegir entre GPO e Intune

«Cambié la GPO y no pasó nada». «Ejecuté gpupdate y el ajuste sigue igual». «La aplicación se ejecuta en el equipo de desarrollo pero no en los PC del cliente». Problemas como estos se investigan mucho mejor cuando se separa qué GPO están en el ámbito, qué ajuste gana y cuándo se procesó.

La directiva de grupo es el mecanismo que distribuye y administra la configuración de Windows en una organización. Que le digan que algo «se distribuye por GPO» no le dice qué está realmente en vigor en un PC o para un usuario. Hay que comparar la configuración del lado que distribuye con el resultado del lado que recibe.

Este artículo es una introducción práctica para el personal de sistemas de pymes que ha heredado un entorno AD, y para los desarrolladores que implementan aplicaciones de negocio en PC unidos al dominio. Cubre el orden de aplicación, cuándo surten efecto los ajustes, el diagnóstico con gpresult y el registro de eventos, ADMX y el almacén central, y cómo elegir entre GPO e Intune. Las explicaciones se basan en fuentes primarias a agosto de 2026.

Empiece por con lo que se está encontrando

Si es la primera lectura, recoja la terminología en el capítulo 2, entienda el mecanismo en los capítulos 3 y 4, y pase después a los pasos de comprobación del capítulo 5. Si está en medio de una investigación, empiece por el capítulo 5 y vuelva a las explicaciones de precedencia y de momento según lo pidan los resultados.

1. Primero la conclusión

«Qué ajuste gana» y «cuándo llega» son problemas distintos

La directiva de grupo se procesa en el orden local, sitio, dominio, OU (LSDOU), y cuando el mismo ajuste entra en conflicto, gana la última en escribir. La GPO local es la capa más débil. Dicho esto, bloquear la herencia y Aplicada cambian este flujo predeterminado.¹

La aplicación tiene dos formas: el procesamiento en primer plano al arrancar y al iniciar sesión, y la actualización en segundo plano a un intervalo predeterminado de unos 90 minutos más un desplazamiento aleatorio de 0 a 30 minutos. La actualización en segundo plano de los controladores de dominio es de 5 minutos de forma predeterminada. gpupdate /force vuelve a aplicar todos los ajustes; no es un comando universal que aplique también, en el acto, los ajustes que solo se procesan al iniciar sesión o al reiniciar.²³

Compruebe el resultado que llegó antes de seguir cambiando cosas

El diagnóstico empieza por el informe RSoP que produce gpresult /h. Compruebe las GPO aplicadas, las denegadas y sus motivos, y la GPO que gana para cada ajuste. Cuando hay que profundizar en fallos o retrasos de procesamiento, use el registro operativo de GroupPolicy.⁴⁵

Los ajustes de plantillas administrativas se escriben, por regla, en ubicaciones del Registro como Software\Policies, y las aplicaciones conscientes de la directiva dan a esos valores precedencia sobre los suyos. «No configurada» no escribe ningún valor. Algunos ajustes sí escriben fuera de las claves dedicadas, no obstante, de modo que cuando un valor permanece, compruebe dónde se escribió.⁶

Alinee el método de administración con las hipótesis de las que depende la aplicación

En un dominio, las definiciones ADMX se consolidan en el almacén central PolicyDefinitions de SYSVOL. Existe para que GPMC referencie un conjunto común de plantillas.⁷

Elija entre GPO e Intune según el fundamento de identidad del dispositivo y dónde se usa. En un entorno híbrido, evite configurar el mismo ajuste dos veces y decida quién posee cada área. Group Policy analytics es útil para clasificar ajustes antes de una migración.⁸⁹

También para los desarrolladores, GPO forma parte de la especificación del entorno. Los ajustes que cambian las hipótesis de una aplicación, como la directiva de ejecución, la fusión de reglas locales de firewall y la configuración de proxy y unidades, se distribuyen de forma central. Cuando algo «falla solo en el cliente», confirme esas hipótesis con el informe y los valores reales.¹⁰¹¹

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (29 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

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

La directiva de grupo es el mecanismo con el que un administrador define de forma central la configuración de Windows y la aplica a equipos y usuarios de destino. Un paquete de ajustes se llama GPO (objeto de directiva de grupo).

Empiece por separar «la GPO local administrada dentro del propio PC» de «la GPO de dominio distribuida desde AD».

Dónde viven los ajustes: local o dominio

Un PC de grupo de trabajo, uno que no está unido al dominio, procesa solo la GPO local.¹ Es decir, cuando se dice que una máquina está «administrada por GPO», en la práctica casi siempre se habla de una GPO de dominio.

flowchart TB
    accTitle: GPO que procesa un PC de grupo de trabajo y un PC unido al dominio
    accDescr: Un PC de grupo de trabajo procesa solo la GPO local, mientras que un PC unido al dominio procesa además las GPO de dominio distribuidas desde Active Directory
    pc{"¿Cómo está unido el PC?"}
    pc -->|Grupo de trabajo| wg["Procesa solo la GPO local"]
    pc -->|Unido al dominio| dom["GPO local más de dominio"]
    dom -.-> note["Las GPO en la práctica son casi todas de dominio"]

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

A qué se dirigen los ajustes: el PC o el usuario

Sea cual sea la GPO, su contenido se divide en dos ramas amplias.

• Configuración del equipo: ajustes que surten efecto para cualquiera que inicie sesión en ese PC. Se aplican al arrancar.
• Configuración de usuario: ajustes que surten efecto para ese usuario da igual en qué PC inicie sesión. Se aplican al iniciar sesión.

El eje de «¿este ajuste está atado al PC o a la persona?» aparece de forma constante en el orden de aplicación y en la comprobación de que un ajuste surtió efecto, ambos a continuación. Algunos elementos existen en ambas ramas, de modo que hágase el hábito de mirar las dos cada vez que busque un ajuste.

flowchart TB
    accTitle: Las dos ramas dentro de una GPO
    accDescr: Toda GPO tiene una rama Configuración del equipo y una rama Configuración de usuario, donde Configuración del equipo se aplica al arrancar y surte efecto para cualquiera que inicie sesión en ese PC, y Configuración de usuario se aplica al iniciar sesión y surte efecto da igual en qué PC inicie sesión el usuario
    gpo["Contenido de una GPO"] --> comp["Configuración del equipo"]
    gpo --> user["Configuración de usuario"]
    comp --> boot["Se aplica al arrancar"]
    user --> logon["Se aplica al iniciar sesión"]
    boot -.-> anyone["Surte efecto para quien inicie sesión"]
    logon -.-> anypc["Surte efecto en cualquier PC"]

Figura 2: Una GPO tiene dos ramas, Configuración del equipo atada al PC y Configuración de usuario atada a la persona.

3. Cómo funciona la aplicación — el «último en escribir gana» 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. La GPO local
2. Las GPO vinculadas al sitio
3. Las GPO vinculadas al dominio
4. Las GPO vinculadas a una OU (unidad organizativa) — se procesan de la OU más alta hacia abajo, y terminan las GPO de la OU que contiene directamente el equipo o usuario de destino

El nombre LSDOU sale de esas iniciales. Expresa el orden en que se procesan las directivas, no un orden «de mayor precedencia hacia abajo».

Cuando varias GPO configuran el mismo ajuste, gana la GPO procesada más tarde. Los ajustes que no entran en conflicto simplemente se combinan.¹

En este orden predeterminado, la GPO de la OU más cercana al destino es la más fuerte y la GPO local es la más débil. «Lo corregí en gpedit.msc y se revirtió» es exactamente este comportamiento funcionando según la especificación. Las excepciones que cambian la herencia se tratan en el apartado 3.2.

flowchart TB
    accTitle: El orden de procesamiento LSDOU y el último en escribir gana
    accDescr: Las GPO se procesan en el orden local, sitio, dominio, OU, y en un conflicto gana la GPO procesada más tarde, de modo que la GPO de la OU más cercana al destino 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 arriba abajo)"]
    ou --> win["En un conflicto gana la última en escribir"]
    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 procesan las directivas, y cuando el mismo ajuste entra en conflicto, gana la GPO procesada más tarde.

En el mismo lugar, gana el número de orden de vínculo más bajo

Cuando hay varias GPO vinculadas al mismo sitio, dominio u OU, compruebe el orden de vínculo en la pestaña «Objetos de directiva de grupo vinculados» de GPMC.

La GPO con el número más bajo se procesa la última y por tanto tiene la mayor precedencia. Es importante no leerlo como «un número más bajo significa que se procesa primero».¹

flowchart TB
    accTitle: Orden de vínculo cuando varias GPO están en el mismo lugar
    accDescr: Cuando hay varias GPO vinculadas al mismo sitio o dominio u OU, el orden de procesamiento lo decide el orden de vínculo en GPMC, y la GPO con el número más bajo se procesa la última y toma la mayor precedencia
    multi["Varias GPO en el mismo lugar"] --> tab["Lo decide el orden de vínculo en GPMC"]
    tab --> last["La GPO de número más bajo se procesa la última"]
    last --> win["Gana por última escritura y toma la mayor precedencia"]

Figura 4: En el mismo destino 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. Bloquear la herencia y Aplicada

Bloquear la herencia y Aplicada son los mecanismos que crean excepciones al orden predeterminado del apartado 3.1. Léalos separando dónde se establecen de qué detienen.¹

• Bloquear la herencia: se establece en un dominio o una OU, y detiene que se hereden GPO de arriba. Es la herramienta para «esta OU sola no debe recibir el estándar de toda la empresa».
• Aplicada (antes No anular): se establece en un vínculo de GPO, y hace que esa GPO se aplique siempre incluso donde la herencia está bloqueada más abajo, y evita que las GPO inferiores la sobrescriban. Cuando chocan bloquear la herencia y Aplicada, gana Aplicada.¹

flowchart TB
    accTitle: Cómo se relacionan bloquear la herencia y Aplicada
    accDescr: Bloquear la herencia detiene que se hereden GPO de arriba, pero una GPO aplicada se aplica siempre incluso donde la herencia está bloqueada más abajo y no la pueden sobrescribir las GPO inferiores
    upper["GPO de arriba"] --> blocked{"¿Herencia bloqueada más abajo?"}
    blocked -->|No| inherit["Se hereda tal cual"]
    blocked -->|Sí| enforced{"¿El vínculo de GPO está aplicado?"}
    enforced -->|No| stop["La herencia se detiene"]
    enforced -->|Sí| apply["Siempre se aplica"]
    apply -.-> noover["No la sobrescriben las GPO inferiores"]

Figura 5: Bloquear la herencia detiene la herencia de arriba, pero una GPO aplicada cruza el bloqueo y se aplica siempre.

Limite para qué usa Aplicada

Como Aplicada cambia el «último en escribir gana» predeterminado, usarla con liberalidad produce más resultados que no coinciden con la intuición incluso al leer el RSoP. La regla práctica es limitarla a cosas como ajustes de seguridad que de verdad deben mantenerse en toda la empresa.

Eso cubre la herencia y la precedencia. Si una GPO puede aplicarse a un destino se decide también por el filtrado de seguridad, que viene a continuación.

3.3. Filtrado de seguridad

La aplicación exige tanto Leer como Aplicar

Más allá del destino del vínculo, a quién se aplica una GPO también se puede acotar por GPO. El usuario o equipo de destino debe tener ambos permisos «Leer» y «Aplicar directiva de grupo» sobre esa GPO.¹³

De forma predeterminada, Usuarios autenticados, que incluye usuarios y equipos, tiene ambos permisos, de modo que todo lo que está bajo el destino del vínculo está en el ámbito. Acotar esto a un grupo de seguridad concreto es lo que hace el filtrado de seguridad.

El filtro se aplica a la GPO en su conjunto. No es un mecanismo para acotar ajustes individuales dentro de una GPO a destinos distintos.¹³

En las GPO orientadas al usuario, deje también el permiso de lectura del PC

Al acotar el destino, no quite Leer a Usuarios autenticados. Desde MS16-072 (2016), la directiva orientada al usuario se obtiene en el contexto de seguridad del equipo. Si el PC no puede leer la GPO, no se aplica aunque el usuario de destino tenga ambos permisos.¹⁴

Piense los permisos necesarios como dos cosas distintas.

• Dé al grupo de destino Leer más Aplicar directiva de grupo.
• Deje solo Leer a Usuarios autenticados o a Equipos del dominio. El permiso Aplicar no hace falta.¹⁴

flowchart TB
    accTitle: Cómo el filtrado de seguridad decide si se aplica una GPO
    accDescr: Para que se aplique una GPO, el usuario o el equipo de destino debe tener tanto el permiso Leer como el de Aplicar directiva de grupo, y una GPO orientada al usuario exige además que la cuenta de equipo pueda leerla
    target["Destino bajo el vínculo de GPO"] --> perm{"¿Leer y Aplicar ambos?"}
    perm -->|No| deny["Denegada por filtrado"]
    perm -->|Sí| usergpo{"¿GPO orientada al usuario?"}
    usergpo -->|No| apply["Se aplica"]
    usergpo -->|Sí| comp{"¿Puede leerla el equipo?"}
    comp -->|Sí| apply
    comp -->|No| deny2["No se aplica (MS16-072)"]

Figura 6: La aplicación exige tanto Leer como Aplicar directiva de grupo, y una GPO orientada al usuario exige además que la cuenta de equipo tenga Leer.

Tras cambiar un grupo, confirme con un token nuevo

Apuntar al objeto incorrecto — «el ajuste está orientado al equipo, pero solo se añadió el usuario al grupo» — es un tropiezo habitual. Compruebe primero si el ajuste está del lado del equipo o del usuario.

El otro es «los quité del grupo y sigue aplicándose». La pertenencia se evalúa a partir del token de seguridad construido al iniciar sesión, de modo que esperar simplemente una actualización en segundo plano no cambia nada.

El cambio de grupo de un usuario llega al filtro tras un cierre de sesión e inicio de sesión, y el de un equipo tras un reinicio, una vez construido un token nuevo.

flowchart TB
    accTitle: Cuánto tarda un cambio de grupo en llegar al filtro
    accDescr: La pertenencia a un grupo se evalúa a partir del token de seguridad construido al iniciar sesión, de modo que el cambio de un usuario llega al filtro solo tras volver a iniciar sesión y el de un equipo solo tras un reinicio que construye un token nuevo
    change["Cambiar los miembros de un grupo"] --> old["No se refleja mientras permanece el token antiguo"]
    old --> u["El usuario vuelve a iniciar sesión"]
    old --> c["El equipo se reinicia"]
    u --> token["Se evalúa con el token nuevo"]
    c --> token
    token --> ok["Se refleja en el filtro"]
    old -.-> bg["Una actualización en segundo plano no lo resuelve"]

Figura 7: Un cambio de grupo llega al filtro solo cuando un cierre de sesión o un reinicio construye un token nuevo.

Una aplicación para PC compartidos: procesamiento de bucle invertido

En PC compartidos y servidores de Escritorio remoto, a veces se quiere «cambiar la Configuración de usuario para todos los que inicien sesión en este PC». El modo especial para eso es el procesamiento de bucle invertido.

Aplica ajustes de usuario según la ubicación del equipo, y tiene dos modos, Reemplazar y Combinar. Es una característica avanzada usada en terminales de quiosco y PC de aula, y este artículo no hace más que señalar que existe.¹⁵

flowchart TB
    accTitle: La idea del procesamiento de bucle invertido
    accDescr: El procesamiento de bucle invertido es un modo especial que aplica Configuración de usuario según la ubicación del equipo, tiene los dos modos Reemplazar y Combinar, y se usa donde todas las personas que inician sesión deben recibir los mismos ajustes de usuario, como PC compartidos y terminales de quiosco
    shared["PC compartidos, terminales de quiosco y similares"] --> lb["Procesamiento de bucle invertido"]
    lb --> base["Lo decide la ubicación del equipo"]
    base --> rep["Modo Reemplazar"]
    base --> mrg["Modo Combinar"]
    lb -.-> aim["Surte efecto para todos los que inician sesión"]

Figura 8: El procesamiento de bucle invertido es un modo especial que aplica Configuración de usuario según la ubicación del equipo, y tiene los dos modos Reemplazar y Combinar.

4. Cuándo surten efecto los ajustes — procesamiento en primer plano y actualización en segundo plano

Tras cambiar un ajuste, puede que simplemente no haya llegado aún el momento de aplicarlo. Aquí, separe si el dispositivo puede alcanzar un DC de cuándo se procesa ese ajuste concreto.²

Separe el arranque y el inicio de sesión de las actualizaciones mientras la máquina está en marcha

Primero, el dispositivo tiene que poder alcanzar un DC

En un dispositivo en marcha que puede alcanzar un controlador de dominio, los ajustes que admiten actualización en segundo plano se extienden por la flota en unas dos horas de forma predeterminada. No llegan a dispositivos sin conexión, ni a portátiles sacados de la oficina sin VPN, hasta la siguiente vez que el dispositivo conecte con un DC.

Los ajustes que solo aplica el procesamiento en primer plano exigen, además, esperar un arranque o un inicio de sesión.

La diferencia entre gpupdate y /force

Cuando corre prisa, ejecute gpupdate en el PC de destino. De forma normal aplica solo los ajustes que cambiaron; al añadir /force vuelve a aplicar todos los ajustes, hayan cambiado o no.³

rem Refresh only what changed (normally this is enough)
gpupdate

rem Reapply every setting (when you suspect the cached state)
gpupdate /force

flowchart TB
    accTitle: Alcance al DC y cómo llegan los ajustes
    accDescr: En un dispositivo en marcha que puede alcanzar un controlador de dominio, los ajustes que admiten actualización en segundo plano se extienden en unas dos horas, pero no llegan a un dispositivo sin conexión o a un portátil sacado de la oficina sin VPN hasta que vuelva a conectar con un DC
    pc{"¿Puede alcanzar un DC?"}
    pc -->|Sí| ok["Se extiende en unas dos horas"]
    pc -->|No| ng["No llega hasta que conecte"]
    ng -.-> ex["Dispositivos sin conexión y portátiles fuera de la oficina sin VPN"]

Figura 9: Un dispositivo en marcha que puede alcanzar un DC recibe los ajustes en unas dos horas, mientras que un dispositivo sin conexión no recibe nada hasta que vuelva a conectar con un DC.

Ni /force puede saltarse el procesamiento en primer plano

La instalación de software orientada al usuario y la redirección de carpetas solo se procesan al iniciar sesión, y la instalación de software orientada al equipo solo al arrancar.³

La opción /logoff de gpupdate cierra sesión tras la actualización y /boot reinicia después. Cuando añadir /force no cambia nada, compruebe si el ajuste es de los que exigen un inicio de sesión o un reinicio.³

flowchart TB
    accTitle: Los caminos por los que un ajuste surte efecto
    accDescr: Un cambio de GPO llega en el intervalo predeterminado de unos 90 minutos más un desplazamiento de 0 a 30 minutos si el ajuste admite actualización en segundo plano, mientras que un ajuste que solo se aplica por procesamiento en primer plano tiene que esperar un arranque o un inicio de sesión, y aun gpupdate necesita /logoff o /boot para los ajustes solo de primer plano cuando corre prisa
    change["Cambiar una GPO"] --> kind{"¿Admite actualización en segundo plano?"}
    kind -->|Sí| bg["Se actualiza en unos 90 minutos más 0 a 30"]
    kind -->|No| fg["Se aplica al arrancar o al iniciar sesión"]
    bg --> done["Surte efecto"]
    fg --> done
    rush["Cuando corre prisa"] -.-> upd["Ejecutar gpupdate"]
    upd -.-> force["/force vuelve a aplicar todo"]
    upd -.-> reboot["El primer plano necesita /logoff o /boot"]

Figura 10: La actualización en segundo plano entrega solo los ajustes que la admiten, y los ajustes aplicados solo por procesamiento en primer plano siguen necesitando un cierre de sesión o un reinicio tras gpupdate.

5. Diagnóstico cuando un ajuste no surte efecto — gpresult, el registro de eventos y el Registro

Las herramientas tienen papeles distintos. gpresult muestra el resultado de la aplicación, el registro operativo muestra el curso del procesamiento y el Registro muestra los valores reales que se escribieron. En lugar de volver a cambiar ajustes de inmediato, acote la causa a partir del resultado.

5.1. Compruebe el RSoP con gpresult /h

El resultado final de varias GPO superpuestas se llama RSoP (Resultant Set of Policy, resultado de conjunto de directivas). La herramienta estándar gpresult produce un informe HTML desde un símbolo del sistema elevado, que es más fácil de leer.⁴⁵

En el ejemplo siguiente, cree la carpeta de salida C:\temp antes de ejecutarlo. Al leer el informe, confirme también que es el resultado del PC y del usuario que quiere investigar.

rem Escribir un informe HTML del RSoP del usuario y del equipo
gpresult /h C:\temp\gp-report.html /f

rem Para comprobar solo el resumen en la consola
gpresult /r
gpresult /scope computer /r

No se detenga en «se aplicó»

En el informe, mire las tres cosas siguientes, en orden. Aunque la GPO que quiere esté en la lista, el ajuste no tendrá el valor que espera si otra GPO lo sobrescribe.

1. La lista de GPO aplicadas — si está la GPO que quiere
2. La lista de GPO denegadas y los motivos — el motivo por el que no se aplicó, como filtrado de seguridad, un filtro WMI o una GPO vacía⁵
3. La GPO que gana para cada ajuste — el valor de qué GPO decidió el ajuste que le importa. Si gana otra GPO, vuelva a las reglas de precedencia del capítulo 3

flowchart TB
    accTitle: Las tres cosas que mirar primero en un informe RSoP
    accDescr: En un informe de gpresult, primero compruebe si la GPO que quiere está en la lista de GPO aplicadas, luego compruebe la lista de GPO denegadas y los motivos, y por último use la GPO que gana para cada ajuste para identificar de quién es el valor que ganó
    rep["Abrir el informe RSoP"] --> one["1. Lista de GPO aplicadas"]
    one --> two["2. GPO denegadas y motivos"]
    two --> three["3. GPO que gana por ajuste"]
    three -.-> review["Revisar si gana otra GPO"]

Figura 11: Lea un informe RSoP en el orden GPO aplicadas, GPO denegadas y motivos, y la GPO que gana para cada ajuste.

5.2. El registro operativo de GroupPolicy

Seguir fallos y retrasos de procesamiento

Los fallos que gpresult solo no revela, y los problemas en los que el procesamiento tarda demasiado, se comprueban en el registro operativo de GroupPolicy del Visor de eventos.

Su ubicación es Registros de aplicaciones y servicios > Microsoft > Windows > GroupPolicy > Operational. El nombre del registro es Microsoft-Windows-GroupPolicy/Operational, y registra desde el inicio hasta el final del procesamiento, las listas de GPO aplicadas y denegadas, y los motivos de denegación.⁵

Acote a una sola ejecución de procesamiento con ActivityID

A cada ejecución del procesamiento de directivas se le asigna un ActivityID único. El procedimiento que documenta Microsoft es recoger el ActivityID de una advertencia o un error en el registro Sistema y usar una vista personalizada para acotar a los eventos de esa misma ejecución. Así se sigue una ejecución de principio a fin sin mezclar registros de otra.⁵

flowchart TB
    accTitle: Cómo acotar el registro operativo de GroupPolicy
    accDescr: A cada ejecución del procesamiento de directivas se le asigna un ActivityID único en el registro operativo de GroupPolicy, de modo que recoja el ActivityID de una advertencia o un error en el registro Sistema y use una vista personalizada para acotar la lectura a los eventos de esa ejecución
    sys["Advertencia o error en el registro Sistema"] --> aid["Recoger el ActivityID"]
    aid --> cv["Acotar con una vista personalizada"]
    cv --> one["Leer los eventos de una ejecución de procesamiento"]
    one -.-> rec["Listas de GPO aplicadas y denegadas con motivos"]

Figura 12: En el registro operativo, recoja el ActivityID del registro Sistema y use una vista personalizada para leer solo una ejecución del procesamiento de directivas.

5.3. La relación con las claves Policies del Registro

Las directivas de plantillas administrativas, tratadas en el capítulo siguiente, se escriben al final como valores del Registro. Por regla, se escriben en las siguientes claves de directiva dedicadas.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Configuración del equipo; la ubicación recomendada)
• HKEY_CURRENT_USER\Software\Policies (Configuración de usuario; la ubicación recomendada)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies y HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Los valores de directiva se leen antes que los ajustes propios de la aplicación

Una aplicación consciente de la directiva se comporta así: lee primero la clave Policies, usa ese valor si hay uno, y si no hay ninguno cae a su propio ajuste o a un valor predeterminado. Una directiva dejada en «No configurada» no escribe ningún valor en el Registro.⁶

Es decir, una plantilla administrativa que usa las claves de directiva dedicadas no reescribe el ajuste propio de la aplicación y deja un «tatuaje»; coloca un valor impuesto en una ubicación aparte. Deje de configurarla y la aplicación vuelve a seguir su propio ajuste.

flowchart TB
    accTitle: Precedencia entre un valor de directiva y un ajuste de la aplicación
    accDescr: Una aplicación consciente de la directiva lee primero la clave Policies y usa ese valor si hay uno, de lo contrario usa su propio ajuste o un valor predeterminado, y una directiva dejada en No configurada no escribe nada en el Registro
    app["Una aplicación consciente de la directiva lee un ajuste"] --> haspol{"¿Hay un valor en la clave Policies?"}
    haspol -->|Sí| pol["Gana el valor de directiva"]
    haspol -->|No| pref["Usa su propio ajuste o un valor predeterminado"]
    notconf["Una directiva No configurada"] -.-> nowrite["No escribe nada en el Registro"]

Figura 13: Una directiva no reescribe el ajuste propio de la aplicación; en su lugar se lee con mayor precedencia un valor impuesto colocado en otra parte.

Cuidado con los ajustes que escriben fuera de las claves dedicadas y dejan valores atrás

No toda directiva escribe en una clave dedicada. «Habilitar rutas largas de Win32», por ejemplo, escribe en LongPathsEnabled bajo HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. Las plantillas de generaciones antiguas y de terceros también incluyen algunas que escriben en rutas arbitrarias.

Los ajustes de este tipo dejan el valor atrás incluso después de dejar de configurar la directiva. Compruebe en qué clave escribe el ajuste que le importa, usando la definición ADMX, el texto explicativo del ajuste y el informe de gpresult.

Los valores escritos fuera de las claves dedicadas por un script o por las Preferencias de directiva de grupo son valores ordinarios del Registro también. A diferencia de las claves de directiva dedicadas, trátelos como valores que permanecen después de dejar de configurarlos.

Compruebe dónde se escribió realmente el valor

Empiece por mirar los valores reales bajo las claves Policies. Pero no concluya que «GPO no influye aquí» solo porque no hay nada; compruebe también si el ajuste es de los que escriben fuera de las claves dedicadas. Los comandos siguientes son un ejemplo de mirar bajo Policies, donde escriben la mayoría de las directivas.

# Ejemplo de comprobar valores distribuidos por directiva de forma directa (la mayoría de las directivas escriben bajo Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Pasos de diagnóstico cuando un ajuste no surte efecto
    accDescr: Primero compruebe las GPO aplicadas y denegadas en el informe RSoP de gpresult, luego acote el registro operativo de GroupPolicy por ActivityID si no basta, y confirme los valores distribuidos de forma directa en las claves Policies del Registro
    start["El ajuste no surte efecto"] --> rsop["Comprobar el RSoP con gpresult /h"]
    rsop --> found{"¿Ve las aplicadas y los motivos de denegación?"}
    found -->|Sí| fix["Revisar precedencia y filtrado"]
    found -->|No| oplog["Leer el registro operativo de GroupPolicy"]
    oplog -.-> aid["Acotar a una ejecución con ActivityID"]
    rsop -.-> reg["Comprobar los valores reales en las claves Policies"]

Figura 14: El diagnóstico avanza de forma mecánica desde gpresult /h, al registro operativo de GroupPolicy cuando no basta, y a una comprobación directa de las claves Policies para los valores reales.

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

ADMX guarda las definiciones, ADML las cadenas de presentación

Los elementos listados bajo «Plantillas administrativas» en GPMC tienen las definiciones de ajuste escritas en archivos ADMX y las cadenas de presentación por idioma en archivos ADML.

Cada PC tiene las definiciones que se incluyen con el sistema operativo en C:\Windows\PolicyDefinitions, y las herramientas de administración las leen para construir la pantalla de ajustes.⁷

En un dominio, referencie un almacén central compartido

Para la operación de dominio, cree una carpeta PolicyDefinitions bajo SYSVOL en un DC. Un ejemplo es \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions.

El contenido se replica a todos los DC del dominio, y las herramientas de directiva de grupo referencian el almacén central de forma predeterminada. Existe para evitar el problema de que las versiones de las plantillas difieran entre máquinas de administración y los elementos visibles no coincidan. Los archivos ADML van en subcarpetas por idioma como ja-JP.⁷

flowchart TB
    accTitle: Cómo funciona el almacén central
    accDescr: Crear una carpeta PolicyDefinitions bajo SYSVOL en un controlador de dominio replica su contenido a todos los controladores de dominio y hace que las herramientas de directiva de grupo referencien el almacén central de forma predeterminada, de modo que las definiciones ya no difieren entre máquinas de administración
    create["Crearlo bajo SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["Replicado a todos los DC"]
    cs --> ref["Las herramientas de GP lo referencian de forma predeterminada"]
    ref -.-> benefit["Desaparecen las discrepancias de definición entre máquinas"]
    cs -.-> adml["Los archivos ADML van a carpetas por idioma"]

Figura 15: La carpeta PolicyDefinitions de SYSVOL se replica a todos los controladores de dominio, y las herramientas de directiva de grupo la referencian de forma predeterminada.

Prepare las actualizaciones en una carpeta de trabajo y luego cambie

Microsoft distribuye archivos ADMX para las versiones nuevas de Windows, versión a versión. Lo que se actualiza es el almacén central. Reemplazar C:\Windows\PolicyDefinitions en cada PC con la versión descargada no está admitido.⁷

Actualice un almacén existente recorriendo los pasos siguientes en lugar de sobrescribir la carpeta de producción de forma directa.

1. Prepare una carpeta de trabajo con un nombre de versión, como PolicyDefinitions-24H2.
2. Reúna el conjunto ADMX completo del sistema operativo y de aplicaciones como Office y Edge.
3. Cambie el nombre del PolicyDefinitions actual a algo como PolicyDefinitions-23H2 para apartarlo.
4. Cambie el nombre de la carpeta de trabajo a PolicyDefinitions para que se referencie como producción.⁷

La carpeta que se referencia es la que se llama PolicyDefinitions. Colocar archivos en una carpeta con nombre de versión no tiene ningún efecto. Conservar la carpeta antigua apartada permite revertir si algo va mal.⁷

flowchart TB
    accTitle: Pasos para actualizar el almacén central
    accDescr: Para actualizar, reúna el conjunto ADMX completo del sistema operativo y de las aplicaciones en una carpeta de trabajo con nombre de versión, cambie el nombre de la carpeta actual para apartarla, luego cambie el nombre de la carpeta de trabajo al nombre de producción PolicyDefinitions, y revierta a la carpeta que apartó si ocurre un problema
    work["Carpeta de trabajo con nombre de versión"] --> gather["Reunir los conjuntos del sistema operativo y de las aplicaciones"]
    gather --> evac["Cambiar el nombre de la actual y apartarla"]
    evac --> rename["Cambiar el nombre de la de trabajo al nombre de producción"]
    rename --> live["Referenciada como producción"]
    live -.-> back["Revertir a la carpeta antigua si hay problemas"]

Figura 16: Para una actualización, reúna el conjunto completo en una carpeta de trabajo, aparte la actual y promocione cambiando el nombre.

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

GPO ya no es la única opción para la administración de configuración de dispositivos Windows. MDM, del que Intune es el representante, configura los ajustes del sistema operativo a través de un mecanismo llamado CSP (Configuration Service Provider). Aquí hay una tabla de decisión para elegir alrededor de cuál construir.

Decida según el fundamento de identidad del dispositivo y su ubicación

La base es si el dispositivo se fundamenta en AD o en Microsoft Entra, y dónde se usa. GPO es fiable para PC de oficina fijos unidos al dominio de AD local, mientras que las GPO de dominio nunca llegan a un PC móvil unido a Entra.

Lo importante es no tratar los dispositivos de oficina y los de fuera como si tuvieran las mismas condiciones de alcance.

En un entorno híbrido, decida quién posee cada ajuste

Incluso en pymes, es habitual una operación híbrida que combina la unión al dominio con la inscripción en Intune. Lo que hay que evitar aquí es configurar el mismo ajuste por GPO y por MDM.

Policy CSP incluye MDMWinsOverGP, que da precedencia a MDM en un conflicto. Se aplica, no obstante, solo a las directivas correspondientes dentro de Policy CSP. Configure dos veces un ajuste que no está bajo ese control y no hay garantía de cuál gana. Microsoft también desaconseja la configuración duplicada.⁸

El principio es decidir «esta área es GPO, aquella es Intune» y comprometer cada área con uno de ellos.

flowchart TB
    accTitle: Elegir entre GPO e Intune
    accDescr: GPO encaja en dispositivos cuyo fundamento de identidad es AD local y que permanecen en la oficina, Intune encaja en dispositivos unidos a Entra y fuera de la oficina, y en un entorno híbrido se evita configurar el mismo ajuste dos veces y se compromete cada área de ajuste con un lado
    q{"¿Fundamento de identidad y ubicación?"}
    q -->|Unido a AD y en la oficina| gpo["GPO es fiable y de grano fino"]
    q -->|Unido a Entra o fuera de la oficina| intune["Intune llega a los dispositivos fuera de la oficina"]
    q -->|Híbrido| split["Comprometer cada área con un lado"]
    split -.-> warn["La configuración duplicada no tiene resultado garantizado"]
    split -.-> ana["Usar Group Policy analytics para clasificar"]

Figura 17: Elija según el fundamento de identidad del dispositivo y su ubicación, y en un entorno híbrido no configure el mismo ajuste por GPO y por MDM.

Use Group Policy analytics para clasificar antes de mover

El punto de entrada para plantearse una migración es Group Policy analytics de Intune. Importe GPO exportadas como XML desde GPMC y analiza, ajuste a ajuste, qué admite MDM, qué está en desuso y qué no se puede admitir. Los ajustes admitidos se pueden migrar a una directiva de catálogo de configuración de Intune.⁹

Úselo no como «una herramienta que lo mueve todo», sino como una herramienta para clasificar qué se puede mover, qué no y qué hay que dejar.

La titularidad de la administración de Windows Update se está reorganizando en el mismo contexto. Vea también «Administración de Windows Update tras el desuso de WSUS».

flowchart TB
    accTitle: Clasificar con Group Policy analytics
    accDescr: Importar en Group Policy analytics GPO exportadas como XML desde GPMC clasifica cada ajuste según si MDM lo admite o si está en desuso o no se admite, y los ajustes admitidos se pueden migrar a una directiva de catálogo de configuración
    exp["Exportar como XML desde GPMC"] --> imp["Importar en analytics"]
    imp --> ana["Analizar la admisión por ajuste"]
    ana --> ok["Admitido por MDM"]
    ana --> dep["En desuso o no admitido"]
    ok --> mig["Migrar a una directiva de catálogo de configuración"]

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

8. Trampas desde el punto de vista del desarrollador — la GPO del cliente cambia cómo se comporta la aplicación

Por último, lo que hay que tener presente desde la posición de Custom Software Development. Las GPO del cliente reescriben en silencio las hipótesis de las que depende la aplicación. Junto con firewalls y antivirus, GPO es un sospechoso habitual detrás de «en el equipo de desarrollo funciona pero en el cliente no». Aquí hay ejemplos de la práctica.

La directiva de ejecución de PowerShell

La directiva de ejecución se puede configurar de forma central por GPO, y los ámbitos MachinePolicy y UserPolicy que vienen de GPO siempre tienen precedencia sobre los valores establecidos en local o por proceso.¹⁰ Si un instalador o un script de operación se construye sobre la hipótesis de que «añadir -ExecutionPolicy Bypass debería hacerlo ejecutar», ni siquiera arranca bajo administración por GPO. Para los detalles, vea «Directiva de ejecución de PowerShell y firma de scripts».

Fusión de reglas locales de firewall desactivada

En entornos donde el firewall se administra de forma central por GPO o Intune, la fusión de reglas locales (AllowLocalPolicyMerge) se puede desactivar por perfil. Donde está desactivada, las reglas de entrada que un instalador registró en local existen pero no se aplican.¹¹ Este es un punto que hay que comprobar sin falta antes de implementar una aplicación de tipo servidor, y se trata en detalle en «Windows Firewall y las aplicaciones de negocio».

Asignaciones de unidades, proxies y otra configuración del entorno

Las asignaciones de unidades de red, las impresoras y similares se suelen distribuir mediante Preferencias de directiva de grupo.¹⁶ Hipótesis de entorno como «debería haber una unidad Z» o «el proxy debería ser una conexión directa» se vienen abajo según qué usuario inicie sesión y a qué OU pertenezca el PC. Otra cosa que las aplicaciones residentes pasan por alto con facilidad es que los ajustes distribuidos por Configuración de usuario, de forma natural, no se aplican a las cuentas con las que se ejecutan los servicios y las tareas programadas.

El ajuste no se puede devolver al estado anterior

Los ajustes que vienen de plantillas administrativas suelen volverse imposibles de cambiar desde la interfaz de usuario; el elemento queda atenuado. El hecho de que «se arreglará si hace que el cliente cambie el ajuste» no funcione tiene consecuencias para cómo se diseña el plan de respuesta.

flowchart TB
    accTitle: Las hipótesis que cambia la GPO del cliente
    accDescr: Las GPO del cliente cambian las hipótesis de una aplicación al imponer la directiva de ejecución, desactivar la fusión de reglas locales de firewall, distribuir asignaciones de unidades y ajustes de proxy, y dejar al usuario sin poder devolver los ajustes, que es una razón de que una aplicación falle solo en el cliente
    gpo["Las GPO del cliente"] --> ep["Directiva de ejecución impuesta"]
    gpo --> fw["Fusión de reglas locales desactivada"]
    gpo --> env["Distribución de unidades y proxy"]
    gpo --> lock["Los ajustes no se pueden devolver"]
    ep --> sym["Una razón de que falle solo en el cliente"]
    fw --> sym
    env --> sym
    lock --> sym

Figura 19: Las GPO del cliente reescriben en silencio las hipótesis de una aplicación, incluida la directiva de ejecución, el firewall y la configuración del entorno.

Decida de antemano qué comprueban los desarrolladores antes de la implementación y durante un incidente

Hay tres preparativos que hacer.

Dónde trazar la línea de los privilegios se trata en «¿Cuándo se necesitan realmente privilegios de administrador en Windows?». GPO no es el enemigo; forma parte de la especificación del entorno. Trátela como una especificación y alinee los elementos a confirmar con el administrador, y el diagnóstico puede avanzar de forma mecánica.

flowchart TB
    accTitle: Los tres preparativos del lado del desarrollo
    accDescr: Los tres preparativos del lado del desarrollo son documentar las hipótesis de entorno de las que depende la aplicación como requisitos de implementación y pedir al personal de TI del cliente que las confirme antes de la implementación, comprobar el informe gpresult y los valores reales en las claves Policies durante un problema, y separar en el diseño el procesamiento que necesita privilegios de administrador
    dev["Preparación del lado del desarrollo"] --> doc["1. Documentar las hipótesis de entorno"]
    dev --> chk["2. Confirmar con gpresult y valores reales"]
    dev --> priv["3. Separar las necesidades de privilegios en el diseño"]
    doc -.-> ask["Pedirlo al personal de TI del cliente antes de la implementación"]

Figura 20: Los tres preparativos del lado del desarrollo son documentar las hipótesis de entorno, confirmar con gpresult y valores reales, y separar las necesidades de privilegios de administrador en el diseño.

9. Resumen

• La directiva de grupo es un mecanismo que procesa los ajustes por GPO en el orden local, sitio, dominio, OU (LSDOU), y los conflictos los decide el último en escribir. La GPO de la OU más cercana al destino es la más fuerte y la GPO local es la capa más débil.
• Bloquear la herencia, Aplicada y el filtrado de seguridad permiten controlar el flujo predeterminado. Aplicada gana también a bloquear la herencia, así que no la use en exceso.
• La aplicación tiene dos formas: el procesamiento en primer plano al arrancar y al iniciar sesión, y una actualización en segundo plano a un intervalo predeterminado de unos 90 minutos más un desplazamiento aleatorio. gpupdate /force vuelve a aplicar todos los ajustes, y no tiene efecto en los que solo se procesan al iniciar sesión o al reiniciar.
• Cuando un ajuste no surte efecto, diagnostique de forma mecánica en el orden gpresult /h, luego el registro operativo de GroupPolicy, luego las claves Policies del Registro. Las GPO denegadas vienen con un motivo.
• Las definiciones de plantillas administrativas viven en archivos ADMX y ADML, y en un dominio se consolidan en el almacén central de SYSVOL. Para actualizar, cambie el lado del almacén central en lugar de reemplazar el PolicyDefinitions local.
• Decida entre GPO e Intune según el fundamento de identidad del dispositivo y su ubicación, y en un entorno híbrido evite configurar el mismo ajuste dos veces y comprometa cada área con un propietario. Group Policy analytics es útil para clasificar una migración.
• Para los desarrolladores, las GPO del cliente forman parte de la especificación del entorno. Documente las hipótesis, como la directiva de ejecución, el firewall y la configuración de unidades y proxy, y construya la práctica de confirmarlas con gpresult, y la mayoría de los casos de «falla solo en el cliente» dejan de dar miedo.

Artículos relacionados

• Windows Firewall y las aplicaciones de negocio — registrar reglas de entrada desde el instalador
• Administración de Windows Update tras el desuso 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 de «tapar con Bypass»
• Automatizar el aprovisionamiento de PC con winget + PowerShell — hacer ejecutable el runbook
• Una guía para dejar de depender del modo IE
• ¿Cuándo se necesitan realmente privilegios de administrador en Windows? - UAC, áreas protegidas y cómo distinguirlo por diseño

Ámbitos de consulta relacionados

KomuraSoft LLC se ocupa de la investigación de causas cuando una aplicación de negocio falla en un entorno de cliente bajo administración por GPO, de ordenar requisitos de implementación como la directiva de ejecución, el firewall y las hipótesis de red, y de consultoría técnica sobre inventarios de directivas y estrategia de coexistencia con Intune para el personal de sistemas que ha heredado un entorno AD. Empezar por algo como «lea este informe de gpresult conmigo» no es ningún problema.

• Consultoría técnica y revisión de diseño
• Investigación de errores y análisis de causa raíz
• Desarrollo de aplicaciones para 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 el ajuste sigue sin aplicarse. ¿Por qué?

Primero compruebe si el ajuste es de los que una actualización en segundo plano nunca aplica. La instalación de software orientada al usuario y la redirección de carpetas solo se procesan al iniciar sesión, y la instalación de software orientada al equipo solo al arrancar, de modo que tras gpupdate hace falta un cierre de sesión (/logoff) o un reinicio (/boot). A continuación, genere un informe RSoP con gpresult /h y compruebe si esa GPO aparece en la lista de GPO aplicadas, y si aparece en la lista de GPO denegadas con un motivo. Si está aplicada pero el comportamiento no cambia, sospeche que otra GPO con mayor precedencia está sobrescribiendo el mismo ajuste (gana la última en escribir). El informe muestra la GPO que gana para cada ajuste, de modo que puede clavar exactamente cuál está ganando.

¿Qué significa Denegada (filtrado) en un informe de gpresult?

Significa que la GPO está en el ámbito por su ubicación de vínculo, pero el filtrado la excluyó de la aplicación. La causa más habitual es el filtrado de seguridad: para que se aplique una GPO, el usuario o el equipo debe tener tanto el permiso Leer como el de Aplicar directiva de grupo sobre esa GPO. De forma predeterminada ambos se conceden a Usuarios autenticados, pero si los restringe a grupos concretos, una pertenencia de grupo que falta o una cuenta de equipo olvidada se traduce en denegación. En las GPO orientadas al usuario, conceder ambos permisos al usuario de destino no basta. Desde MS16-072, la directiva de usuario se obtiene en el contexto de seguridad del equipo, de modo que hay que dejar Leer (Aplicar no hace falta) a Usuarios autenticados o a Equipos del dominio. Otras causas son un filtro WMI cuya condición no coincide, o que el lado de usuario o de equipo de la GPO esté deshabilitado. El motivo de la denegación queda registrado tanto en el informe de gpresult como en el registro operativo de GroupPolicy.

¿Hay que administrar los dispositivos con GPO o con Intune?

La regla básica es coincidir con el fundamento de identidad del dispositivo. Si los dispositivos están unidos sobre todo al dominio de AD local y permanecen conectados a la red interna, GPO es la opción más fiable y de mayor granularidad. Si crece el número de dispositivos unidos a Microsoft Entra, o de equipos de teletrabajo que nunca conectan con un controlador de dominio, Intune (MDM/CSP), que entrega la configuración también fuera de la oficina, encaja mejor. En un entorno híbrido donde coexisten ambos, configurar el mismo ajuste por GPO y por MDM crea un conflicto sin resultado garantizado, de modo que el principio es decidir, área de ajuste por área, quién lo administra y comprometerse con uno. Cuando empiece a plantearse la migración, importar las GPO actuales en Group Policy analytics de Intune permite clasificar los ajustes en los que MDM ya admite y los no admitidos o en desuso.

Un ajuste que configuré en el Editor de directivas de grupo local (gpedit.msc) lo sobrescribe el ajuste de dominio. ¿Es el diseño?

Sí, es el diseño. La directiva de grupo se procesa en el orden local, sitio, dominio, OU (LSDOU), y gana la GPO que se procesa más tarde en un conflicto, lo que hace de la GPO local la capa más débil. Si una GPO de dominio configura el mismo ajuste, el cambio local se sobrescribe siempre. A la inversa, si el lado de dominio deja ese ajuste en No configurada, el valor de la GPO local se mantiene. Incluso cuando de verdad quiere que el ajuste local tenga precedencia para una prueba, no hay forma de invertir este orden de precedencia en un PC unido al dominio, de modo que los enfoques realistas son crear una OU de prueba y ajustar la GPO del lado de dominio, o usar un equipo de prueba no unido al dominio.

Una aplicación de negocio que desarrollamos falla solo en el entorno del cliente. ¿Hay forma de comprobar si la causa es GPO?

El primer paso es pedir al administrador del cliente que ejecute gpresult /h report.html desde un símbolo del sistema elevado en el PC afectado y revisar el informe RSoP. Busque ajustes que cambien cómo se comporta la aplicación: scripts bloqueados por la directiva de ejecución, fusión de reglas locales de firewall desactivada, o configuración de proxy y asignaciones de unidades. También ayuda comprobar si hay valores de directiva del producto correspondiente escritos bajo HKLM\Software\Policies y HKCU\Software\Policies en el Registro, lo que saca a la luz de forma mecánica cualquier ajuste impuesto que venga de plantillas administrativas. Del lado del desarrollo, la preparación que se puede hacer es documentar las hipótesis de las que depende la aplicación, como la directiva de ejecución, los puertos de entrada y las carpetas en las que escribe, en la guía de implementación, y pedir al personal de TI del cliente que las confirme antes de implementarla.

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.