Stratégie de groupe

Optimisation des performances de Stratégie de groupe

Darren Mar-Elia

Vue d'ensemble:

• Comparaison entre GPO monolithiques et GPO fonctionnels
• Comment traiter les entrées de stratégie de groupe
• Ce qui se passe lors de modifications de la Stratégie de groupe

On me pose fréquemment la question, « Du point de vue performances, vaut-il mieux avoir un petit nombre d'objets de stratégie de groupe volumineux ou beaucoup de petits » ?Cette question et d'autres liées à la conception de Stratégie de groupe et aux performances font justement l'objet de cet article.Et, comme avec la plupart des questions larges,

je peux vous dire d'ores et déjà :« Ça dépend. »Bien que cela puisse vous sembler évasif, mon objectif est d'apporter la lumière sur les mécanismes sous-jacents au traitement de la Stratégie de groupe de manière à vous permettre de prendre des décisions éclairées pour votre conception de Stratégie de groupe, que vous en soyez juste au début ou que vous cherchiez à optimiser un environnement avec des centaines d'objets de stratégie de groupe existants.

Comparaison entre GPO monolithiques et GPO fonctionnels

Commençons par décrire les différentes façons dont vous pouvez implémenter vos objets de stratégie de groupe.Les termes « monolithiques » et « fonctionnels » se réfèrent à la façon dont vous les concevez.Les objets de stratégie de groupe monolithiques contiennent des paramètres ayant de multiples origines.Par exemple, un GPO monolithique peut contenir des paramètres provenant des stratégies de modèles d'administration, de maintenance Internet Explorer et d'installation de logiciels, le tout dans un seul objet de stratégie de groupe.Par contraste, les objets de stratégie de groupe fonctionnels exécutent généralement une seule action.Par exemple, un objet de stratégie de groupe fonctionnel peut s'attacher seulement à l'installation de logiciel ou appliquer des paramètres de sécurité.J'ai vu même des objets de stratégie de groupe fonctionnels contenant seulement un paramètre de stratégie !Mais c'est probablement un cas extrême.La figure 1 montre quelques uns des avantages et désavantages de chaque approche.

Figure 1 Comparaison des GPO monolithiques et fonctionnels

Comme vous pouvez le voir, il n'est pas possible de trancher définitivement sur la meilleure approche : monolithique ou fonctionnelle.Dans votre environnement, vous aurez probablement besoin des deux.Par exemple, vous pourrez trouver l'approche fonctionnelle préférable lorsque vous créez la stratégie de sécurité pour l'ensemble de votre domaine.Utiliser un objet de stratégie de groupe unique contenant seulement les paramètres de sécurité facilite la délégation du contrôle de cet objet de stratégie de groupe à vos administrateurs de sécurité, où personne d'autre ne peut y toucher.Par le même jeton, si vous déléguez l'administration de la stratégie de groupe aux administrateurs d'unités d'organisation, la configuration d'un GPO monolithique pour chaque unité d'organisation offre un emplacement unique à ces administrateurs pour gérer tous leurs paramètres de stratégie.Cela peut réduire la complexité et vous permettre de modérer le nombre d'objets de stratégie de groupe créés pour les utilisateurs et les ordinateurs de l'unité d'organisation donnée.

Quel est l'effet de ces décisions de conception de haut niveau sur les performances du traitement de la stratégie de groupe, et comment pouvez-vous prendre des décisions intelligentes sur la conception de la Stratégie de groupe pour réduire les impacts sur les performances ?La première étape dans l'optimisation des performances de votre infrastructure de Stratégie de groupe est de comprendre comment le traitement de la stratégie de groupe fonctionne sous couverture.

Comprendre le traitement de la stratégie de groupe

