Ma GPO ne fonctionne pas ! Que faire ? Voici 14 pistes et conseils pour s’en sortir !

I. Présentation

Dans cet article, nous allons parler du troubleshooting ou dépannage de GPO en environnement Active Directory ! En effet, lorsque l’on déploie des stratégies de groupe au sein d’un domaine, il peut arriver que les choses ne se passent pas comme prévu… Surtout lorsque l’on commence à avoir beaucoup de GPO et que l’on utilise des paramètres spécifiques, les filtres WMI, le ciblage sur des groupes de sécurité, etc...

Pour « débugger » une GPO et faire en sorte qu’elle fonctionne comme on a envie qu’elle fonctionne, il faudra vérifier sa configuration. Cet article référence une dizaine de points à vérifier pour se sortir d'affaire et faire en sorte qu'une GPO s’applique – enfin - correctement.

• Voir la vidéo sur YouTube

Version originale de l'article : 24 mars 2015

II. 14 pistes et conseils pour dépanner une GPO

A. Un paramètre non appliqué, vérifiez l’étendue

Si un paramètre ne s'applique pas, vérifiez l'unité d'organisation sur laquelle s'applique la GPO. S'il s'agit d'un paramètre Ordinateur, la GPO doit s'appliquer sur l'OU qui contient l'objet ordinateur ciblé. Sur le même principe s'il s'agit d'un paramètre Utilisateur, la GPO doit s'appliquer sur l'OU qui contient cet utilisateur.

En fait, il faut surtout que l'objet cible soit dans l’étendue de la GPO (l’étendue est aussi appelée scope), c'est-à-dire qu'il est dans la sous-arborescence sur laquelle s'applique la GPO.

Exemple de cette notion d’étendue :

En fait, vérifiez que l’objet ciblé n’est pas « hors de portée » de la GPO.

B. Le filtrage de sécurité

Par défaut, le groupe "Utilisateurs authentifiés" dispose des autorisations nécessaires sur un objet GPO nouvellement créé. Pour rappel, ce groupe inclut tous les utilisateurs et tous les ordinateurs du domaine ! Que ce soit une GPO avec des paramètres ordinateurs et/ou des paramètres utilisateurs, elle s'appliquera sur l'ensemble des objets.

Dans certains cas, nous sommes amenés à modifier ce filtrage de sécurité, car nous ne voulons pas cibler tous les utilisateurs ou tous les ordinateurs, mais uniquement certains objets. Dans ce cas, nous allons retirer "Utilisateurs authentifiés" afin de positionner à la place un groupe de sécurité (dont vous gérez les membres).

Lorsque l'on fait cette modification, il faut également ajouter le groupe "Utilisateurs authentifiés" en lecture seule au sein de l'onglet "Délégation". Sinon, notre filtrage de sécurité ne sera pas pris en compte ! Dans cet onglet "Délégation", attention également aux éventuelles permissions "refuser" qui seraient définies explicitement sur cette GPO.

Pour approfondir ce point, consultez ce tutoriel :

• Comment appliquer une GPO sur un groupe de sécurité spécifique ?

C. Filtrage WMI

Le filtrage WMI permet à l'administrateur d'appliquer la stratégie de groupe uniquement aux machines qui répondent à un ou plusieurs critères définis dans une requête WMI. Par exemple, nous pouvons créer un filtre WMI pour cibler uniquement les machines sous Windows 10, ou pour cibler uniquement les machines sous Windows Server.

De ce fait, si vous avez défini un filtre WMI, vérifiez que la requête est correcte sinon il peut expliquer pourquoi une GPO ne s'applique pas sur une machine. Autrement dit, vérifiez que le filtre WMI n'exclut pas votre cible plutôt que de la prendre en compte. Pour rappel, par défaut, aucun filtre WMI n'est mis en place.

Pour ceux qui souhaitent, voici un article complet sur l'utilisation des filtres WMI avec les GPO :

• GPO et les filtres WMI

