Les défis du GPO

De plus, comme il est possible de déléguer le contrôle d’un GPO (par exemple au
niveau des OU), on peut très bien ignorer ce que quelqu’un d’autre a fait avec
un GPO dans un conteneur sur lequel on n’a aucun contrôle. Il est donc difficile
de déterminer les stratégies effectivement reçues par un objet utilisateur ou
ordinateur donné.
Microsoft ne fournira pas immédiatement d’outils pour aider à  cette tâche, mais
Full Armor (http://www.fullarmor.com)
prévoit de sortir un produit de ce genre lors de la sortie de Windows 2000. Cet
éditeur crée déjà  des outils pour gérer les stratégies système NT 4.0. Pour Windows
2000, Full Armor complètera ces fonctions pour supporter la gestion des GPO, y
compris une fonction permettant de déterminer les stratégies résultantes des modifications
et effectivement reçues par un objet utilisateur ou ordinateur donné.

Les GPO posent un deuxième problème. En effet, s’il existe des GPO à  de nombreux
niveaux d’une hiérarchie AD, le système doit les traiter à  chaque ouverture de
session par un utilisateur ou démarrage d’une machine. Microsoft a ajouté à  Windows
2000 quelques fonctions pour optimiser les performances. D’abord les informations
sur la version d’un GPO résident sur le poste de travail et dans le GPO. Si un
GPO ne change pas, le système ne le traite pas. De plus, il est possible de désactiver
le traitement des configurations des utilisateurs ou des ordinateurs.
Supposons que vous créez un GPO pour distribuer des scripts de démarrage et d’arrêt.
La partie concernant la configuration des utilisateurs du GPO reste non utilisée
; sa désactivation empêche donc la station de travail d’essayer de parcourir le
GPO pour vérifier si rien n’a changé.Le troisième problème est dû au fait que
le GPC et le GPT sont des entités distinctes.
Etant un objet AD, le GPC se duplique selon un timing différent de celui des fichiers
contenus par le GPT. Ainsi au moment où le GPO est créé, le GPC peut très bien
avoir déjà  commencé à  se dupliquer à  travers l’infrastructure AD avant que le
GPT ait fini de dupliquer tous les fichiers dans tous les partages Sysvol de tous
les contrôleurs de domaines.Pour tout arranger, AD utilise un modèle de duplication
à  plusieurs domaines maîtres.
Le risque existe donc d’éditer un GPO sur un contrôleur de domaine, tandis qu’un
autre administrateur édite le même GPO sur un autre contrôleur de domaine, annulant
ainsi réciproquement les changements effectués. C’est pourquoi lors de la mise
en fonction du GPE, la focalisation se fait par défaut uniquement sur le contrôleur
de domaine qui joue le rôle de PDC dans l’Operations Master. (Les rôles de l’Operations
Master sont un ensemble de fonctions obligatoires dans une infrastructure AD.

Un serveur ayant le rôle de PDC sert à  mettre à  jour les périphériques NT et Win9x).
Cette condition limite les problèmes de convergence qui pourraient se poser lorsque
des administrateurs éditent des GPO à  partir de plusieurs contrôleurs de domaines.
Il convient toutefois de n’accorder la responsabilité d’éditer le GPO qu’à  quelques
administrateurs et de veiller à  ce que tout le monde soit informé lorsqu’un changement
est effectué. Enfin, il ne faut pas oublier de désactiver un GPO pendant qu’on
l’édite, et de le réactiver ensuite afin que les changements se propagent dans
tout le réseau.