Directiva de grupo

Optimización del rendimiento de directiva de grupo

Darren Mar-Elia

Resumen:

• Objetos de directiva de grupo monolíticos y funcionales
• Cómo procesar las entradas de directiva de grupo
• Qué sucede cuando se producen cambios de directiva de grupo

Con frecuencia me suelen plantear esta pregunta: "Desde el punto de vista del rendimiento, ¿es mejor tener pocos objetos de directiva de grupo de gran tamaño o muchos pequeños?"Esta y otras preguntas relacionadas con el diseño y el rendimiento de la directiva de grupo constituyen el centro de este artículo.Y, como sucede con la mayoría de las preguntas genéricas,

puedo anticipar la respuesta:"Depende."Aunque pueda parecer evasivo, mi objetivo es clarificar los mecanismos subyacentes al procesamiento de directivas de grupo para que pueda tomar decisiones con fundamento acerca de su diseño de directivas de grupo, independientemente de si está comenzando o desea optimizar un entorno con centenares de objetos de directiva de grupo existentes.

Objetos de directiva de grupo monolíticos y funcionales

Empecemos con la descripción de las distintas formas en que se pueden implementar los objetos de directiva de grupo.Los términos "monolíticos" y "funcionales" hacen referencia a su diseño.Los objetos de directiva de grupo monolíticos contienen la configuración de muchas áreas diversas.Por ejemplo, un objeto de directiva de grupo monolítico quizás contenga la configuración de plantillas administrativas, mantenimiento de Internet Explorer y de directivas de instalación de software, todo ello en un solo objeto de directiva de grupo.Por el contrario, los objetos de directiva de grupo funcionales normalmente llevan a cabo una tarea.Por ejemplo, un objeto de directiva de grupo funcional podría realizar sólo instalación de software o aplicar una configuración de seguridad.Incluso he visto objetos de directiva de grupo funcionales que sólo contenían una única configuración de directiva.Pero eso probablemente es un caso extremo.En la Figura 1 se muestran algunas de las ventajas y desventajas de cada enfoque.

Figure 1 Comparación de objetos de directiva de grupo monolíticos y funcionales

Como se puede ver, no hay respuesta clara con respecto a qué enfoque, monolítico o funcional, es el mejor en todos los casos.En su entorno, probablemente necesitará los dos.Por ejemplo, tal vez prefiera el enfoque funcional al crear la directiva de seguridad para todo el dominio.Con un único objeto de directiva de grupo que contenga solamente configuración de seguridad, se facilita la delegación del control de dicho objeto a los administradores de seguridad donde nadie más tendrá acceso a él.De la misma forma, si delega la administración de las directivas de grupo a los administradores de la unidad organizativa, el establecimiento de un objeto de directiva de grupo monolítico para cada unidad organizativa proporcionará a dichos administradores un único lugar donde puedan administrar todas las configuraciones de directiva.De este modo se les reducirá la complejidad y podrá moderar el número de objetos de directiva de grupo creados para los usuarios y los equipos de una determinada unidad organizativa.

¿Cómo afectan estas decisiones de diseño de alto nivel al rendimiento de procesamiento de la directiva de grupo, y cómo puede tomar decisiones adecuadas acerca del diseño de directivas de grupo para minimizar las repercusiones en el rendimiento?El primer paso para maximizar el rendimiento de la infraestructura de directiva de grupo es comprender el funcionamiento del procesamiento de directiva de grupo.

Descripción del procesamiento de directiva de grupo

