La stratégie de groupe (GPO) en pratique — fonctionnement, vérification de l'application et choix entre GPO et Intune

« J’ai changé la GPO et rien n’a bougé. » « J’ai lancé gpupdate et le paramètre n’a toujours pas changé. » « L’application tourne sur le poste de développement mais pas sur les PC chez le client. » Des problèmes de ce type deviennent beaucoup plus faciles à investiguer une fois que l’on sépare quelles GPO sont dans la portée, quel paramètre l’emporte, et quand le traitement a eu lieu.

La stratégie de groupe est le mécanisme qui distribue et gère les paramètres Windows dans une organisation. Qu’on vous dise que quelque chose est « distribué par GPO » ne dit pas ce qui est réellement en vigueur sur un PC ou pour un utilisateur. Il faut comparer la configuration du côté qui distribue avec le résultat du côté qui reçoit.

Cet article est une introduction pratique pour le personnel informatique des PME qui a hérité d’un environnement AD, et pour les développeurs qui déploient des applications métier sur des PC joints au domaine. Il couvre l’ordre d’application, le moment où les paramètres prennent effet, le diagnostic avec gpresult et le journal d’événements, ADMX et le magasin central, et comment choisir entre GPO et Intune. Les explications s’appuient sur des sources primaires à la date d’août 2026.

Partez de ce que vous rencontrez

Pour une première lecture, prenez le vocabulaire au chapitre 2, comprenez le mécanisme aux chapitres 3 et 4, puis passez aux étapes de vérification du chapitre 5. Si vous êtes au milieu d’une investigation, commencez par le chapitre 5 et revenez aux explications de priorité et de moment selon ce que demandent les résultats.

1. La conclusion d’abord

« Quel paramètre l’emporte » et « quand il arrive » sont des problèmes distincts

La stratégie de groupe est traitée dans l’ordre local, site, domaine, OU (LSDOU), et lorsque le même paramètre entre en conflit, c’est la dernière écriture qui l’emporte. La GPO locale est la couche la plus faible. Cela dit, Bloquer l’héritage et Appliqué (Enforced) changent ce flux par défaut.¹

L’application a deux formes : le traitement au premier plan au démarrage et à la connexion, et l’actualisation en arrière-plan à un intervalle par défaut d’environ 90 minutes plus un décalage aléatoire de 0 à 30 minutes. L’actualisation en arrière-plan des contrôleurs de domaine est de 5 minutes par défaut. gpupdate /force réapplique tous les paramètres ; ce n’est pas une commande universelle qui applique aussi, sur-le-champ, les paramètres qui ne sont traités qu’à la connexion ou au redémarrage.²³

Vérifiez le résultat qui est arrivé avant de continuer à changer des choses

Le diagnostic commence par le rapport RSoP produit par gpresult /h. Vérifiez les GPO appliquées, les GPO refusées et leurs motifs, et la GPO gagnante pour chaque paramètre. Quand il faut creuser des échecs ou des retards de traitement, utilisez le journal opérationnel GroupPolicy.⁴⁵

Les paramètres des modèles d’administration s’écrivent, en règle générale, dans des emplacements du registre tels que Software\Policies, et les applications conscientes de la stratégie donnent à ces valeurs la priorité sur leurs propres paramètres. « Non configuré » n’écrit aucune valeur. Certains paramètres s’écrivent toutefois en dehors des clés dédiées : lorsqu’une valeur reste, vérifiez où elle a été écrite.⁶

Alignez la méthode de gestion sur les hypothèses dont dépend l’application

Dans un domaine, les définitions ADMX sont consolidées dans le magasin central PolicyDefinitions de SYSVOL. Il existe pour que GPMC référence un ensemble commun de modèles.⁷

Choisissez entre GPO et Intune selon le fondement d’identité de l’appareil et l’endroit où il est utilisé. Dans un environnement hybride, évitez de configurer deux fois le même paramètre et décidez qui possède chaque domaine. Group Policy analytics est utile pour trier les paramètres avant une migration.⁸⁹