D. Vérifier l’état de la GPO

En sélectionnant une GPO et en cliquant sur l’objet « Détails », il est possible de donner différents états à la GPO (notamment des états de désactivation). Vérifiez que l’état est bien sûr « Activé » pour activer l’ensemble des paramètres (ordinateurs et utilisateurs) définis dans cette GPO. Sinon, vous rendez inactif tout ou partie des paramètres de la GPO.

Toutefois, s'il s'agit d'une GPO avec des paramètres "ordinateurs", vous pouvez désactiver les paramètres de configuration "utilisateurs". Ceci n'empêchera pas votre GPO de fonctionner correctement.

E. La délégation

L’onglet délégation regroupe les autorisations appliquées sur l’objet GPO en question, notamment pour déléguer la création d’une GPO à un utilisateur (l’autoriser). De plus, ces autorisations sont importantes pour la réplication des GPO entre les contrôleurs de domaine, car elles régissent les droits d’accès.

On remarque que les informations que l’on retrouve dans cet onglet sont équivalentes à celles que l’on retrouve dans l’onglet « Sécurité », en accédant aux « Propriétés » d’un dossier d’un élément GPO (dans SYSVOL). Voyez par vous-mêmes :

Ce point est à vérifier si vous avez des problèmes de réplication de vos GPOs, ce qui peut impliquer des erreurs d’application par la suite…

F. Les héritages : un nid à problèmes...

Il existe des notions d’héritages pour les stratégies de groupe. Par exemple, si l’on souhaite que la GPO « Default Domain Policy » ne s’applique pas sur une OU en particulier, il suffira de faire clic droit sur l’OU concernée puis « Bloquer l’héritage ».

Les héritages bloqués sont facilement visibles grâce à un icône bleu contenant un point d’exclamation, comme ceci :

Si vous avez désactivé l'héritage sur certaines unités d'organisation, vérifiez que ce ne soit pas un problème. Si vous souhaitez qu'une GPO de niveau supérieur s'applique sur une OU où l'héritage est désactivé, vous devez lier explicitement la GPO à cette OU.

À savoir également : si l’héritage sur l’OU « Collaborateurs » est désactivé comme ci-dessus, mais que la GPO « Default Domain Policy » est « Appliqué » (Enforced), elle sera appliquée malgré tout. Autrement dit, elle outrepasse le blocage et s’applique quand même.

G. LSDOU : Kézako ?

L'acronyme LSDOU spécifie l'ordre d'application des stratégies de groupe. De ce fait, la stratégie Locale est appliquée en première et ensuite : Site, Domaine et Unité d'Organisation (Organizational Unit).

Cette notion est très importante puisque si vous activez un paramètre dans une GPO appliquée au niveau du domaine, et qu'une autre GPO placée au niveau de l'OU désactive ce même paramètre, ce sera la GPO placée la plus proche de la cible qui gagnera. En fait, en dehors de la stratégie locale, on remarque que plus la GPO est appliquée sur une unité d'organisation proche de l'objet ciblé, plus elle sera prioritaire.

En complément, lorsque vous sélectionnez une OU à partir de la console "Gestion de stratégie de groupe", vous avez accès à un onglet nommé "Objets de stratégie de groupe liés", où vous pouvez voir l'ensemble des GPOs liées directement à cette OU. Ici, vous pouvez, grâce aux flèches situées sur la gauche, modifier l'ordre d'application des GPOs. Le traitement est séquentiel : numéro 1, numéro 2, numéro 3, etc.

H. Le lien est-il actif ?

Dans la console de gestion des stratégies de groupe, les différentes GPO sont stockées dans un container nommé « Objets de stratégie de groupe ». Ensuite, chaque GPO est liée sur une ou plusieurs OUs, ce qui crée des liens.

Un lien représente un raccourci entre la GPO dans le container et l'OU sur laquelle s'applique cette GPO.