El procesamiento de directiva de grupo es un conjunto complejo de las interacciones que implican muchos elementos de su infraestructura de Windows® y Active Directory®.En un nivel alto, existen dos partes en el procesamiento de directiva de grupo.La primera es la parte principal, el procesamiento de la infraestructura de directiva de grupo.En esta fase, un cliente de directiva de grupo de Windows consulta su controlador de dominio más próximo para determinar cuál es la velocidad de vínculo al mismo, dónde se encuentra en la jerarquía de Active Directory (es decir, de qué sitio, dominio y unidad organizativa es miembro el cliente) y qué objetos de directiva de grupo se aplican al equipo o al usuario que ha iniciado sesión.Es importante tener en cuenta que en este contexto un cliente puede ser un servidor o una estación de trabajo que participa en un dominio de Active Directory.Una vez creada la lista de objetos de directiva de grupo, comienza la siguiente fase: el procesamiento de extensión de lado cliente (CSE).Durante la fase de CSE, cada CSE registrada procesa la lista de los objetos de directiva de grupo que han implementado configuraciones en su área.Por ejemplo, la CSE Registro o Plantilla administrativa se ejecuta en primer lugar en todos los casos y procesa todos los objetos de directiva de grupo que se aplican al equipo o al usuario concretos y que han implementado la directiva del Registro en ellos.

En la lista que se ofrece a continuación, se detallan los pasos que recorre el ciclo de procesamiento de directiva de grupo, incluidas las interacciones de red entre el cliente y el controlador de dominio.Es importante recordar que la directiva de grupo se aplica tanto a equipos como a usuarios.Por lo tanto, cada vez que se procese la directiva (por ejemplo, durante una actualización de fondo de directiva de grupo), el ciclo que indico más adelante se repetirá para el equipo y para la cuenta de usuario que ha iniciado la sesión en un sistema determinado, ya que cada uno puede tener aplicado un conjunto de directivas distinto.Cuando esto sucede, Windows lleva a cabo realmente el ciclo de procesamiento simultáneamente tanto para el equipo como para el usuario, y cada ciclo se ejecuta en un subproceso diferente en el motor de directiva de grupo.El proceso Winlogon para Windows 2000, Windows XP y Windows Server® 2003, y el servicio Cliente de la directiva de grupo en Windows Vista® y Windows Server 2008.

El procesamiento de una directiva de grupo es un procedimiento de seis pasos:

1. El cliente lleva a cabo la detección de vínculo lento del Protocolo de mensajes de control de Internet (ICMP) en un controlador de dominio de su sitio para determinar la velocidad de vínculo.En Windows Vista, el uso de ICMP para la detección de vínculos lentos queda reemplazo por el servicio de reconocimiento de ubicación de red (NLA).
2. El cliente lee la información de estado de CSE en su Registro local para determinar los últimos objetos de directiva de grupo que se procesaron.
3. El cliente usa LDAP para buscar el atributo gpLink en Active Directory en cada objeto contenedor dentro de su ubicación en la jerarquía de Active Directory: primero en el nivel de unidad organizativa (incluidas todas las unidades organizativas anidadas), después en el dominio y, finalmente, en el nivel de sitio de Active Directory.A partir de los resultados de esta búsqueda, construye una lista de objetos de directiva de grupo que se deben evaluar para su procesamiento.
4. Seguidamente, se busca cada objeto de directiva de grupo en Active Directory para determinar si el cliente (usuario o equipo) tiene los permisos necesarios para procesarlo.También se evalúa su número de versión, la ruta de acceso a la parte de la plantilla de directiva de grupo (GPT), la parte del objeto de directiva de grupo en SYSVOL y las CSE que se han implementado en dicho objeto de directiva de grupo.
5. A continuación, el cliente usa el protocolo de bloque de mensajes de servidor (SMB) para leer el contenido de la plantilla de directiva de grupo y obtener el número de versión del objeto de directiva de grupo del archivo gpt.ini.Los números de versión del contenedor de directiva de grupo (GPC) y la plantilla de directiva de grupo constituyen un factor que se usa para determinar si un objeto de directiva de grupo ha cambiado desde el último ciclo de procesamiento.
6. Cada CSE se ejecuta en el orden registrado en HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions, y procesa los objetos de directiva de grupo que implementan dicha CSE si el objeto de directiva de grupo ha cambiado desde el último ciclo de procesamiento (según lo determinado durante el procesamiento principal).Cada CSE también registra los datos del conjunto resultante de directivas (RSoP) de usuario en el Instrumental de administración de Windows (WMI) durante cada actualización, si están disponibles.