Pour les développeurs aussi, la GPO fait partie de la spécification de l’environnement. Les paramètres qui changent les hypothèses d’une application, comme la stratégie d’exécution, la fusion des règles locales du pare-feu, et la configuration du proxy et des lecteurs, sont distribués de façon centralisée. Quand quelque chose « échoue seulement chez le client », confirmez ces hypothèses avec le rapport et les valeurs réelles.¹⁰¹¹

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (29 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Qu’est-ce que la stratégie de groupe — GPO locales et GPO de domaine

La stratégie de groupe est le mécanisme par lequel un administrateur définit de façon centralisée des paramètres Windows et les applique aux ordinateurs et utilisateurs cibles. Un ensemble de paramètres s’appelle une GPO (objet de stratégie de groupe).

Commencez par séparer « la GPO locale gérée à l’intérieur du PC lui-même » de « la GPO de domaine distribuée depuis AD ».

Où vivent les paramètres : local ou domaine

Un PC de groupe de travail, c’est-à-dire non joint à un domaine, ne traite que la GPO locale.¹ Autrement dit, quand on dit qu’une machine est « gérée par GPO », on désigne en pratique presque toujours une GPO de domaine.

flowchart TB
    accTitle: GPO traitées par un PC de groupe de travail et par un PC joint au domaine
    accDescr: Un PC de groupe de travail ne traite que la GPO locale, tandis qu'un PC joint au domaine traite aussi les GPO de domaine distribuées depuis Active Directory
    pc{"Comment le PC est-il joint ?"}
    pc -->|Groupe de travail| wg["Ne traite que la GPO locale"]
    pc -->|Joint au domaine| dom["GPO locale plus GPO de domaine"]
    dom -.-> note["Les GPO en pratique sont presque toutes des GPO de domaine"]

Figure 1 : Un PC de groupe de travail ne traite que la GPO locale, tandis qu’un PC joint au domaine traite aussi les GPO de domaine.

Ce que ciblent les paramètres : le PC ou l’utilisateur

Quelle que soit la GPO, son contenu se répartit en deux grandes branches.

• Configuration ordinateur : paramètres qui prennent effet pour quiconque se connecte à ce PC. Appliquée au démarrage.
• Configuration utilisateur : paramètres qui prennent effet pour cet utilisateur quel que soit le PC sur lequel il se connecte. Appliquée à la connexion.

L’axe « ce paramètre est-il lié au PC ou à la personne » revient de façon constante dans l’ordre d’application et dans la vérification qu’un paramètre a pris effet, tous deux traités ensuite. Certains éléments existent dans les deux branches : prenez l’habitude de regarder les deux chaque fois que vous cherchez un paramètre.

flowchart TB
    accTitle: Les deux branches à l'intérieur d'une GPO
    accDescr: Toute GPO a une branche Configuration ordinateur et une branche Configuration utilisateur, la Configuration ordinateur s'appliquant au démarrage et prenant effet pour quiconque se connecte à ce PC, et la Configuration utilisateur s'appliquant à la connexion et prenant effet quel que soit le PC sur lequel l'utilisateur se connecte
    gpo["Contenu d'une GPO"] --> comp["Configuration ordinateur"]
    gpo --> user["Configuration utilisateur"]
    comp --> boot["Appliquée au démarrage"]
    user --> logon["Appliquée à la connexion"]
    boot -.-> anyone["Prend effet pour quiconque se connecte"]
    logon -.-> anypc["Prend effet sur n'importe quel PC"]

Figure 2 : Une GPO a deux branches, Configuration ordinateur liée au PC et Configuration utilisateur liée à la personne.

3. Comment fonctionne l’application — le « dernière écriture gagne » du LSDOU et le contrôle de l’héritage

3.1. LSDOU : local, site, domaine, OU

Sur un PC joint au domaine, les GPO sont traitées dans l’ordre suivant.¹

1. La GPO locale
2. Les GPO liées au site
3. Les GPO liées au domaine
4. Les GPO liées à une OU (unité d’organisation) — traitées de l’OU la plus haute vers le bas, en terminant par les GPO de l’OU qui contient directement l’ordinateur ou l’utilisateur cible

Le nom LSDOU vient de ces initiales. Il exprime l’ordre dans lequel les stratégies sont traitées, et non un ordre « de la plus haute priorité vers le bas ».

Lorsque plusieurs GPO configurent le même paramètre, la GPO traitée plus tard l’emporte. Les paramètres qui n’entrent pas en conflit sont simplement combinés.¹

Dans cet ordre par défaut, la GPO de l’OU la plus proche de la cible est la plus forte et la GPO locale est la plus faible. « Je l’ai corrigé dans gpedit.msc et cela est revenu » est exactement ce comportement fonctionnant selon la spécification. Les exceptions qui changent l’héritage sont traitées à la section 3.2.

flowchart TB
    accTitle: L'ordre de traitement LSDOU et la dernière écriture l'emporte
    accDescr: Les GPO sont traitées dans l'ordre local, site, domaine, OU, et en cas de conflit la GPO traitée plus tard l'emporte, de sorte que la GPO de l'OU la plus proche de la cible est la plus forte et la GPO locale est la plus faible
    l["1. GPO locale"] --> s["2. Site"]
    s --> d["3. Domaine"]
    d --> ou["4. OU (du haut vers le bas)"]
    ou --> win["La dernière écriture l'emporte en cas de conflit"]
    win -.-> strongest["La GPO de l'OU la plus proche est la plus forte"]
    win -.-> weakest["La GPO locale est la plus faible"]

Figure 3 : LSDOU est l’ordre dans lequel les stratégies sont traitées, et lorsque le même paramètre entre en conflit, la GPO traitée plus tard l’emporte.

Au même emplacement, le plus petit numéro d’ordre de lien l’emporte

Lorsque plusieurs GPO sont liées au même site, domaine ou OU, consultez l’ordre des liens dans l’onglet « Objets de stratégie de groupe liés » de GPMC.

La GPO au plus petit numéro est traitée en dernier et a donc la plus haute priorité. Il importe de ne pas lire cela comme « un numéro plus bas signifie qu’elle est traitée en premier ».¹

flowchart TB
    accTitle: Ordre des liens lorsque plusieurs GPO sont au même emplacement
    accDescr: Lorsque plusieurs GPO sont liées au même site, domaine ou OU, l'ordre de traitement est décidé par l'ordre des liens dans GPMC, et la GPO au plus petit numéro est traitée en dernier et prend la plus haute priorité
    multi["Plusieurs GPO au même emplacement"] --> tab["Décidé par l'ordre des liens dans GPMC"]
    tab --> last["La GPO au plus petit numéro est traitée en dernier"]
    last --> win["L'emporte par dernière écriture et prend la plus haute priorité"]

Figure 4 : À la même cible de lien, la GPO au plus petit numéro d’ordre de lien est traitée en dernier et l’emporte.

3.2. Bloquer l’héritage et Appliqué (Enforced)

Bloquer l’héritage et Appliqué (Enforced) sont les mécanismes qui créent des exceptions à l’ordre par défaut de la section 3.1. Lisez-les en séparant où on les règle de ce qu’ils arrêtent.¹

• Bloquer l’héritage : réglé sur un domaine ou une OU, il arrête l’héritage des GPO depuis le niveau supérieur. C’est l’outil pour « cette OU seule ne doit pas recevoir le standard de toute l’entreprise ».
• Appliqué (anciennement No Override) : réglé sur un lien GPO, il fait que cette GPO s’applique toujours, même là où l’héritage est bloqué en dessous, et empêche les GPO inférieures de l’écraser. Lorsque Bloquer l’héritage et Appliqué se heurtent, Appliqué l’emporte.¹

flowchart TB
    accTitle: Comment Bloquer l'héritage et Appliqué se relient
    accDescr: Bloquer l'héritage arrête l'héritage des GPO depuis le niveau supérieur, mais une GPO appliquée s'applique toujours même là où l'héritage est bloqué en dessous et ne peut pas être écrasée par des GPO inférieures
    upper["GPO du niveau supérieur"] --> blocked{"Héritage bloqué en dessous ?"}
    blocked -->|Non| inherit["Hérité tel quel"]
    blocked -->|Oui| enforced{"Le lien GPO est-il appliqué ?"}
    enforced -->|Non| stop["L'héritage s'arrête"]
    enforced -->|Oui| apply["Toujours appliquée"]
    apply -.-> noover["Non écrasée par les GPO inférieures"]

Figure 5 : Bloquer l’héritage arrête l’héritage depuis le niveau supérieur, mais une GPO appliquée traverse le blocage et s’applique toujours.

Limitez l’usage d’Appliqué

Parce qu’Appliqué change le « dernière écriture l’emporte » par défaut, l’utiliser trop largement produit davantage de résultats qui ne correspondent pas à l’intuition, même en lisant le RSoP. La règle empirique est de le limiter à des choses comme les paramètres de sécurité qui doivent absolument tenir dans toute l’entreprise.

Cela couvre l’héritage et la priorité. Qu’une GPO puisse s’appliquer à une cible est aussi décidé par le filtrage de sécurité, qui vient ensuite.

3.3. Filtrage de sécurité

L’application exige à la fois « Lecture » et « Appliquer »

Au-delà de la cible du lien, à qui une GPO s’applique peut aussi être restreint par GPO. L’utilisateur ou l’ordinateur cible doit détenir à la fois les autorisations « Lecture » et « Appliquer la stratégie de groupe » sur cette GPO.¹³

Par défaut, Utilisateurs authentifiés, qui inclut les utilisateurs et les ordinateurs, détient les deux autorisations, de sorte que tout ce qui est sous la cible du lien est dans la portée. Restreindre cela à un groupe de sécurité précis, c’est le filtrage de sécurité.

Le filtre s’applique à la GPO dans son ensemble. Ce n’est pas un mécanisme pour restreindre des paramètres individuels à l’intérieur d’une GPO vers des cibles différentes.¹³

Pour les GPO côté utilisateur, gardez aussi l’autorisation Lecture du PC

Lorsque vous restreignez la cible, ne retirez pas « Lecture » à Utilisateurs authentifiés. Depuis MS16-072 (2016), la stratégie côté utilisateur est récupérée dans le contexte de sécurité de l’ordinateur. Si le PC ne peut pas lire la GPO, elle ne s’appliquera pas même lorsque l’utilisateur cible détient les deux autorisations.¹⁴

Pensez les autorisations requises comme deux choses distinctes.

• Donnez au groupe cible Lecture plus Appliquer la stratégie de groupe.
• Laissez Lecture seulement à Utilisateurs authentifiés ou à Ordinateurs du domaine. L’autorisation Appliquer n’est pas nécessaire.¹⁴

flowchart TB
    accTitle: Comment le filtrage de sécurité décide si une GPO s'applique
    accDescr: Pour qu'une GPO s'applique, l'utilisateur ou l'ordinateur cible doit détenir à la fois les autorisations Lecture et Appliquer la stratégie de groupe, et une GPO côté utilisateur exige en plus que le compte ordinateur puisse la lire
    target["Cible sous le lien GPO"] --> perm{"Lecture et Appliquer toutes deux ?"}
    perm -->|Non| deny["Refusé par le filtrage"]
    perm -->|Oui| usergpo{"GPO côté utilisateur ?"}
    usergpo -->|Non| apply["Appliquée"]
    usergpo -->|Oui| comp{"L'ordinateur peut-il la lire ?"}
    comp -->|Oui| apply
    comp -->|Non| deny2["Non appliquée (MS16-072)"]

Figure 6 : L’application exige à la fois « Lecture » et « Appliquer la stratégie de groupe », et une GPO côté utilisateur exige aussi que le compte ordinateur ait Lecture.

Après un changement de groupe, confirmez avec un nouveau jeton

Cibler le mauvais objet — « le paramètre est côté ordinateur, mais seul l’utilisateur a été ajouté au groupe » — est un écueil courant. Vérifiez d’abord si le paramètre est côté ordinateur ou côté utilisateur.

L’autre est « je les ai retirés du groupe et cela s’applique encore ». L’appartenance est évaluée à partir du jeton de sécurité construit à la connexion, de sorte qu’attendre simplement une actualisation en arrière-plan ne change rien.

Le changement de groupe d’un utilisateur atteint le filtre après une déconnexion et une reconnexion, et celui d’un ordinateur après un redémarrage, une fois qu’un nouveau jeton a été construit.

flowchart TB
    accTitle: Combien de temps un changement de groupe met à atteindre le filtre
    accDescr: L'appartenance à un groupe est évaluée à partir du jeton de sécurité construit à la connexion, de sorte que le changement d'un utilisateur n'atteint le filtre qu'après une nouvelle connexion et celui d'un ordinateur qu'après qu'un redémarrage a construit un nouveau jeton
    change["Changer les membres d'un groupe"] --> old["Non reflété tant que l'ancien jeton tient"]
    old --> u["L'utilisateur se reconnecte"]
    old --> c["L'ordinateur redémarre"]
    u --> token["Évalué avec le nouveau jeton"]
    c --> token
    token --> ok["Reflété dans le filtre"]
    old -.-> bg["Une actualisation en arrière-plan ne le résout pas"]

Figure 7 : Un changement de groupe n’atteint le filtre que lorsqu’une déconnexion ou un redémarrage construit un nouveau jeton.

Une application pour les PC partagés : le traitement de bouclage

Sur les PC partagés et les serveurs Bureau à distance, on veut parfois « échanger la Configuration utilisateur pour quiconque se connecte à ce PC ». Le mode spécial pour cela est le traitement de bouclage.

Il applique les paramètres utilisateur d’après l’emplacement de l’ordinateur, et a deux modes, Remplacer et Fusionner. C’est une fonction avancée utilisée sur les bornes kiosque et les PC de salle de classe, et cet article se contente de noter qu’elle existe.¹⁵

flowchart TB
    accTitle: L'idée derrière le traitement de bouclage
    accDescr: Le traitement de bouclage est un mode spécial qui applique la Configuration utilisateur d'après l'emplacement de l'ordinateur, a les deux modes Remplacer et Fusionner, et s'utilise là où chaque personne qui se connecte doit recevoir les mêmes paramètres utilisateur, comme les PC partagés et les bornes kiosque
    shared["PC partagés, bornes kiosque et assimilés"] --> lb["Traitement de bouclage"]
    lb --> base["Décidé par l'emplacement de l'ordinateur"]
    base --> rep["Mode Remplacer"]
    base --> mrg["Mode Fusionner"]
    lb -.-> aim["Prend effet pour quiconque se connecte"]

Figure 8 : Le traitement de bouclage est un mode spécial qui applique la Configuration utilisateur d’après l’emplacement de l’ordinateur, et il a les deux modes Remplacer et Fusionner.

4. Quand les paramètres prennent effet — traitement au premier plan et actualisation en arrière-plan

Après un changement de paramètre, le moment de l’application peut simplement ne pas être encore venu. Ici, séparez si l’appareil peut joindre un DC de quand ce paramètre particulier est traité.²

Séparer le démarrage et la connexion des actualisations pendant que la machine tourne

D’abord, l’appareil doit pouvoir joindre un DC

Sur un appareil en fonctionnement qui peut joindre un contrôleur de domaine, les paramètres qui prennent en charge l’actualisation en arrière-plan se propagent dans le parc en environ deux heures par défaut. Ils n’atteignent pas les appareils hors ligne, ni les portables emmenés hors site sans connexion VPN, jusqu’à la prochaine fois que l’appareil se connecte à un DC.

Les paramètres qui ne sont jamais appliqués que par le traitement au premier plan exigent d’attendre en plus un démarrage ou une connexion.

La différence entre gpupdate et /force

Lorsque vous êtes pressé, exécutez gpupdate sur le PC cible. Normalement, il n’applique que les paramètres qui ont changé ; l’ajout de /force réapplique tous les paramètres, qu’ils aient changé ou non.³

rem Actualiser seulement ce qui a changé (normalement cela suffit)
gpupdate

rem Réappliquer tous les paramètres (quand on soupçonne l'état en cache)
gpupdate /force

flowchart TB
    accTitle: Joignabilité du DC et comment les paramètres arrivent
    accDescr: Sur un appareil en fonctionnement qui peut joindre un contrôleur de domaine, les paramètres qui prennent en charge l'actualisation en arrière-plan se propagent en environ deux heures, mais ils n'atteignent pas un appareil hors ligne ou un portable emmené hors site sans connexion VPN jusqu'à sa prochaine connexion à un DC
    pc{"Peut-il joindre un DC ?"}
    pc -->|Oui| ok["Se propage en environ deux heures"]
    pc -->|Non| ng["N'arrive pas tant qu'il ne se connecte pas"]
    ng -.-> ex["Appareils hors ligne et portables hors site sans VPN"]

Figure 9 : Un appareil en fonctionnement qui peut joindre un DC reçoit les paramètres en environ deux heures, tandis qu’un appareil hors ligne ne reçoit rien jusqu’à sa prochaine connexion à un DC.

Même /force ne peut pas sauter le traitement au premier plan

L’installation de logiciel côté utilisateur et la redirection de dossiers ne sont traitées qu’à la connexion, et l’installation de logiciel côté ordinateur seulement au démarrage.³

L’option /logoff de gpupdate déconnecte après l’actualisation et /boot redémarre après. Lorsque l’ajout de /force ne change rien, vérifiez si le paramètre fait partie des types qui exigent une connexion ou un redémarrage.³

flowchart TB
    accTitle: Les chemins par lesquels un paramètre prend effet
    accDescr: Un changement de GPO arrive dans l'intervalle par défaut d'environ 90 minutes plus un décalage de 0 à 30 minutes si le paramètre prend en charge l'actualisation en arrière-plan, tandis qu'un paramètre appliqué seulement par le traitement au premier plan doit attendre un démarrage ou une connexion, et même gpupdate a besoin de /logoff ou /boot pour les paramètres uniquement au premier plan lorsque vous êtes pressé
    change["Changer une GPO"] --> kind{"Prend en charge l'actualisation en arrière-plan ?"}
    kind -->|Oui| bg["Actualisé en environ 90 minutes plus 0 à 30"]
    kind -->|Non| fg["Appliqué au démarrage ou à la connexion"]
    bg --> done["Prend effet"]
    fg --> done
    rush["Lorsque vous êtes pressé"] -.-> upd["Exécuter gpupdate"]
    upd -.-> force["/force réapplique tout"]
    upd -.-> reboot["Le premier plan a besoin de /logoff ou /boot"]

Figure 10 : L’actualisation en arrière-plan ne livre que les paramètres qui la prennent en charge, et les paramètres appliqués seulement par le traitement au premier plan ont encore besoin d’une déconnexion ou d’un redémarrage après gpupdate.

5. Diagnostiquer quand un paramètre ne prend pas effet — gpresult, le journal d’événements et le registre

Les outils n’ont pas le même rôle. gpresult montre le résultat de l’application, le journal opérationnel montre le déroulement du traitement, et le registre montre les valeurs réellement écrites. Plutôt que de changer tout de suite les paramètres à nouveau, resserrez la cause à partir du résultat.

5.1. Vérifier le RSoP avec gpresult /h

Le résultat final de plusieurs GPO qui se superposent s’appelle RSoP (Resultant Set of Policy). L’outil standard gpresult produit un rapport HTML depuis une invite de commandes avec élévation, plus facile à lire.⁴⁵

Dans l’exemple ci-dessous, créez le dossier de sortie C:\temp avant d’exécuter. Lorsque vous lisez le rapport, confirmez aussi qu’il s’agit du résultat pour le PC et l’utilisateur que vous voulez investiguer.

rem Écrire un rapport HTML du RSoP pour l'utilisateur et l'ordinateur
gpresult /h C:\temp\gp-report.html /f

rem Pour ne vérifier que le résumé dans la console
gpresult /r
gpresult /scope computer /r

Ne vous arrêtez pas à « elle a été appliquée »

Dans le rapport, regardez les trois points suivants dans l’ordre. Même lorsque la GPO voulue est dans la liste, le paramètre n’aura pas la valeur attendue si une autre GPO l’écrase.

1. La liste des GPO appliquées — la GPO voulue y figure-t-elle
2. La liste des GPO refusées et les motifs — le motif pour lequel elle n’a pas été appliquée, comme le filtrage de sécurité, un filtre WMI ou une GPO vide, est affiché⁵
3. La GPO gagnante pour chaque paramètre — la valeur de quelle GPO a décidé le paramètre qui vous intéresse. Si une autre GPO l’emporte, revenez aux règles de priorité du chapitre 3

flowchart TB
    accTitle: Les trois points à regarder d'abord dans un rapport RSoP
    accDescr: Dans un rapport gpresult, vérifiez d'abord si la GPO voulue figure dans la liste des GPO appliquées, puis la liste des GPO refusées et les motifs, et enfin utilisez la GPO gagnante pour chaque paramètre pour identifier dont la valeur l'a emporté
    rep["Ouvrir le rapport RSoP"] --> one["1. Liste des GPO appliquées"]
    one --> two["2. GPO refusées et motifs"]
    two --> three["3. GPO gagnante par paramètre"]
    three -.-> review["Revenir si une autre GPO l'emporte"]

Figure 11 : Lisez un rapport RSoP dans l’ordre GPO appliquées, GPO refusées et motifs, et GPO gagnante pour chaque paramètre.

5.2. Le journal opérationnel GroupPolicy

Suivre les échecs et les retards de traitement

Les échecs que gpresult seul ne révèle pas, et les problèmes où le traitement prend trop de temps, se vérifient dans le journal opérationnel GroupPolicy de l’Observateur d’événements.

Son emplacement est Journaux des applications et des services > Microsoft > Windows > GroupPolicy > Operational. Le nom du journal est Microsoft-Windows-GroupPolicy/Operational, et il consigne tout, du début à la fin du traitement, les listes des GPO appliquées et refusées, et les motifs de refus.⁵

Resserrer à une seule exécution de traitement avec ActivityID

Chaque exécution du traitement de stratégie se voit attribuer un ActivityID unique. La procédure documentée par Microsoft consiste à relever l’ActivityID d’un avertissement ou d’une erreur dans le journal Système et à utiliser une vue personnalisée pour resserrer les événements de cette même exécution. Ainsi vous suivez une exécution du début à la fin sans mélanger les enregistrements d’une autre.⁵

flowchart TB
    accTitle: Comment resserrer le journal opérationnel GroupPolicy
    accDescr: Chaque exécution du traitement de stratégie se voit attribuer un ActivityID unique dans le journal opérationnel GroupPolicy, donc relevez l'ActivityID d'un avertissement ou d'une erreur dans le journal Système et utilisez une vue personnalisée pour resserrer la lecture aux événements de cette seule exécution
    sys["Avertissement ou erreur dans le journal Système"] --> aid["Relever l'ActivityID"]
    aid --> cv["Resserrer avec une vue personnalisée"]
    cv --> one["Lire les événements d'une exécution de traitement"]
    one -.-> rec["Listes des GPO appliquées et refusées avec motifs"]

Figure 12 : Pour le journal opérationnel, relevez l’ActivityID dans le journal Système et utilisez une vue personnalisée pour ne lire qu’une exécution du traitement de stratégie.

5.3. La relation avec les clés Policies du registre

Les stratégies des modèles d’administration, traitées au chapitre suivant, s’écrivent au final comme des valeurs de registre. En règle générale, elles s’écrivent dans les clés de stratégie dédiées suivantes.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Configuration ordinateur ; l’emplacement recommandé)
• HKEY_CURRENT_USER\Software\Policies (Configuration utilisateur ; l’emplacement recommandé)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies et HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Les valeurs de stratégie sont lues avant les paramètres propres de l’application

Une application consciente de la stratégie se comporte ainsi : elle lit d’abord la clé Policies, utilise cette valeur s’il y en a une, et retombe sur son propre paramètre ou une valeur par défaut s’il n’y en a pas. Une stratégie laissée « Non configuré » n’écrit aucune valeur dans le registre.⁶

Autrement dit, un modèle d’administration qui utilise les clés de stratégie dédiées ne réécrit pas le paramètre propre de l’application pour y laisser un « tatouage » ; il place une valeur imposée ailleurs. Cessez de la configurer et l’application revient à suivre son propre paramètre.

flowchart TB
    accTitle: Priorité entre une valeur de stratégie et un paramètre d'application
    accDescr: Une application consciente de la stratégie lit d'abord la clé Policies et utilise cette valeur s'il y en a une, sinon elle utilise son propre paramètre ou une valeur par défaut, et une stratégie laissée Non configuré n'écrit rien dans le registre
    app["Une application consciente de la stratégie lit un paramètre"] --> haspol{"Y a-t-il une valeur dans la clé Policies ?"}
    haspol -->|Oui| pol["La valeur de stratégie l'emporte"]
    haspol -->|Non| pref["Utilise son propre paramètre ou une valeur par défaut"]
    notconf["Une stratégie Non configuré"] -.-> nowrite["N'écrit rien dans le registre"]

Figure 13 : Une stratégie ne réécrit pas le paramètre propre de l’application ; une valeur imposée placée ailleurs est lue avec une priorité plus élevée.

Attention aux paramètres qui s’écrivent hors des clés dédiées et laissent des valeurs

Toutes les stratégies ne s’écrivent pas dans une clé dédiée. « Activer les chemins longs Win32 », par exemple, s’écrit dans LongPathsEnabled sous HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. Les modèles d’ancienne génération et les modèles tiers en comprennent aussi qui s’écrivent vers des chemins arbitraires.

Ce type de paramètre laisse sa valeur même après que vous avez cessé de configurer la stratégie. Vérifiez dans quelle clé le paramètre qui vous intéresse s’écrit, à l’aide de la définition ADMX, du texte explicatif du paramètre et du rapport gpresult.

Les valeurs écrites hors des clés dédiées par un script ou par les Préférences de stratégie de groupe sont aussi des valeurs de registre ordinaires. Contrairement aux clés de stratégie dédiées, traitez-les comme des valeurs qui restent après que vous avez cessé de les configurer.

Vérifiez où la valeur a réellement été écrite

Commencez par regarder les valeurs réelles sous les clés Policies. Mais ne concluez pas que « la GPO n’a aucune influence ici » simplement parce qu’il n’y a rien : vérifiez aussi si le paramètre est du type qui s’écrit hors des clés dédiées. Les commandes ci-dessous sont un exemple de consultation sous Policies, là où la plupart des stratégies s’écrivent.

# Example of checking values distributed by policy directly (most policies write under Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Étapes de diagnostic lorsqu'un paramètre ne prend pas effet
    accDescr: Vérifiez d'abord les GPO appliquées et refusées dans le rapport RSoP de gpresult, puis resserrez le journal opérationnel GroupPolicy par ActivityID si cela ne suffit pas, et confirmez les valeurs distribuées directement dans les clés Policies du registre
    start["Le paramètre ne prend pas effet"] --> rsop["Vérifier le RSoP avec gpresult /h"]
    rsop --> found{"Voyez-vous les motifs appliqués et refusés ?"}
    found -->|Oui| fix["Revenir à la priorité et au filtrage"]
    found -->|Non| oplog["Lire le journal opérationnel GroupPolicy"]
    oplog -.-> aid["Resserrer à une exécution avec ActivityID"]
    rsop -.-> reg["Vérifier les valeurs réelles dans les clés Policies"]

Figure 14 : Le diagnostic avance mécaniquement de gpresult /h, au journal opérationnel GroupPolicy lorsque cela ne suffit pas, puis à une vérification directe des clés Policies pour les valeurs réelles.

6. Modèles d’administration (ADMX) et magasin central

ADMX contient les définitions, ADML les chaînes d’affichage

Les éléments listés sous « Modèles d’administration » dans GPMC ont leurs définitions de paramètres écrites dans des fichiers ADMX et leurs chaînes d’affichage par langue dans des fichiers ADML.

Chaque PC a les définitions livrées avec le système d’exploitation dans C:\Windows\PolicyDefinitions, et les outils de gestion les lisent pour construire l’écran des paramètres.⁷

Dans un domaine, référencez un magasin central partagé

Pour l’exploitation de domaine, créez un dossier PolicyDefinitions sous SYSVOL sur un DC. Un exemple est \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions.

Le contenu est répliqué vers chaque DC du domaine, et les outils de stratégie de groupe référencent alors le magasin central par défaut. Il existe pour éviter le problème de versions de modèles différentes entre machines d’administration, de sorte que les éléments visibles ne correspondent plus. Les fichiers ADML vont dans des sous-dossiers par langue tels que ja-JP.⁷

flowchart TB
    accTitle: Comment fonctionne le magasin central
    accDescr: Créer un dossier PolicyDefinitions sous SYSVOL sur un contrôleur de domaine réplique son contenu vers chaque contrôleur de domaine et fait que les outils de stratégie de groupe référencent le magasin central par défaut, de sorte que les définitions ne diffèrent plus entre machines d'administration
    create["Le créer sous SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["Répliqué vers chaque DC"]
    cs --> ref["Les outils GP le référencent par défaut"]
    ref -.-> benefit["Les écarts de définition entre machines disparaissent"]
    cs -.-> adml["Les fichiers ADML vont dans des dossiers par langue"]

Figure 15 : Le dossier PolicyDefinitions de SYSVOL est répliqué vers chaque contrôleur de domaine, et les outils de stratégie de groupe le référencent par défaut.

Préparez les mises à jour dans un dossier de travail, puis basculez

Microsoft distribue des fichiers ADMX pour les nouvelles versions de Windows, version par version. Ce que vous mettez à jour, c’est le magasin central. Remplacer C:\Windows\PolicyDefinitions sur chaque PC par la version téléchargée n’est pas pris en charge.⁷

Mettez à jour un magasin existant en suivant les étapes ci-dessous plutôt qu’en écrasant directement le dossier de production.

1. Préparez un dossier de travail portant un nom de version, tel que PolicyDefinitions-24H2.
2. Assemblez l’ensemble ADMX complet pour le système d’exploitation et pour des applications telles qu’Office et Edge.
3. Renommez le PolicyDefinitions actuel en quelque chose comme PolicyDefinitions-23H2 pour le mettre de côté.
4. Renommez le dossier de travail en PolicyDefinitions pour qu’il soit référencé comme production.⁷

Le dossier qui est référencé est celui nommé PolicyDefinitions. Placer simplement des fichiers dans un dossier portant un nom de version n’a aucun effet. Garder l’ancien dossier de côté permet de revenir en arrière si quelque chose se passe mal.⁷

flowchart TB
    accTitle: Étapes pour mettre à jour le magasin central
    accDescr: Pour mettre à jour, assemblez l'ensemble ADMX complet pour le système d'exploitation et les applications dans un dossier de travail portant un nom de version, renommez le dossier actuel pour le mettre de côté, puis renommez le dossier de travail au nom de production PolicyDefinitions, et revenez au dossier mis de côté si un problème survient
    work["Dossier de travail portant un nom de version"] --> gather["Assembler les ensembles OS et applications"]
    gather --> evac["Renommer l'actuel et le mettre de côté"]
    evac --> rename["Renommer le dossier de travail au nom de production"]
    rename --> live["Référencé comme production"]
    live -.-> back["Revenir à l'ancien dossier en cas de problème"]

Figure 16 : Pour une mise à jour, assemblez l’ensemble complet dans un dossier de travail, mettez l’actuel de côté, et passez en production par renommage.

7. GPO face à Intune (MDM/CSP) face à la distribution manuelle et par script — un tableau de décision

La GPO n’est plus la seule option pour la gestion de configuration des appareils Windows. Le MDM, dont Intune est le représentant, configure les paramètres du système d’exploitation par un mécanisme appelé CSP (Configuration Service Provider). Voici un tableau de décision pour choisir autour de lequel construire.

Décidez d’après le fondement d’identité de l’appareil et son emplacement

La base est si l’appareil est fondé sur AD ou sur Microsoft Entra, et où il est utilisé. La GPO est fiable pour les PC de bureau en entreprise joints au domaine d’un AD local, tandis que les GPO de domaine n’atteignent jamais un PC mobile joint à Entra.

L’important est de ne pas traiter les appareils en entreprise et hors site comme ayant les mêmes conditions de joignabilité.

Dans un environnement hybride, décidez qui possède chaque paramètre

Même dans les PME, l’exploitation hybride qui combine la jointure au domaine et l’inscription Intune est courante. Ce qu’il faut éviter ici, c’est de configurer le même paramètre à la fois par GPO et par MDM.

Policy CSP inclut MDMWinsOverGP, qui donne la priorité au MDM en cas de conflit. Il s’applique toutefois seulement aux stratégies correspondantes à l’intérieur de Policy CSP. Configurer deux fois un paramètre qui n’est pas sous ce contrôle ne garantit pas lequel l’emporte. Microsoft déconseille aussi la configuration en double.⁸

Le principe est de décider « ce domaine est GPO, celui-là est Intune » et de confier chaque domaine à l’un des deux.

flowchart TB
    accTitle: Choisir entre GPO et Intune
    accDescr: La GPO convient aux appareils dont le fondement d'identité est l'AD local et qui restent en entreprise, Intune convient aux appareils joints à Entra et hors site, et dans un environnement hybride on évite de configurer deux fois le même paramètre et on confie chaque domaine de paramètre à un seul côté
    q{"Fondement d'identité et emplacement ?"}
    q -->|Joint à AD et en entreprise| gpo["La GPO est fiable et fine"]
    q -->|Joint à Entra ou hors site| intune["Intune atteint les appareils hors site"]
    q -->|Hybride| split["Confier chaque domaine à un seul côté"]
    split -.-> warn["La configuration en double n'a pas de résultat garanti"]
    split -.-> ana["Utiliser Group Policy analytics pour trier"]

Figure 17 : Choisissez d’après le fondement d’identité de l’appareil et son emplacement, et dans un environnement hybride ne configurez pas le même paramètre à la fois par GPO et par MDM.

Utilisez Group Policy analytics pour trier avant de déplacer

Le point d’entrée pour envisager une migration est Group Policy analytics d’Intune. Importez des GPO exportées en XML depuis GPMC et il analyse, paramètre par paramètre, ce qui est pris en charge par le MDM, ce qui est déconseillé et ce qui ne peut pas l’être. Les paramètres pris en charge peuvent être migrés vers une stratégie de catalogue de paramètres Intune.⁹

Utilisez-le non pas comme « un outil qui déplace tout », mais comme un outil pour trier ce qui peut être déplacé, ce qui ne peut pas, et ce qu’il faut abandonner.

La propriété de la gestion de Windows Update est réorganisée dans le même contexte. Voir aussi « La gestion de Windows Update après la dépréciation de WSUS ».

flowchart TB
    accTitle: Trier avec Group Policy analytics
    accDescr: Importer des GPO exportées en XML depuis GPMC dans Group Policy analytics trie chaque paramètre selon que le MDM le prend en charge ou qu'il est déconseillé ou non pris en charge, et les paramètres pris en charge peuvent être migrés vers une stratégie de catalogue de paramètres
    exp["Exporter en XML depuis GPMC"] --> imp["Importer dans analytics"]
    imp --> ana["Analyser la prise en charge par paramètre"]
    ana --> ok["Pris en charge par le MDM"]
    ana --> dep["Déconseillé ou non pris en charge"]
    ok --> mig["Migrer vers une stratégie de catalogue de paramètres"]

Figure 18 : Group Policy analytics importe les GPO exportées et trie les paramètres qui peuvent passer au MDM de ceux qui ne le peuvent pas.

8. Écueils du point de vue d’un développeur — la GPO du client change le comportement de l’application

Enfin, voici ce qu’il faut garder à l’esprit depuis la position du Custom Software Development. Les GPO du client réécrivent discrètement les hypothèses dont dépend votre application. À côté des pare-feu et des antivirus, la GPO est un suspect habituel derrière « cela marche sur le poste de développement mais pas chez le client ». Voici des exemples issus de la pratique.

La stratégie d’exécution PowerShell

La stratégie d’exécution peut être configurée de façon centralisée par GPO, et les portées MachinePolicy et UserPolicy qui viennent de la GPO prennent toujours le dessus sur les valeurs réglées localement ou par processus.¹⁰ Si un installateur ou un script d’exploitation est construit sur l’hypothèse que « ajouter -ExecutionPolicy Bypass devrait le faire s’exécuter », il ne démarrera même pas sous gestion GPO. Pour le détail, voir « Politique d’exécution PowerShell et signature de scripts ».

Fusion des règles locales du pare-feu désactivée

Dans les environnements où le pare-feu est géré de façon centralisée par GPO ou Intune, la fusion des règles locales (AllowLocalPolicyMerge) peut être désactivée par profil. Là où elle est désactivée, les règles entrantes qu’un installateur a enregistrées localement existent mais ne sont pas appliquées.¹¹ C’est un point à vérifier sans faute avant de déployer une application de type serveur, et il est traité en détail dans « Windows Defender Firewall et les applications métier ».

Mappages de lecteurs, proxys et autre configuration d’environnement

Les mappages de lecteurs réseau, les imprimantes et assimilés sont typiquement distribués par les Préférences de stratégie de groupe.¹⁶ Des hypothèses d’environnement telles que « il devrait y avoir un lecteur Z » ou « le proxy devrait être une connexion directe » s’effondrent selon l’utilisateur qui se connecte et l’OU à laquelle le PC appartient. Autre chose que les applications résidentes oublient facilement : les paramètres distribués par la Configuration utilisateur ne sont, naturellement, pas appliqués aux comptes sous lesquels s’exécutent les services et les tâches planifiées.

Le paramètre ne peut déjà plus être changé en retour

Les paramètres issus des modèles d’administration deviennent normalement impossibles à changer depuis l’interface utilisateur ; l’élément est grisé. Le fait que « cela sera réglé si vous faites changer le paramètre par le client » ne fonctionne pas a des conséquences sur la façon de concevoir le plan de réponse.

flowchart TB
    accTitle: Les hypothèses qu'une GPO client change
    accDescr: Les GPO d'un client changent les hypothèses d'une application en imposant la stratégie d'exécution, en désactivant la fusion des règles locales du pare-feu, en distribuant les mappages de lecteurs et les paramètres de proxy, et en laissant l'utilisateur incapable de changer les paramètres en retour, ce qui est une raison pour laquelle une application échoue seulement chez le client
    gpo["Les GPO du client"] --> ep["Stratégie d'exécution imposée"]
    gpo --> fw["Fusion des règles locales désactivée"]
    gpo --> env["Distribution des lecteurs et du proxy"]
    gpo --> lock["Les paramètres ne peuvent pas être changés en retour"]
    ep --> sym["Une raison pour laquelle cela échoue seulement chez le client"]
    fw --> sym
    env --> sym
    lock --> sym

Figure 19 : Les GPO du client réécrivent discrètement les hypothèses d’une application, y compris la stratégie d’exécution, le pare-feu et la configuration d’environnement.

Décidez à l’avance ce que les développeurs vérifient avant le déploiement et pendant un incident

Il y a trois préparations à faire.

Où tracer la ligne sur les privilèges est traité dans « Quand Windows exige-t-il réellement des privilèges administrateur ». La GPO n’est pas votre ennemie ; elle fait partie de la spécification de l’environnement. Traitez-la comme une spécification et alignez les points à confirmer avec l’administrateur, et le diagnostic peut avancer mécaniquement.

flowchart TB
    accTitle: Les trois préparations côté développement
    accDescr: Les trois préparations côté développement sont de documenter les hypothèses d'environnement dont dépend l'application comme exigences de déploiement et de demander au service informatique du client de les confirmer avant le déploiement, de vérifier le rapport gpresult et les valeurs réelles dans les clés Policies pendant un incident, et de séparer le traitement qui a besoin de privilèges administrateur à la conception
    dev["Préparation côté développement"] --> doc["1. Documenter les hypothèses d'environnement"]
    dev --> chk["2. Confirmer avec gpresult et les valeurs réelles"]
    dev --> priv["3. Séparer les besoins de privilèges dans la conception"]
    doc -.-> ask["Demander au service informatique du client avant le déploiement"]

Figure 20 : Les trois préparations côté développement sont de documenter les hypothèses d’environnement, de confirmer avec gpresult et les valeurs réelles, et de séparer les besoins de privilèges administrateur dans la conception.

9. Synthèse

• La stratégie de groupe est un mécanisme qui traite les paramètres par GPO dans l’ordre local, site, domaine, OU (LSDOU), et les conflits sont tranchés par la dernière écriture. La GPO de l’OU la plus proche de la cible est la plus forte et la GPO locale est la couche la plus faible.
• Bloquer l’héritage, Appliqué et le filtrage de sécurité permettent de contrôler le flux par défaut. Appliqué l’emporte aussi sur Bloquer l’héritage : ne l’utilisez pas trop.
• L’application a deux formes : le traitement au premier plan au démarrage et à la connexion, et une actualisation en arrière-plan à un intervalle par défaut d’environ 90 minutes plus un décalage aléatoire. gpupdate /force réapplique tous les paramètres, et il n’a aucun effet sur les paramètres qui ne sont jamais traités qu’à la connexion ou au redémarrage.
• Lorsqu’un paramètre ne prend pas effet, diagnostiquez mécaniquement dans l’ordre gpresult /h, puis le journal opérationnel GroupPolicy, puis les clés Policies du registre. Les GPO refusées viennent avec un motif.
• Les définitions des modèles d’administration vivent dans des fichiers ADMX et ADML, et dans un domaine elles sont consolidées dans le magasin central de SYSVOL. Pour mettre à jour, basculez le côté magasin central plutôt que de remplacer le PolicyDefinitions local.
• Décidez entre GPO et Intune d’après le fondement d’identité de l’appareil et son emplacement, et dans un environnement hybride évitez de configurer deux fois le même paramètre et confiez chaque domaine à un seul propriétaire. Group Policy analytics est utile pour trier une migration.
• Pour les développeurs, les GPO du client font partie de la spécification de l’environnement. Documentez les hypothèses, comme la stratégie d’exécution, le pare-feu et la configuration des lecteurs et du proxy, et installez la pratique de les confirmer avec gpresult, et la plupart des cas de « cela échoue seulement chez le client » cessent d’être inquiétants.

Articles connexes

• Windows Defender Firewall et les applications métier — enregistrer les règles entrantes depuis l’installateur
• La gestion de Windows Update après la dépréciation de WSUS — comment choisir entre WUfB, Autopatch et Intune
• Politique d’exécution PowerShell et signature de scripts — Guide pratique pour sortir de l’exploitation « on colmate avec Bypass »
• Automatiser le déploiement de postes avec winget et PowerShell — Rendre le manuel de procédure exécutable
• Guide pour sortir de la dépendance au mode IE
• Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception

Domaines de conseil connexes

KomuraSoft LLC prend en charge l’investigation de cause lorsqu’une application métier échoue dans un environnement client sous gestion GPO, l’organisation des exigences de déploiement telles que la stratégie d’exécution, le pare-feu et les hypothèses réseau, et le conseil technique sur les inventaires de stratégies et la stratégie de coexistence avec Intune pour le personnel informatique qui a hérité d’un environnement AD. Commencer par quelque chose comme « lisez ce rapport gpresult avec moi » convient tout à fait.

• Conseil technique et revue de conception
• Investigation de bogues et analyse de cause racine
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

J'ai exécuté gpupdate /force, mais le paramètre ne s'applique toujours pas. Pourquoi ?

Vérifiez d'abord si ce paramètre fait partie des types qu'une actualisation en arrière-plan n'applique jamais. L'installation de logiciel côté utilisateur et la redirection de dossiers ne sont traitées qu'à la connexion, et l'installation de logiciel côté ordinateur seulement au démarrage : une fois gpupdate terminé, une déconnexion (/logoff) ou un redémarrage (/boot) est donc nécessaire. Ensuite, générez un rapport RSoP avec gpresult /h et vérifiez si cette GPO figure dans la liste des GPO appliquées, et si elle figure dans la liste des GPO refusées avec un motif. Si elle est appliquée mais que le comportement ne change pas, soupçonnez qu'une autre GPO de priorité plus élevée écrase le même paramètre (c'est la dernière écrite qui l'emporte). Le rapport affiche la GPO gagnante pour chaque paramètre, ce qui permet d'identifier précisément laquelle l'emporte.

Que signifie « Refusé (filtrage) » dans un rapport gpresult ?

Cela signifie que la GPO est bien dans la portée au niveau de l'emplacement du lien, mais que le filtrage l'a exclue de l'application. La cause la plus courante est le filtrage de sécurité : pour qu'une GPO s'applique, l'utilisateur ou l'ordinateur doit disposer à la fois de l'autorisation Lecture et de l'autorisation Appliquer la stratégie de groupe sur cette GPO. Par défaut, les deux sont accordées à Utilisateurs authentifiés, mais si vous les restreignez à des groupes précis, une appartenance de groupe manquante ou un compte ordinateur oublié entraîne un refus. Pour les GPO côté utilisateur, accorder les deux autorisations à l'utilisateur cible ne suffit pas. Depuis MS16-072, les stratégies utilisateur sont récupérées dans le contexte de sécurité de l'ordinateur : il faut donc laisser Lecture (Appliquer n'est pas nécessaire) à Utilisateurs authentifiés ou à Ordinateurs du domaine. D'autres causes sont un filtre WMI dont la condition ne correspond pas, ou la désactivation du côté utilisateur ou ordinateur de la GPO. Le motif du refus est consigné à la fois dans le rapport gpresult et dans le journal opérationnel GroupPolicy.

Faut-il gérer les appareils avec la GPO ou avec Intune ?

La règle de base est de s'aligner sur le fondement d'identité de l'appareil. Si les appareils sont surtout joints à un domaine AD local et connectés en permanence au réseau interne, la GPO reste l'option la plus fiable et la plus fine. Si les appareils joints à Microsoft Entra, ou les postes en télétravail qui ne se connectent jamais à un contrôleur de domaine, se multiplient, Intune (MDM/CSP), qui livre la configuration aussi hors de l'entreprise, convient mieux. Dans un environnement hybride où les deux coexistent, configurer le même paramètre à la fois par GPO et par MDM crée un conflit dont le résultat n'est pas garanti : le principe est de décider, domaine de paramètre par domaine de paramètre, lequel des deux gère, et de s'y tenir. Lorsque vous envisagez une migration, importer les GPO existantes dans Group Policy analytics d'Intune permet de trier les paramètres déjà pris en charge par le MDM de ceux qui ne le sont pas ou qui sont déconseillés.

Un paramètre que j'ai configuré dans l'Éditeur de stratégie de groupe locale (gpedit.msc) est écrasé par le paramètre de domaine. Est-ce voulu ?

Oui, c'est voulu. La stratégie de groupe est traitée dans l'ordre local, site, domaine, OU (LSDOU), et c'est la GPO traitée en dernier qui l'emporte en cas de conflit, ce qui fait de la GPO locale la couche la plus faible. Si une GPO de domaine configure le même paramètre, la modification locale est toujours écrasée. À l'inverse, si le domaine a laissé ce paramètre Non configuré, la valeur de la GPO locale reste telle quelle. Même si, pour un test, vous voulez absolument faire primer le paramètre local, il n'existe aucun moyen d'inverser cet ordre de priorité sur un PC joint à un domaine : les approches réalistes sont de créer une OU de test et d'y ajuster la GPO côté domaine, ou d'utiliser une machine de test non jointe au domaine.

L'application métier que nous avons développée échoue seulement chez le client. Existe-t-il un moyen de vérifier si la GPO en est la cause ?

La première étape consiste à demander à l'administrateur du client d'exécuter gpresult /h report.html depuis une invite de commandes avec élévation sur le PC concerné, puis de consulter le rapport RSoP. Cherchez les paramètres qui changent le comportement de l'application : scripts bloqués par la stratégie d'exécution, fusion des règles locales du pare-feu désactivée, ou configuration du proxy et des lecteurs réseau. Il est aussi utile de vérifier si des valeurs de stratégie du produit concerné sont écrites sous HKLM\Software\Policies et HKCU\Software\Policies dans le registre, ce qui fait apparaître mécaniquement les paramètres imposés issus des modèles d'administration. Côté développement, la préparation possible consiste à documenter dans le guide de déploiement les hypothèses dont dépend l'application, comme la stratégie d'exécution, les ports d'écoute et les dossiers d'écriture, et à demander au service informatique du client de les confirmer avant le déploiement.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.