Le traitement de la stratégie de groupe est une série complexe d'interactions impliquant de nombreuses parties de votre infrastructure Windows® et Active Directory®.À un niveau élevé, le traitement de la Stratégie de groupe comprend deux parties.La première est appelée Noyau, ou traitement d'Infrastructure de Stratégie de groupe.Dans cette phase, un client de stratégie de groupe Windows interroge son contrôleur de domaine le plus proche pour déterminer la vitesse de lien au DC, où il se situe dans la hiérarchie Active Directory (c'est-à-dire de quel site, quel domaine et quelle l'unité d'organisation le client est membre), et quels objets de stratégie de groupe s'appliquent à l'ordinateur ou l'utilisateur actuellement connecté.(Il est important de noter que dans ce contexte un client peut être un serveur ou un poste de travail appartenant à un domaine Active Directory.)Une fois la liste d'objets de stratégie de groupe créée, la phase suivante démarre : le traitement d'extension côté client (CSE, Client-Side Extension).Pendant la phase CSE, chaque CSE enregistré traite la liste d'objets de stratégie de groupe ayant des paramètres implémentés dans sa zone.Par exemple, le CSE Registre ou Modèle d'administration s'exécute systématiquement en premier et traite tous les objets de stratégie de groupe qui s'appliquent à l'ordinateur ou à l'utilisateur donné et qui ont une stratégie de registre implémentée en eux.

La liste qui suit détaille les étapes du cycle de traitement de la stratégie de groupe, y compris les interactions de réseau entre le contrôleur client et domaine.Il est important de rappeler que la stratégie de groupe s'applique aux ordinateurs et aux utilisateurs.Donc, chaque fois que la stratégie opère (par exemple pendant l'actualisation en arrière-plan de la stratégie de groupe), le cycle que j'énumère ci-dessous sera répété pour l'ordinateur et le compte utilisateur actuellement connecté sur un système donné, puisque chacun peut avoir un ensemble différent de stratégies appliqué.Dans ce cas, Windows exécute en fait le cycle de traitement simultanément pour l'ordinateur et l'utilisateur, avec chaque cycle s'exécutant sur un thread différent du processus de moteur de Stratégie de groupe.(Le processus Winlogon pour Windows 2000, Windows XP et Windows Server® 2003 et le service Client de Stratégie de groupe dans Windows Vista® et Windows Server 2008.)

Le traitement d'une stratégie de groupe compte six étapes :