Analicemos este proceso y veamos cómo se puede ver afectado el rendimiento.Lo primero es apreciar que hay una diferencia entre el procesamiento en primer plano y el procesamiento de fondo.El procesamiento en primer plano se produce para los equipos durante un reinicio del sistema y para los usuarios durante un inicio de sesión.Las actualizaciones de fondo se producen en las estaciones de trabajo y los servidores miembro cada 90 minutos de forma predeterminada y hasta un máximo de 30 minutos en un valor aleatorio.Las actualizaciones de fondo se producen en los controladores de dominio cada cinco minutos de forma predeterminada.En Windows Vista, también puede tener actualizaciones basadas en NLA, que son fundamentalmente eventos de actualización de fondo que se activan por un error anterior del procesamiento de directiva de grupo debido a la falta de acceso a un controlador de dominio (como cuando el cliente está sin conexión al producirse un intervalo de fondo).¿Por qué son importantes estas distinciones?Principalmente porque determinadas CSE (por ejemplo, las CSE Instalación de software y Redirección de carpetas) no se ejecutarán durante una actualización de fondo.Del mismo modo, los scripts de inicio y cierre de sesión o de inicio y apagado no se ejecutarán durante una actualización de fondo.

De forma similar, en el paso uno de este proceso, mencioné el proceso de detección de vínculo lento.En sistemas anteriores a Windows Vista, este proceso se basa en clientes que usan ICMP para enviar un ping al controlador de dominio con el fin de determinar su disponibilidad y velocidad de vínculo.Si la velocidad de vínculo calculada está por debajo de un determinado valor de umbral (el valor predeterminado es 500 Kb/s), se considera que el vínculo es lento y, de nuevo, determinadas CSE, como Instalación de software, Redirección de carpetas y Mantenimiento de Internet Explorer, no se ejecutarán.Todas estas condiciones pueden afectar al rendimiento así como a la entrega esperada de directivas.

Probablemente, el aspecto del ciclo de procesamiento de directiva con la mayor repercusión en el rendimiento sea la lógica que determina si han cambiado los objetos de directiva de grupo que se aplican a un equipo o un usuario.El motor de directiva de grupo tiene una optimización integrada que indica si no ha cambiado nada para un equipo o un usuario desde la última vez que se procesó la directiva de grupo; en este caso, no se produce el procesamiento.Evidentemente, esto puede afectar de forma considerable al tiempo que los clientes tardan en procesar la directiva, especialmente si su entorno de directiva de grupo es bastante estático.Examinemos con más detalle lo que constituye un cambio.

Cuándo se produce un cambio de directiva de grupo

Por lo tanto, ¿qué constituye un cambio en lo que respecta al procesamiento de directiva de grupo?Hay varios factores, pero el más evidente es que si cambia un objeto de directiva de grupo, los clientes que lo procesan detectarán el cambio y volverán a procesar el objeto.¿Cómo sabe un cliente que un objeto de directiva de grupo ha cambiado?Lo averigua a partir de los números de versión en el objeto de directiva de grupo y en el cliente.

Un objeto de directiva de grupo se compone de dos partes: el GPC almacenado en Active Directory en CN=Directivas, CN=Contenedor del sistema en cada dominio y la GPT almacenada en SYSVOL en la carpeta "Directivas".Cada elemento del objeto de directiva de grupo contiene un número de versión.Para el GPC, este número de versión se almacena en el atributo versionNumber en el objeto GPC.Para la GPT, se almacena en el archivo gpt.ini en la raíz de una GPT concreta.El cliente también mantiene un registro de los números de versión de los objetos de directiva de grupo que ha procesado (tanto por equipo como por usuario) dentro de su Registro.Esta información de versión se almacena en HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History para el equipo y en HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID de usuario> para el usuario en cada equipo.