Ces liens peuvent être activés ou désactivés, cela signifie que l'on peut temporairement désactiver un lien pour désactiver l'application de la GPO sur une OU. Ceci est pratique puisque ça évite de devoir supprimer le raccourci et le recréer ultérieurement.

Vous devez vérifier que les liens sont corrects, notamment actif pour la GPO qui doit s'appliquer.

En faisant un clic droit sur un raccourci, il sera possible de savoir si le lien est activé ou non :

I. Les GPOs « Enforced » - « Appliqué »

Que la traduction de cette option est mauvaise ! En fait, dans la version française de Windows « Enforced » est traduit par « Appliqué », ce qui peut laisser penser que si on n’active pas ce paramètre la GPO ne sera pas appliquée. Ceci est totalement faux.

Il serait plus judicieux de traduire « Enforced » par « Forcé », de ce fait comprenez « Appliqué » par « Forcé » (ou « forcer l’application ») et là ça change la donne...

Cette possibilité remet en cause le schéma d’application LSDOU et offre de nouvelles perspectives pour appliquer les GPOs. En effet, si on active ce paramètre pour une GPO on force son application et on la rend prioritaire par rapport à une autre.

De plus, si deux GPOs sont forcées, ce sera celle de plus haut niveau qui sera prioritaire ! Par exemple, si je force la GPO « Default Domain Policy » et la GPO « Utilisateurs_IE », ce sera la première qui gagnera sur la deuxième, car elle est placée « plus haut ».

On reconnaît facilement une GPO sur laquelle le paramètre « Appliqué » est définit à « Oui », car l’icône contient un verrou.

J. Le loopback processing

Pour faire simple sur la notion de loopback processing, lorsque vous démarrez l’ordinateur, il applique les paramètres ordinateurs définis dans la GPO qui s’applique sur lui. Ensuite, lorsqu’un utilisateur se connecte, les paramètres utilisateurs présents dans la GPO qui s’applique sur l’utilisateur sont alors appliqués. Jusque-là, tout est normal...

Par contre, si vous activez le loopback processing au niveau de la GPO concernée il peut y avoir des surprises… En effet, si c’est actif, les paramètres utilisateurs contenus dans la GPO appliquée sur l’ordinateur seront appliqués à l’utilisateur qui se connecte, alors que cette GPO n’est pas directement appliquée à cet utilisateur ! Les paramètres utilisateurs provenant réellement de la GPO appliquée à l’utilisateur seront traités de différentes façons.

Le traitement dépend de ce que vous avez décidé : cumul des deux (avec priorité aux paramètres de la GPO ordinateur en cas de conflit) ou appliquer en priorité les paramètres définis sur la GPO qui s’applique à l’utilisateur.

Ce paramètre est configurable par GPO :

• Configuration de l’ordinateur > Modèles d’administration > Système > Stratégie de groupe > Configurer le mode de traitement par bouclage de la stratégie de groupe utilisateur

• En savoir plus sur le Loopback processing (GPO)

K. Attention à la fausse piste...

Certains paramètres se ressemblent beaucoup et les différences sont parfois minimes sur le papier, mais « conséquente » dans la réalité. Soyez vigilant et lisez bien la description d’un paramètre, en fait posez-vous la question suivante : « Ce paramètre est-il vraiment celui qui répond à mes attentes ? »

Peut-être que toute votre configuration est parfaite, mais si vous ne choisissez pas le bon paramètre, ça ne marchera pas. Regardez également les systèmes d'exploitation pris en charge par le paramètre de GPO, ainsi que les éditions supportées.

Par exemple, certains paramètres sont pris en charge uniquement sur les éditions "Enterprise" et "Education" de Windows, ce qui exclut les éditions "Pro" pourtant populaires en entreprise.

L. L’observateur d’événements

Aussi bien au niveau du contrôleur de domaine que de la cible, l’observateur d’événements fournit bien souvent des informations intéressantes sur l’erreur rencontrée (tout dépend de son origine...). De ce fait, n’hésitez pas à consulter l’observateur d’événements sur un ordinateur cible sur lequel la GPO ne s’applique pas, mais aussi sur votre contrôleur de domaine.

