Le modèle de conception est important

multidomaines.

Limiter les GPO. 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, je conseille de
limiter ce nombre à  10 comme point
de départ, mais il faut le tester car il dépend
beaucoup de ce que chaque GPO
effectue. Sachez aussi que les temps
d’attente sont plus longs la première
fois qu’un ordinateur ou utilisateur
traite un GPO, parce que les extensions
côté client doivent appliquer initialement
tous les paramètres. Après le
cycle de traitement initial, les redémarrages
système et les connexions utilisateur
qui suivront ne traiteront que les
GPO qui ont changé (sauf si vous les
forcez à  procéder autrement).

Limiter les groupes de sécurité.
L’utilisation des groupes de sécurité
(les groupes locaux, globaux ou universels
AD contenant des ordinateurs
ou des utilisateurs) peut affecter le traitement
GPO. On peut recourir aux
groupes de sécurité pour filtrer les
effets des GPO – par exemple, quand
on veut n’appliquer un GPO niveau domaine qu’à  un petit nombre
d’utilisateurs ou d’ordinateurs. Mais le
filtrage par les groupes de sécurité se
paie en performances. En effet, plus il
y a d’ACE (access control entries) associées
à  un GPO, plus l’extension côté
client du GPO doit travailler pour savoir
si un ordinateur ou un utilisateur
appartient à  l’un des groupes soumis
au filtrage. Donc, en maintenant les
ACL des GPO courts et concis, on améliore
(ou tout au moins on maintient)
les performances. Il ne faut pas utiliser
systématiquement les ACL pour filtrer
les GPO de chaque ordinateur ou utilisateur.
Il vaut mieux repenser le niveau
auquel les GPO sont liés. On peut fort
bien obtenir le résultat souhaité en reliant
le GPO plus bas dans la hiérarchie
d’AD (par exemple, au niveau OU plutôt
qu’au niveau domaine).

Limiter les liens multidomaines. Les performances sont aussi affectées par
l’utilisation de GPO liés au travers de frontières de domaines. Chaque GPO
appartient à  un domaine AD et le GPC
et le GPT du GPO résident sur les DC
de ce domaine. Supposons que l’on ait
une forêt d’AD multidomaines. On
pourrait lier un GPO d’un domaine
(domaine A) à  un autre domaine de la
forêt (domaine B). Mais quand un ordinateur
ou un utilisateur du domaine
B traite le GPO qui se trouve dans le
domaine A, les extensions côté client
de l’ordinateur du domaine B doivent
traverser les relations d’approbation
dans la forêt, pour accéder au GPC et
au GPT du GPO. Une telle opération
est plus coûteuse en matière de performances
que le fait de communiquer
avec des GPO dans le même domaine.
De plus, si l’ordinateur du domaine B
ne peut pas trouver un DC du domaine
A dans le même site AD, il lui faudra
peut-être traverser des liens WAN pour
atteindre un DC et traiter le GPO.

Il vaut donc mieux éviter de lier des GPO en franchissant des frontières de
domaines. Il est préférable de copier
un GPO défini d’un domaine dans un
autre. (XP et Win2K ne procurent pas
un moyen simple de copier des GPO
d’un domaine dans un autre, mais des
outils tierce partie le font très bien.)