Cuando se produce el procesamiento de directiva de grupo, una de las partes examina los números de versión de todos los objetos de directiva de grupo a los que está sujeto el equipo o el usuario y los compara con los procesados en el último ciclo, tal como consta en el Registro.Si cualquiera de los números de versión de los objetos de directiva de grupo actuales es distinto (tenga en cuenta que sólo tienen que ser diferentes; pueden ser mayores o menores), dichos objetos se procesarán en el ciclo de procesamiento actual.Si no es así, no se procesan a menos que se cumpla otra de las condiciones de cambio.Las demás condiciones de cambio son las siguientes:

• Un cambio en la lista de objetos de directiva de grupo que se aplican a un usuario o equipo (un objeto de directiva de grupo que se ha agregado o quitado).
• Un cambio en la pertenencia al grupo de seguridad de un usuario o un equipo.
• Un cambio en un filtro WMI vinculado a un objeto de directiva de grupo (un filtro WMI que se ha agregado o quitado).

Si se cumple alguna de estas condiciones de cambio, el cliente volverá a procesar la directiva durante dicho ciclo.Pero hay sutilezas en este proceso que debe conocer, ya que pueden tener una gran repercusión en el rendimiento.Para una CSE determinada, si uno de diez objetos de directiva de grupo cambia, dicha CSE debe procesar todos los objetos.Recuerde que el procesamiento se produce por CSE.Sin embargo, las CSE deben procesar la directiva en el orden de prioridad que controla el procesamiento (primero los objetos de directiva de grupo locales, después los vinculados al sitio, a continuación los vinculados al dominio y, finalmente, los vinculados a la unidad organizativa).Según este requisito, supongamos que un usuario tiene diez objetos de directiva de grupo aplicables, cada uno vinculado a distintos niveles de la jerarquía de Active Directory.Y supongamos que cada uno de estos diez objetos de directiva de grupo implementa algunas configuraciones de directiva de plantilla administrativa.Un administrador cambia un objeto de directiva de grupo vinculado al dominio, y agrega una nueva configuración de directiva de plantilla administrativa.A continuación, el equipo o el usuario procesa la directiva y advierte que el número de versión del objeto de directiva de grupo que ha cambiado es mayor con respecto a la última vez que se procesó, por lo que el objeto se debe volver a procesar.Pero, para mantener el orden de prioridad del procesamiento de directiva de grupo, debe procesar todas las configuraciones de plantillas administrativas que se aplican a todos los objetos de directiva de grupo.Por lo tanto, un simple cambio en un objeto de directiva de grupo puede tener una repercusión importante en dicho cliente.

Comparación del rendimiento de los objetos de directiva de grupo monolíticos y funcionales

Una vez examinado el ciclo de procesamiento y el modo en que los cambios en el entorno de directiva de grupo afectan al procesamiento, volvamos a nuestra explicación de las diferencias entre los objetos de directiva de grupo monolíticos y los funcionales, y el modo en que cada enfoque afecta al rendimiento.

Los objetos de directiva de grupo monolíticos pueden tener una penalización de rendimiento oculta debido al modo en que funciona el control de versiones de directiva de grupo.Los motivos al respecto no son evidentes, pero están relacionados con el hecho de que no existe el concepto de control de versiones por CSE en el procesamiento de directiva de grupo.Supongamos que un usuario tiene tres objetos de directiva de grupo que se le aplican.Cada objeto de directiva de grupo es monolítico en el sentido en que implementa varias áreas de directiva.Por ejemplo, supongamos que cada objeto de directiva de grupo implementa las directivas Plantilla administrativa, Instalación de software y Redirección de carpetas.Supongamos que un administrador efectúa un cambio en la directiva Plantilla administrativa de uno de estos objetos de directiva de grupo.Debido a este cambio, aumenta su número de versión.A continuación, el usuario procesa la directiva de grupo.La CSE Plantilla administrativa se inicia y advierte que uno de los objetos de directiva de grupo ha cambiado, por lo que procesa los tres objetos de nuevo.