Consultez les journaux "Applications" et "Système" ainsi que le journal spécifique aux stratégies de groupes que vous pouvez trouver à cet endroit :

• Journaux des applications et des services > Microsoft > Windows > GroupPolicy > Opérationnel

Ce journal est très riche et il pourra permettre d'obtenir un code d'erreur ou un message d'erreur qui vous permettra d'orienter vos recherches et d'identifier la source du problème !

• Microsoft Learn - GPO - Events ID

M. La latence du réseau

Certaines stratégies de groupe, notamment celles permettant d'exécuter un script au démarrage de l'ordinateur ou d'installer un logiciel, sont susceptibles de ne pas fonctionner à cause du réseau. Il se peut que Windows cherche à exécuter le script mentionné dans la GPO alors que le réseau n'est pas encore prêt sur la machine, ce qui forcément génère une erreur et met la GPO en échec.

Par exemple, vous pouvez identifier des logs avec les codes d'erreur 1129 et 1130 dans l'observateur d'événements de la machine.

Pour résoudre ces erreurs liées au réseau, il y a deux paramètres de GPO que l'on peut utiliser pour adapter le comportement de Windows :

• Configuration ordinateur > Stratégies > Modèles d'administration > Système > Stratégie de groupe > Spécifier le temps d'attente de traitement de stratégie de démarrage
• 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

Pour en savoir plus, consultez ces articles :

• GPO – Troubleshooting : erreurs ID 1129 – 1130 avec un script de démarrage
• GPO - Toujours attendre le réseau (partie III.B de l'article)

N. L’outil gpresult (et le rapport RSOP)

L'outil "gpresult" intégré à Windows est incontournable pour le troubleshooting de GPO ! Grâce à gpresult il est possible de récupérer un état des GPO qui s'appliquent sur un utilisateur/ordinateur du domaine. Cet outil va permettre de vérifier qu'une stratégie de groupe s'applique bien, et si la GPO ne s'applique pas, il va permettre de visualiser s'il y a une erreur associée.

Nous l'avons présenté dans un article (et une vidéo dédiée) :

• Dépannage de GPO avec l'outil gpresult

Par ailleurs, à partir de la console de Gestion de stratégie de groupe, nous avons une alternative à gpresult avec l’outil RSOP (Resultant Set Of Policy – Résultats de stratégie de groupe). C'est un outil intéressant pour tester l’application des GPOs à distance.

Choisissez un ordinateur, un utilisateur et l’outil RSOP se chargera de vous afficher un rapport quant à l’application des GPOs pour cet utilisateur sur la machine indiquée. Cet outil permet d’une part de contrôler que tout s’applique bien comme on le souhaite, d’autre part de débugger les GPOs en cas de besoin. De plus, vous pouvez sauvegarder les rapports directement dans la console.

Voici un aperçu de RSOP :

Pour générer un rapport, utilisez la console de gestion de stratégie de groupe, effectuez un clic droit sur « Résultats de stratégie de groupe » et suivez l’assistant.

III. Conclusion

En conclusion, lorsque vous mettez en place des GPOs faites le plus simple possible, il ne faut pas que ça devienne « une usine à gaz ». Pensez également à adopter une convention de nommage claire et parlante, par exemple pour différencier facilement une GPO Utilisateur d'une GPO Ordinateur, ou une GPO destinées aux serveurs plutôt qu'aux postes de travail.

Avec les points cités ci-dessus, vous devriez pouvoir vous en sortir dans de nombreuses situations, bien qu’il puisse y avoir des cas extrêmes. Si votre problème n'est pas résolu, utilisez notre Discord pour exposer votre problème à la communauté. Par ailleurs, si vous souhaitez apporter un complément, veuillez laisser un commentaire sur cet article, ce sera appréciable.