1. Le client exécute la détection de liaisons lentes ICMP (Internet Control Message Protocol) sur un contrôleur de domaine de son site pour déterminer la vitesse des liaisons.Dans Windows Vista, l'utilisation du protocole ICMP pour la détection de liaisons lentes est remplacée par le service NLA (Network Location Awareness).
2. Le client lit les informations d'état de CSE à partir de son registre local pour déterminer quels objets de stratégie de groupe ont été traités en dernier.
3. Le client utilise le protocole LDAP pour rechercher l'attribut gpLink dans Active Directory sur chaque objet de conteneur dans son emplacement de la hiérarchie Active Directory : d'abord au niveau d'unité d'organisation (y compris toutes les unités d'organisation imbriquées), ensuite au niveau du domaine et enfin au niveau du site Active Directory.À partir des résultats de cette recherche, il génère une liste d'objets de stratégie de groupe devant être évalués pour le traitement.
4. Chaque objet de stratégie de groupe est ensuite recherché dans Active Directory pour déterminer si le client (utilisateur ou ordinateur) possède les autorisations nécessaires pour le traiter.Son numéro de version, le chemin du Modèle de Stratégie de groupe (GPT), la portion de l'objet de stratégie de groupe dans SYSVOL et les CSE implémentés dans cet objet de stratégie de groupe sont également évalués.
5. Le client utilise ensuite le protocole SMB (Server Message Block) pour lire le contenu du GPT et obtenir le numéro de version de l'objet de stratégie de groupe à partir du fichier gpt.ini.Les numéros de version dans le Conteneur de Stratégie de groupe (GPC) et le GPT sont un facteur utilisé pour déterminer si un objet de stratégie de groupe a changé depuis le dernier cycle de traitement.
6. Chaque CSE s'exécute dans l'ordre enregistré sous HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions, et traite les objets de stratégie de groupe qui implémentent ce CSE si l'objet de stratégie de groupe a changé depuis le dernier cycle de traitement (comme déterminé pendant le traitement noyau).Chaque CSE consigne également les données RSOP (Resultant Set of User Policy) dans Windows Management Instrumentation (WMI) à chaque actualisation, le cas échéant.

Examinons ce processus et regardons quel impact cela peut avoir sur les performances.La première chose à savoir est qu'il y a une différence entre le traitement de premier plan et le traitement en arrière-plan.Le traitement de premier plan a lieu pour les ordinateurs pendant un redémarrage du système et pour les utilisateurs pendant une ouverture de session.Les actualisations en arrière-plan ont lieu sur les postes de travail et les serveurs membres par défaut toutes les 90 minutes plus jusqu'à 30 minutes dans une valeur aléatoire.Les actualisations en arrière-plan ont lieu sur les contrôleurs de domaine toutes les 5 minutes par défaut.Dans Windows Vista, vous pouvez avoir également des actualisations NLA, qui sont essentiellement des événements d'actualisation en arrière-plan déclenchés par une défaillance précédente de traitement de la stratégie de groupe suite à un problème d'accès à un contrôleur de domaine (comme quand le client était hors connexion lorsque une échéance d'opération en arrière-plan est survenue).Pourquoi ces distinctions sont-elles importantes ?Principalement parce que certains CSE (par exemple, Installation de logiciel et CSE de redirection de dossiers) ne s'exécuteront pas pendant une actualisation en arrière-plan.De la même manière, les scripts d'ouverture/de fermeture de session ou de démarrage/d'arrêt ne s'exécutent pas pendant une actualisation en arrière-plan.

De même, dans l'Étape 1 de ce processus, j'ai mentionné le processus de détection de liaison lente.Dans les systèmes antérieurs à Windows Vista, ce processus se base sur les clients utilisant ICMP pour analyser le contrôleur de domaine et déterminer sa disponibilité et sa vitesse de liaison.Si la vitesse de liaison calculée descend au-dessous d'une certaine valeur seuil (par défaut 500 Ko/s) la liaison est considérée comme lente et, encore une fois, certains CSE comme Installation de logiciel, Redirection de dossiers et Maintenance Internet Explorer ne s'exécuteront pas.Toutes ces conditions peuvent avoir un impact sur les performances de même que sur la réalisation prévue de la stratégie.

L'aspect du cycle de traitement de stratégie qui a probablement le plus grand impact sur les performances est la logique qui détermine si l'objet de stratégie de groupe s'appliquant à un ordinateur ou à un utilisateur a changé.Le moteur Stratégie de groupe a une optimisation incorporée qui stipule que si rien n'a changé pour un ordinateur ou un utilisateur depuis le dernier traitement de la stratégie de groupe, aucun traitement ne survient.Ceci peut avoir évidemment un impact énorme sur la durée de traitement de la stratégie pour vos clients, surtout si votre environnement de Stratégie de groupe est assez statique.Regardons plus en détail ce que constitue une modification.

Quand une modification de la stratégie de groupe se produit

Donc, qu'est-ce qui constitue une modification en termes de traitement de la stratégie de groupe ?Il y a plusieurs facteurs mais le plus évident est que si vous changez à un objet de stratégie de groupe, les clients qui le traitent détecteront la modification et retraiteront cet objet de stratégie de groupe.Comment un client sait-il qu'un objet de stratégie de groupe a changé ?Il se base sur les numéros de version de l'objet de stratégie de groupe et dans le client pour le déterminer.

Un objet de stratégie de groupe est composé de deux parties : GPC enregistré dans Active Directory sous le conteneur CN = Stratégies, CN = Système dans chaque domaine, et le GPT enregistré dans SYSVOL sous le dossier des stratégies.Chaque partie de l'objet de stratégie de groupe contient un numéro de version.Pour le GPC, ce numéro de version est enregistré dans l'attribut versionNumber sur l'objet de GPC.Pour le GPT, il a enregistré dans le fichier gpt.ini à la racine d'un GPT donné.Le client garde également un enregistrement des numéros de version des objets de stratégie de groupe qu'il a traités (par ordinateur et par utilisateur) dans son registre.Cette information de version est conservée sous HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History pour l'ordinateur et HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<SID of User> pour l'utilisateur sur chaque client.

Lorsque le traitement de la stratégie de groupe s'exécute, une des parties de l'opération consiste à examiner les numéros de version de tous les objets de stratégie de groupe en vigueur pour l'ordinateur ou l'utilisateur et à les comparer ceux traités au cours du dernier cycle, tels qu'ils sont dans le registre.Si des numéros de version des objets de stratégie de groupe actuels sont différents (notez qu'il suffit qu'ils soient différents, ils pourraient être plus grands ou plus petits !), ces objets de stratégie de groupe seront traités pendant le cycle de traitement courant.Si non, ils ne sont pas traités à moins qu'une des autres conditions de modification ne soit vraie.Ces autres conditions de modification sont les suivantes :

• une modification dans la liste d'objets de stratégie de groupe qui s'applique à un utilisateur ou à un ordinateur (ajout ou suppression d'un objet de stratégie de groupe) ;
• une modification dans l'appartenance au groupe de sécurité d'un utilisateur ou d'un ordinateur ;
• une modification dans un filtre WMI lié à un objet de stratégie de groupe (ajout ou suppression d'un filtre WMI).

Si l'une de ces conditions de changement est remplie, le client retraitera la stratégie pendant ce cycle.Mais ce processus comprend des subtilités que vous devez connaître, car elles peuvent avoir un impact significatif sur les performances.Pour un CSE donné, si 1 objet de stratégie de groupe sur 10 change, tous les objets de stratégie de groupe doivent être traités pour ce CSE.N'oubliez pas que le traitement se produit sur une base par CSE.Cependant, les CSE doivent traiter la stratégie dans l'ordre de priorité qui régit le traitement (objets de stratégie de groupe locaux en premier, puis objets de stratégie de groupe liés au site, puis objets de stratégie de groupe liés au domaine, puis objets de stratégie de groupe liés aux unités d'organisation).Sachant cela, imaginons qu'un utilisateur a 10 objets de stratégie de groupe qui s'appliquent, chacun étant lié à des niveaux différents de la hiérarchie Active Directory.Et disons que chacun de ces 10 objets de stratégie de groupe implémente certains paramètres de stratégie Modèle d'administration.Maintenant, un administrateur passe et modifie un objet de stratégie de groupe lié au domaine en ajoutant un nouveau paramètre de stratégie de modèle d'administration.Ensuite l'ordinateur ou l'utilisateur traite la stratégie et remarque que le numéro de version de cet objet de stratégie de groupe modifié est plus grand que lors du dernier traitement, l'objet de stratégie de groupe doit donc être traité de nouveau.Mais afin de maintenir l'ordre de priorité de traitement de Stratégie de groupe, il doit traiter les paramètres de tout le modèle d'administration qui s'appliquent à tous objets de stratégie de groupe.Donc une simple modification à un objet de stratégie de groupe peut avoir un impact potentiellement significatif sur les performances pour ce client.

Comparaison entre GPO monolithiques et GPO fonctionnels

Maintenant que nous avons étudié le cycle de traitement et comment les modifications apportées à votre environnement de Stratégie de groupe influence votre traitement, revenons à notre discussion sur les GPO monolithiques et fonctionnels et la façon dont chaque approche affecte les performances.

Les objets de stratégie de groupe monolithiques peuvent présenter des problèmes de performances masqués en raison du mode de fonctionnement du contrôle des versions de la stratégie de groupe.Les raisons n'en sont pas tout à fait évidentes, mais cela a voir avec le fait qu'il n'y a pas de concept de contrôle de versions par CSE dans le traitement de la stratégie de groupe.Supposons que trois objets de stratégie de groupe soient appliqués à un utilisateur.Chaque objet de stratégie de groupe est monolithique, en ce qu'il implémente plusieurs zones de stratégie.Par exemple, supposons que chaque objet de stratégie de groupe implémente la stratégie de modèle d'administration, la stratégie d'installation de logiciel et la stratégie de redirection de dossiers.Disons maintenant qu'un administrateur modifie la stratégie de modèle d'administration dans l'un de ces objets de stratégie de groupe.Son numéro de version est augmenté par cette modification.Ensuite l'utilisateur arrive et traite la stratégie de groupe.Le CSE Modèle d'administration démarre et voit qu'un des objets de stratégie de groupe a changé, donc il traite ces trois objets de stratégie de groupe une nouvelle fois.

Lorsque les CSE Installation de logiciel et Redirection de dossiers s'exécutent, ils regardent également les numéros de version de l'objet de stratégie de groupe et remarquent le nouveau numéro de version sur un des GPO.Mais parce que ce numéro de version ne leur dit pas quelle zone de stratégie a été modifiée dans quel objet de stratégie de groupe, ils continuent et traitent encore les trois objets de stratégie de groupe, au cas où.Le résultat est que, dans une mise en œuvre de GPO monolithique, modifier une zone de stratégie peut causer une activité de traitement dans une autre zone.

C'est vrai, dans le cas d'une stratégie d'installation de logiciel ou de redirection de dossiers, il est possible que ces CSE n'exécutent en réalité pas d'autre tâche parce que, par exemple, si une application a déjà été installée, elle ne le sera pas de nouveau.Mais l'important est que ce comportement peut se produire avec n'importe quel CSE et devrait être pris en compte lorsque vous concevez des GPO monolithiques.Si vous avez une zone de stratégie qui change fréquemment, vous pouvez envisager de conserver les GPO implémentant cette zone de stratégie séparés des autres zones de stratégie.

Du point de vue des GPO fonctionnel, les considérations de performances sont plus évidentes.Si vous avez plus d'objets de stratégie de groupe par utilisateur ou par ordinateur (parce que l'approche fonctionnelle implique généralement plus de GPO pour un ensemble donné de paramètres de stratégie), cela signifie que le moteur Stratégie de groupe doit passer plus de temps pour énumérer ces objets de stratégie de groupe pendant la phase fondamentale de traitement de la stratégie de groupe.Cependant, comme nous le verrons dans la section suivante, ceci peut ne pas nécessairement impacter les performances de façon significative.

Mesure des performances de Stratégie de groupe

Finalement, pour prendre de bonnes décisions sur les performances de votre infrastructure de Stratégie de groupe, vous avez besoin de pouvoir mesurer comment la Stratégie de groupe s'exécute dans votre environnement réel.Il est presque impossible de déterminer ou de prévoir les performances de Stratégie de groupe, étant donné le nombre de facteurs qui peuvent influer un cycle de traitement donné.Pour cette raison, une mesure empirique est votre meilleur atout pour déterminer si les performances du traitement de Stratégie de groupe sont un problème.Qu'est-ce qui constitue de mauvaises performances ?Et bien, les mauvaises performances sont n'importe quelle situation où un traitement de la stratégie de groupe affecte l'expérience de vos utilisateurs sur leurs systèmes.Ce peut être différent pour chaque organisation, mais l'essentiel est de savoir que vous avez un problème.

Alors comment mesurer la durée d'un cycle de traitement de Stratégie de groupe donné ?Et bien, une fois encore, la réponse n'est pas simple.Si vous exécutez Windows Vista ou Windows Server 2008, vous pouvez profiter des nouveaux journaux des opérations de l'Observateur d'événements.Le journal des opérations de la stratégie de groupe dans l'Observateur d'événements, situé sous Journaux des applications et des services\Microsoft\Windows\Stratégie de groupe\Opérationnel, fournit une instrumentation excellente sur chaque étape du cycle de traitement de la stratégie de groupe, y compris le temps passé pendant chaque phase de traitement (voir la Figure 2).

Figure 2** Événement de journal des opérations de la Stratégie de groupe indiquant le temps de traitement de la stratégie **(Cliquer sur l'image pour l'agrandir)

Cependant, si vous ne travaillez pas dans un environnement Windows Vista ou Windows Server 2008, les mécanismes de mesure des durées de traitement de stratégie sont moins directs.Dans ce cas, vos choix sont d'activer la journalisation détaillée de userenv (voir l'article du support de Microsoft à l'adresse support.microsoft.com/kb/221833) et d'afficher les horodateurs dans ce fichier pour un cycle de traitement donné, ou d'utiliser les valeurs contenues dans le registre sur le client qui indique les heures de démarrage et d'arrêt pour le traitement de stratégie.Ces valeurs sont enregistrées dans ce qui suit pour l'ordinateur

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

et ici pour l'utilisateur :

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

Les valeurs sont enregistrées au format FILETIME et doivent être converties en une date et une heure normales.Vous pouvez utiliser également l'utilitaire gratuit GPTime.exe que j'ai écrit (disponible à gpoguy.com/tools.htm#GP_Time_Utility) pour obtenir la même information.

Si vous ne travaillez pas dans un environnement Windows Vista ou Windows Server 2008, mais que vous avez accès à un journal userenv, vous pouvez toujours obtenir des informations utiles sur la durée de chaque cycle de traitement de stratégie.Par exemple, la figure 3 montre un extrait du journal userenv affichant la partie de la phase fondamentale de traitement de Stratégie de groupe.

Figure 3** Une portion du journal userenv **(Cliquer sur l'image pour l'agrandir)

Remarquez que chaque ligne du fichier journal inclut un horodateur.La partie fondamentale du cycle de traitement de Stratégie de groupe commence lorsque vous voyez un événement disant quelque chose comme « ProcessGPOs :Démarrage du traitement de la stratégie de groupe d'utilisateurs (en arrière-plan)... .»La partie CSE du cycle de traitement commence lorsque vous voyez la ligne « ProcessGPOs :traitement du Registre d'extension. »Vous pouvez utiliser ce journal et ses horodateurs pour déterminer la durée de chaque partie d'un cycle de stratégie.

Observations générales sur les performances

Lorsque vous aurez passé assez de temps à regarder les fichiers journaux userenv, vous commencerez à voir des modèles émerger, et bien que vous ne puissiez pas prédire combien de temps prendra le traitement de la stratégie, vous pouvez commencer à faire certaines observations générales sur les zones où le temps est dépensé dans un cycle de traitement donné.Par exemple, pendant un événement de traitement de stratégie, lorsque les modifications de stratégie sont traitées et que les CSE doivent agir à cause d'une modification, le temps passé dans la partie fondamentale de traitement de Stratégie de groupe est généralement beaucoup plus court comparé à la partie CSE.

Ceci est vrai pour la plupart des zones de stratégie parce que la plupart des CSE doivent effectuer des tâches qui s'exécutent plus longtemps que la portion fondamentale de leur traitement, dont les opérations les plus lourdes interrogent Active Directory et SYSVOL.Par exemple, il n'y a pas de comparaison entre le temps passé au traitement fondamental et le CSE Installation de logiciel exécutant une installation de Microsoft® Office.Cependant, pour une actualisation en arrière-plan normale de stratégie où rien n'a changé depuis le dernier cycle, la partie fondamentale du cycle de traitement prend à peu près le même temps que la portion CSE.L'exception est le traitement de stratégie de registre, qui est en fait assez rapide, à moins que vous ayez des dizaines ou des centaines de paramètres de stratégie de registre en place pour un utilisateur ou un ordinateur donné.

En outre, désactiver le côté ordinateur ou utilisateur d'un objet de stratégie de groupe parce qu'il est inutilisé a peu d'effet sur les performances de traitement de stratégie.Si un côté de stratégie est inutilisé, la seule surcharge sera dans l'interrogation d'Active Directory pour déterminer cela, et la même requête doit être exécutée pour afficher l'option de désactivation comme celle qui s'exécute pour déterminer si des CSE ont été implémentés pour ce côté de l'objet de stratégie de groupe.L'effet de la désactivation d'un côté est négligeable.

Recommandations de conception pour des performances optimales de Stratégie de groupe

Maintenant que nous avons observés bon nombre des aspects des performances de traitement de Stratégie de groupe, certaines recommandations de conception qui peuvent avoir un impact direct sur les performances.Celles-ci sont résumées dans quatre points importants.

1. Si vous modifiez fréquemment vos GPO, gardez présent à l'esprit l'effet mentionné précédemment : une modification d'un CSE peut influer sur le traitement de tous les CSE.Dans ce but, si vous avez l'intention d'apporter souvent des modifications à, par exemple, la stratégie de registre, il est plus logique pour vous de placer votre stratégie de registre dans des GPO fonctionnels (objets de stratégie de groupe réalisant seulement la stratégie de registre) car cela isolera les autres CSE du traitement lorsque les modifications surviendront.
2. Lorsque vous vous demandez combien il faut de GPO pour en avoir trop, gardez à l'esprit que le traitement de stratégie se produit seulement pendant les modifications et que ce sont les CSE « lourds » comme l'Installation de logiciel, la Redirection de dossiers ou le traitement de nombreuses stratégies de registre ou autorisations de paramètres sur de vastes arborescences de fichiers ou de registre qui prennent le plus de temps.Le temps passé à interroger Active Directory pour obtenir la liste de GPO pendant le traitement fondamental est souvent la plus petite partie du cycle de traitement.Donc, le traitement de 30 objets de stratégie de groupe appliqués à un utilisateur donné mais qui apportent des modifications minimales de stratégie de registre et qui ne changent pas souvent peut prendre moins de temps que pour 5 objets de stratégie de groupe qui exécutent des CSE lourds régulièrement parce que ces objets de stratégie de groupe changent fréquemment.
3. Évitez les comportements qui forcent des ralentissements évidents dans les performances de traitement de stratégie.Par exemple, vous pouvez déterminer la stratégie pour forcer le traitement de CSE même si aucun GPO n'a changé (sous Configuration ordinateur\Modèles d'administration\Système\Stratégie de groupe).Cependant, si vous faites ceci, attendez-vous à ce que le traitement de stratégie prenne plus longtemps à chaque cycle.
4. Gardez à l'esprit les compromis dus à la désactivation de l'optimisation d'ouverture de session rapide dans Windows XP et Windows Vista (en activant la stratégie à la Configuration ordinateur\Modèles d'administration\Système\Ouverture de session\Toujours attendre le réseau lors du démarrage de l’ordinateur et de l’ouverture de session).Lorsque cette stratégie est activée, le traitement de premier plan passe d'asynchrone à synchrone.Ceci signifie que la stratégie d'ordinateur et d'utilisateur doit s'exécuter jusqu'à la fin avant que l'utilisateur n'obtienne le contrôle de l'ordinateur et du poste de travail.Cependant, ceci peut être également avantageux parce que cela contourne le problème de la nécessité de deux redémarrages ou ouvertures de session ou plus pour que la stratégie d'installation de logiciel et de redirection de dossiers prenne effet.

Conclusion

Bien que les performances de traitement de Stratégie de groupe ne soient pas une science exacte, vous pouvez apporter quelques éclaircissements à votre processus de conception et ainsi atténuer les problèmes de performances.

Comprendre le fonctionnement du cycle de traitement et à quoi le temps est consacré peut vous faire avancer vers le dépistage des problèmes de performances.Utilisez les journaux des opérations de Windows Vista ou Windows Server 2008 (ou les journaux userenv dans les versions précédentes de Windows) pour obtenir des informations rationalisées sur le cycle de traitement.Gardez présent à l'esprit les caprices du traitement de CSE et ce qui constitue une modification de stratégie d'un point de vue CSE.Et n'oubliez pas que, dans les environnements dynamiques avec beaucoup de modifications, les GPO fonctionnels peuvent être plus judicieux que des GPO monolithiques.Mais la base à connaître est que la Stratégie de groupe est une technologie conçue pour vous aider à mieux gérer votre environnement Windows.Il est très important que vos besoins d'entreprise orientent votre conception de Stratégie de groupe et non l'inverse.Gardez en tête que certains des comportements de performances abordés peuvent vous aider ici à atteindre cet objectif.

Darren Mar-Elia est MVP de Microsoft Group Policy, créateur du célèbre site sur la stratégie de groupe, www.gpoguy.com et coauteur de Microsoft Windows Group Policy Guide (Guide de stratégie de groupe Microsoft Windows) (en anglais) (Microsoft Press, 2005)Il est également Directeur technique et fondateur de SDM Software, Inc. Contactez-le à Darren@gpoguy.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.