Cuando se ejecutan las CSE Instalación de software y Redirección de carpetas, también consultan los números de versión de objeto de directiva de grupo y advierten un nuevo número de versión en uno de los objetos.Pero como este número de versión no les indica el área de directiva que ha cambiado en dicho objeto de directiva de grupo, continúan y procesan los tres objetos, por si acaso.El resultado es que, en una implementación de objeto de directiva de grupo monolítico, efectuar cambios en un área de la directiva puede provocar actividad de procesamiento en otra área.

Ciertamente, en el caso de la directiva de instalación de software o de redirección de carpetas, es posible que las CSE no efectúen realmente ninguna tarea porque, por ejemplo, si una aplicación ya se ha instalado no se volverá a instalar.Pero la cuestión es que este comportamiento puede suceder con cualquier CSE y se debe tener en cuenta cuando se diseñan objetos de directiva de grupo monolíticos.Si tiene un área de directiva que cambia con frecuencia, puede considerar la posibilidad de mantener los objetos de directiva de grupo que implementan dicha área de directiva separados de las demás áreas de directiva.

Desde un punto de vista de objeto de directiva de grupo funcional, las consideraciones de rendimiento resultan más evidentes.Si tiene varios objetos de directiva de grupo por usuario o equipo (debido a que el enfoque funcional normalmente implica más objetos de directiva de grupo para un determinado conjunto de configuraciones de directiva), significa que el motor de directiva de grupo tiene que dedicar más tiempo a enumerar dichos objetos de directiva de grupo durante la fase principal del procesamiento de directiva de grupo.Sin embargo, como veremos en la sección siguiente, esto puede no afectar necesariamente al rendimiento de una manera importante.

Medición del rendimiento de directiva de grupo

Por último, para tomar decisiones acertadas acerca del rendimiento de la infraestructura de directiva de grupo, debe ser capaz de cuantificar el rendimiento de directiva de grupo en el entorno real.Resulta prácticamente imposible modelar o predecir el rendimiento de directiva de grupo, dada la gran cantidad de factores que pueden afectar a un determinado ciclo de procesamiento.Por este motivo, la medición empírica es la mejor apuesta para descubrir si el rendimiento de procesamiento de directiva de grupo supone un problema.¿Qué constituye un rendimiento incorrecto?El rendimiento incorrecto es cualquier situación donde el procesamiento de directiva de grupo afecta a la experiencia de los usuarios en sus sistemas.Esto puede ser diferente para cada organización, pero la clave es saber que existe un problema.

Por lo tanto, ¿cómo se mide la duración de un determinado ciclo de procesamiento de directiva de grupo?Bueno, de nuevo, la respuesta no es sencilla.Si ejecuta Windows Vista o Windows Server 2008, puede aprovechar los nuevos registros operativos del Visor de eventos.El registro operativo de directiva de grupo en el Visor de eventos, que se encuentra en Registros de aplicaciones y de servicios\Microsoft\Windows\Directiva de grupo\Operativo, proporciona un instrumental excelente de cada paso del ciclo de procesamiento de directiva de grupo, incluido el tiempo empleado durante cada fase del procesamiento (consulte la Figura 2).

Figura 2** Evento de registro operativo de directiva de grupo que muestra el tiempo de procesamiento de directiva **(Hacer clic en la imagen para ampliarla)

Sin embargo, si no trabaja en un entorno de Windows Vista o Windows Server 2008, los mecanismos para medir los tiempos de procesamiento de directiva son menos directos.En este caso, las opciones son habilitar el registro de userenv detallado (consulte el artículo de soporte técnico de Microsoft en support.microsoft.com/kb/221833) y consultar las marcas de tiempo en este archivo para un determinado ciclo de procesamiento, o usar los valores almacenados en el Registro del cliente que indican los tiempos de inicio y detención del procesamiento de directiva.Estos valores se almacenan en la siguiente ubicación para el equipo:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}

