5. Des limitations à respecter
5.1. Limiter les GPO
Pour commencer, l’action la plus élémentaire consiste à limiter
le nombre de GPO qu’un ordinateur ou utilisateur doit traiter au démarrage ou
à la connexion. En général, il est conseillé de limiter ce nombre à 10 comme
point de départ. Il faut savoir aussi qu’une longueur des temps d’attente plus
importante est remarquée la première fois qu’un ordinateur ou utilisateur traite
une GPO. Cela s’explique par le fait parce que côté client les applications
sont contraintes d’appliquer initialement tous les paramètres. Par la suite,
seules les GPO qui auront changé seront traitées par les redémarrages système
et les connexions utilisateur.
5.2. Limiter les groupes de sécurité
Le traitement des stratégies de groupe peut être affecter par
l’utilisation des groupes de sécurité (les groupes locaux, globaux ou universels
AD contenant des ordinateurs ou des utilisateurs) .
Les groupes de sécurité peuvent être utilisés pour filtrer
les effets des GPO mais le filtrage par ces derniers fait diminuer considérablement
les performances. En effet l’extension côté client de la GPO doit travailler
pour savoir si un ordinateur ou un utilisateur appartient à l’un des groupes
soumis au filtrage et plus il y a d’ACE (access control entries) associées à
une GPO plus le travail est long.
En maintenant les ACL des GPO courtes et concises, un gain
de performances est donc engendré. L’utilisation systématique des ACL pour filtrer
les GPO de chaque ordinateur ou utilisateur n’est pas une bonne solution : il
serait plus judicieux repenser le niveau auquel les GPO sont liées en effet
le résultat souhaité peut être obtenu en reliant la GPO plus bas dans la hiérarchie
d’Active Directory (au niveau de l’unité d’organisation plutôt qu’au niveau
du domaine par exemple).
5.3. Limiter les liens multidomaines
Les performances sont aussi affectées par l’utilisation de
GPO liées au travers de frontières de domaines. Chaque GPO appartient à un domaine
Active directory et les informations la concernant résident sur les contrôleurs
de domaine de ce domaine. Supposons que l’on ait une forêt d’Active Directory
multidomaine, il est possible de lier une GPO d’un domaine (X) à un autre domaine
de la forêt (Y) mais quand un ordinateur ou un utilisateur du domaine Y traite
la GPO qui se trouve dans le domaine X, les extensions côté client de l’ordinateur
du domaine Y doivent traverser les relations d’approbation dans la forêt, pour
accéder aux informations de la GPO. En matière de performances ces opérations
sont très coûteuses et mêmes plus que le fait de communiquer avec des GPO dans
le même domaine. Par ailleurs, il arrive que l’ordinateur du domaine Y ne puisse
pas trouver un contrôleur de domaine du domaine X dans le même site Active directory,
il lui sera alors nécessaire de traverser des liens WAN de façon à atteindre
un DC et traiter la GPO.
Au final évitez de lier des GPO qui amènent à franchir des
frontières de domaines. Copiez plutôt une GPO définie d’un domaine vers un autre.
 Introduction
1. Qu'est-ce qu'une stratégie de groupe ?
2. Application d'une stratégie de groupe
3. Comment configurer les paramètres des GPO ?
4. Quelques outils en ligne de commande bien utiles
5. Des limitations à respecter
Conclusion
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Les stratégies de groupe, c'est quoi ?