Y aquí para el usuario:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}

Los valores están almacenados en formato FILETIME y se deben convertir a una fecha y hora normales.También puede usar la utilidad gratuita GPTime.exe que escribí (disponible en gpoguy.com/tools.htm#GP_Time_Utility) para obtener la misma información.

Si no tiene un entorno de Windows Vista o Windows Server 2008 pero tiene acceso a un registro de userenv, puede obtener información valiosa acerca del tiempo que se ha empleado en cada ciclo de procesamiento de directiva.Por ejemplo, en la Figura 3 se ofrece un fragmento del registro de userenv que muestra parte de la fase principal del procesamiento de directiva de grupo.

Figura 3** Una parte del registro de userenv **(Hacer clic en la imagen para ampliarla)

Observe que cada línea del archivo de registro incluye una marca de tiempo.La parte principal del ciclo de procesamiento de directiva de grupo empieza a partir del evento que indica algo parecido a "ProcessGPOs:Iniciando el procesamiento de directivas de grupo (de fondo)... "La parte de CSE del ciclo de procesamiento empieza a partir de la línea "ProcessGPOs:Procesando Registro de extensiones".Puede usar este registro y las marcas de tiempo que contiene para determinar cuánto tarda cada parte de un ciclo de directiva.

Observaciones generales acerca del rendimiento

Cuando haya dedicado suficiente tiempo a examinar los archivos de registro de userenv, empezarán a surgir patrones y, aunque no puede predecir cuánto tardará el procesamiento de directiva, puede comenzar a realizar algunas observaciones generales acerca del tiempo empleado en un determinado ciclo de procesamiento.Por ejemplo, durante un evento de procesamiento de directiva, cuando se procesan cambios de directiva y las CSE tienen trabajo a consecuencia de un cambio, el tiempo dedicado a la parte principal del procesamiento de directiva de grupo normalmente es mucho menor en comparación con la parte de CSE.

Esto se aplica a la mayoría de las áreas de directiva porque muchas CSE necesitan llevar a cabo tareas que duran más tiempo que la parte principal de su procesamiento, cuyas operaciones más exigentes consultan Active Directory y SYSVOL.Por ejemplo, no hay comparación entre el tiempo empleado en el procesamiento principal y la CSE Instalación de software que ejecuta una instalación de Microsoft® Office.Sin embargo, para una actualización de directiva de fondo normal donde no ha cambiado nada desde el último ciclo, la parte principal del ciclo de procesamiento dura aproximadamente el mismo tiempo que la parte de CSE.El procesamiento de directivas del Registro constituye la excepción, ya que es realmente bastante más rápido, a menos que tenga decenas o centenares de configuraciones de directivas del Registro para un determinado usuario o equipo.

Además, deshabilitar el lado de equipo o usuario de un objeto de directiva de grupo porque no se usa apenas repercute en el rendimiento de procesamiento de directiva.Si no se usa un lado de directiva, la única sobrecarga será consultar Active Directory para determinarlo, y la misma consulta se debe realizar con el fin de ver la opción de deshabilitación como la única que se produce para determinar si se ha implementado alguna CSE para dicho lado del objeto de directiva de grupo,El efecto de deshabilitar un lado es mínimo.

Recomendaciones de diseño para un rendimiento de directiva de grupo óptimo

Una vez examinados numerosos aspectos del rendimiento de procesamiento de directiva de grupo, existen algunas recomendaciones de diseño que pueden afectar directamente al rendimiento.Se resumen en cuatro puntos clave.

1. Si realiza cambios frecuentes en los objetos de directiva de grupo, tenga presente el efecto mencionado anteriormente por el que un cambio en una CSE puede afectar al procesamiento de todas las CSE.En este sentido, por ejemplo, si planea realizar cambios frecuentes en la directiva del Registro, resulta más lógico colocar la directiva del Registro en objetos de directiva de grupo funcionales (objetos que sólo se encargan de la directiva del Registro), ya que así se aislará el procesamiento de otras CSE cuando se produzcan cambios.
2. Al plantearse cuántos objetos de directiva de grupo son demasiados, tenga presente que el procesamiento de directiva sólo se produce durante los cambios, y que las CSE más "exigentes", como Instalación de software, Redirección de carpetas, el tratamiento de una gran cantidad de directivas del Registro o la configuración de permisos en árboles de archivo grande o del Registro, son las que llevan más tiempo.El tiempo dedicado a consultar Active Directory en busca de la lista de objetos de directiva de grupo durante el procesamiento principal suele ser la parte menor del ciclo de procesamiento.Por lo tanto, 30 objetos de directiva de grupo que se aplican a un determinado usuario pero que apenas efectúan cambios de directiva del Registro y no cambian con frecuencia tardarán menos tiempo en procesarse que cinco objetos de directiva de grupo que ejecutan CSE exigentes de forma periódica, porque dichos objetos cambian con frecuencia.
3. Evite los comportamientos que provocan retrasos evidentes en el rendimiento del procesamiento de directivas.Por ejemplo, puede establecer la directiva para obligar a las CSE a procesarse, incluso si un objeto de directiva de grupo no ha cambiado (en Configuración del equipo\Plantillas administrativas\Sistema\Directiva de grupo).Sin embargo, si lo hace, el procesamiento de directiva tardará más tiempo en cada ciclo.
4. Tenga en cuenta lo que implica deshabilitar la optimización del inicio de sesión rápido en Windows XP y Windows Vista (se realiza habilitando la directiva en Configuración del equipo\Plantillas administrativas\Sistema\Inicio de sesión\Esperar siempre la detección de red al inicio del equipo y de sesión).Cuando se habilita esta directiva, el procesamiento en primer plano cambia de asincrónico a sincrónico.Esto significa que la directiva de equipo y de usuario debe ejecutarse hasta su finalización antes de que el usuario obtenga el control del equipo y del escritorio.Sin embargo, también puede ser beneficioso, porque soluciona el problema de requerir dos o más reinicios o inicios de sesión para que las directivas de instalación de software y de redirección de carpetas surtan efecto.

Conclusión

Aunque el rendimiento del procesamiento de directiva de grupo no es una ciencia exacta, existe información que puede usar en el proceso de diseño para mitigar los problemas de rendimiento.

La comprensión de cómo funciona el procesamiento y dónde se emplea el tiempo supone una gran ventaja en el seguimiento de los problemas de rendimiento.Use los registros operativos de Windows Vista o Windows Server 2008 (o los registros de userenv en versiones anteriores de Windows) para obtener información instrumentada del ciclo de procesamiento.Tenga presente las peculiaridades de procesamiento de CSE y lo que constituye un cambio en la directiva desde un punto de vista de CSE.Y recuerde que, en los entornos dinámicos con numerosos cambios, los objetos de directiva de grupo funcionales son más lógicos que los monolíticos.Pero la conclusión final es que la directiva de grupo es una tecnología diseñada para ayudarle a administrar mejor su entorno de Windows.Es muy importante que sus necesidades de negocio impulsen el diseño de directiva de grupo en vez de que suceda al revés.Tenga en cuenta que algunos de los comportamientos de rendimiento tratados aquí pueden ayudarle a alcanzar dicho objetivo.

Darren Mar-Eliaes MVP en directivas de grupo de Microsoft, creador del famoso sitio de directivas de grupo www.gpoguy.com y coautor de la guía de directivas de grupo de Microsoft Windows (Microsoft Press, 2005). Es también CTO y fundador de SDM Software, Inc. Póngase en contacto con él en la dirección Darren@gpoguy.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.