C’est souvent un vrai casse-tête. L’organisation des GPO est un sujet complexe, et plus le temps passe, plus cela devient difficile dans les annuaires Active Directory qui ont plusieurs années derrière eux. On applique sur des groupes, sur des OU ? On filtre ? On imbrique ?
À travers ce guide, on va essayer de voir les bonnes pratiques : comment structurer ses unités d’organisation, nommer ses stratégies, choisir entre filtrage et liaison, et surtout comment reprendre en main un parc de GPO qui a dérivé au fil des années.
1. Rappel : comment une GPO s’applique réellement
Avant de parler d’organisation, il faut avoir en tête le mécanisme d’application. Beaucoup de mauvaises décisions de structuration viennent d’une compréhension approximative de cet ordre.
L’ordre LSDOU
Les stratégies s’appliquent dans cet ordre précis :
- Local : la stratégie locale de la machine
- Site : les GPO liées au site Active Directory
- Domaine : les GPO liées à la racine du domaine
- OU : les GPO liées aux unités d’organisation, de la plus haute à la plus profonde
La dernière stratégie appliquée gagne en cas de conflit. Autrement dit, l’OU la plus proche de l’objet a le dernier mot. C’est le principe fondateur de toute organisation saine : plus on descend dans l’arborescence, plus on est spécifique.
Quand plusieurs GPO sont liées à la même OU, elles s’appliquent de bas en haut selon l’ordre des liens. La GPO avec l’ordre de lien 1 est traitée en dernier, elle l’emporte donc sur les autres. C’est contre-intuitif, et c’est une source classique d’erreur.
Un point souvent oublié : l’emplacement de l’objet, pas du groupe
Une GPO s’applique à un objet ordinateur ou utilisateur en fonction de sa position dans l’arborescence des OU. Un utilisateur membre du groupe « Comptables » ne recevra pas la GPO liée à l’OU « Comptabilité » si son compte se trouve physiquement dans l’OU « Utilisateurs\Siège ».
C’est la réponse à la question posée en introduction : on applique sur des OU. Les groupes servent uniquement à affiner ensuite, via le filtrage de sécurité. On y revient plus loin.
La fréquence de rafraîchissement
- Postes et serveurs membres : toutes les 90 minutes, avec un décalage aléatoire de 0 à 30 minutes
- Contrôleurs de domaine : toutes les 5 minutes
- À l’ouverture de session (partie Utilisateur) et au démarrage (partie Ordinateur)
Certains paramètres ne s’appliquent qu’au démarrage ou à l’ouverture de session : installation de logiciels, scripts de démarrage, redirection de dossiers. Un gpupdate /force ne suffit pas toujours, il faut redémarrer ou se reconnecter.
2. Structurer ses OU pour les GPO
C’est le point de départ. Une arborescence d’OU mal pensée rend impossible toute organisation propre des stratégies, et aucun filtrage ne rattrapera cela.
Séparer machines et utilisateurs dès le premier niveau
La règle de base : les objets ordinateurs et les objets utilisateurs ne vivent pas dans les mêmes branches. Les paramètres qui les concernent sont différents, les cycles de vie aussi, et les équipes qui les gèrent également dans beaucoup d’organisations.
Structurer par fonction, pas par organigramme
L’erreur la plus fréquente consiste à calquer l’arborescence d’OU sur l’organigramme de l’entreprise. C’est tentant, c’est lisible pour la direction, et c’est ingérable au bout de deux réorganisations.
Structurez selon ce qui détermine réellement les paramètres à appliquer : le type de machine, le rôle, le niveau de sécurité requis. Une réorganisation de service ne doit pas provoquer une refonte de vos GPO.
Exemple d’arborescence
contoso.local
│
├── _CONTOSO ← racine métier, tout le reste est natif
│ │
│ ├── Ordinateurs
│ │ ├── Postes
│ │ │ ├── Fixes
│ │ │ ├── Portables ← BitLocker, VPN, cache hors connexion
│ │ │ └── Kiosques ← loopback en mode Replace
│ │ └── Serveurs
│ │ ├── Membres
│ │ ├── RDS ← loopback en mode Merge
│ │ └── Applicatifs
│ │
│ ├── Utilisateurs
│ │ ├── Standard
│ │ ├── Prestataires
│ │ └── Administration
│ │ ├── Tier0 ← admins du domaine
│ │ ├── Tier1 ← admins serveurs
│ │ └── Tier2 ← support poste de travail
│ │
│ ├── Groupes
│ ├── Comptes-Services
│ └── Quarantaine ← héritage bloqué, objets en attente de tri
│
└── Domain Controllers ← ne pas déplacer, ne pas renommer
Quelques principes visibles dans cet exemple :
- Une racine métier unique (
_CONTOSO) permet de lier une GPO de base qui touche tout le parc administré sans toucher aux conteneurs système. L’underscore la fait remonter en tête de liste dans la console. - Une OU Quarantaine avec héritage bloqué sert de zone tampon pour les objets nouvellement créés ou dont on n’est pas sûr. Mieux vaut un poste sans stratégie qu’un poste avec les mauvaises.
- Les comptes d’administration sont isolés par niveau de privilège, ce qui permet d’appliquer des restrictions d’ouverture de session différenciées (modèle en tiers).
Ne jamais laisser d’objets dans les conteneurs par défaut
Les conteneurs CN=Users et CN=Computers ne sont pas des OU. On ne peut donc pas y lier de GPO. Tout objet qui y reste ne reçoit que les stratégies du domaine.
Redirigez les créations par défaut :
redircmp "OU=Quarantaine,OU=_CONTOSO,DC=contoso,DC=local"
redirusr "OU=Quarantaine,OU=_CONTOSO,DC=contoso,DC=local"
3. Nommer ses GPO : la convention qui sauve
Sur un annuaire de cinq ans, on trouve fréquemment des GPO nommées Test, Test2, Nouvelle GPO, Copie de Politique Bureau, GPO Jean-Michel. Personne n’ose les supprimer parce que personne ne sait ce qu’elles font.
Structure de nommage proposée
[Portée]-[Cible]-[Fonction]
Portée : préfixe indiquant quelle partie de la GPO est active.
| Préfixe | Signification |
|---|---|
C |
Paramètres Ordinateur uniquement |
U |
Paramètres Utilisateur uniquement |
CU |
Les deux parties sont actives |
Cible : à quoi s’adresse la stratégie (ALL, SRV, PC, RDS, ADM, KIOSK).
Fonction : ce que fait la GPO, en clair et sans ambiguïté.
Exemples concrets
C-ALL-Baseline-Securite
C-PC-Chiffrement-BitLocker
C-SRV-Pare-feu-Regles-Metier
C-RDS-Restrictions-Session
U-ALL-Redirection-Dossiers
U-ADM-Interdiction-Navigation-Internet
CU-KIOSK-Verrouillage-Complet
Le bénéfice est immédiat : dans la console GPMC, un tri alphabétique regroupe naturellement les stratégies par portée puis par cible. En lisant le nom seul, on sait où elle est censée être liée et ce qu’elle fait.
Documenter dans la GPO elle-même
L’onglet Commentaire des propriétés de la GPO existe et reste dramatiquement sous-utilisé. Renseignez-y systématiquement :
- La date de création et l’auteur
- Le ticket ou la demande à l’origine
- Ce que fait la stratégie, en deux lignes
- Les dépendances éventuelles avec d’autres GPO
Il est également possible de commenter chaque paramètre individuellement dans l’éditeur, ainsi que chaque élément de préférence. Quand un successeur reprendra votre annuaire, il vous en sera reconnaissant.
4. Granularité : une GPO, un objectif
Le piège de la GPO monolithique
La tentation est forte de tout mettre dans une seule stratégie « Politique Entreprise » : sécurité, mappages de lecteurs, imprimantes, fond d’écran, paramètres navigateur. Au début, c’est pratique. Deux ans plus tard, plus personne n’ose la modifier parce qu’un changement peut casser n’importe quoi.
Le piège inverse
À l’autre extrême, créer une GPO par paramètre produit un annuaire avec 200 stratégies liées, un temps d’ouverture de session dégradé et un diagnostic impossible.
Le bon équilibre
Regroupez par domaine fonctionnel cohérent : une GPO de baseline sécurité, une GPO de mappages réseau, une GPO de configuration navigateur, une GPO de déploiement d’imprimantes. Le critère pratique : une GPO doit pouvoir être désactivée ou supprimée sans effet de bord sur un autre sujet.
Si vous vous demandez « est-ce que couper cette GPO va casser autre chose », c’est qu’elle en fait trop.
Désactiver la moitié inutilisée
Si une GPO ne contient que des paramètres Ordinateur, désactivez explicitement la partie Utilisateur dans les propriétés de la stratégie. Le client cesse alors d’évaluer une section vide à chaque traitement. Sur un parc important et avec de nombreuses GPO, le gain sur le temps d’ouverture de session devient mesurable.
# Recenser les GPO dont une partie est vide mais non désactivée
Get-GPO -All | ForEach-Object {
$report = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
[PSCustomObject]@{
Nom = $_.DisplayName
StatutGPO = $_.GpoStatus
VersionUserAD = $_.User.DSVersion
VersionComputerAD= $_.Computer.DSVersion
}
} | Where-Object {
($_.VersionUserAD -eq 0 -and $_.StatutGPO -notmatch 'UserSettingsDisabled') -or
($_.VersionComputerAD -eq 0 -and $_.StatutGPO -notmatch 'ComputerSettingsDisabled')
} | Format-Table -AutoSize
5. OU, filtrage de sécurité, WMI : quand utiliser quoi
Voilà le cœur de la question posée en introduction. Les trois mécanismes ne sont pas interchangeables, et leur coût n’est pas le même.
Règle n°1 : l’OU d’abord
Liez la GPO à l’OU la plus précise possible. C’est le mécanisme le plus lisible, le plus performant et le plus facile à diagnostiquer. Si la structure d’OU est bonne, 80 % des besoins sont couverts sans aucun filtrage.
Règle n°2 : le filtrage de sécurité pour les exceptions
Le filtrage de sécurité (onglet Étendue de la GPO) est adapté quand le périmètre ne correspond pas à une OU : une population transverse, un déploiement progressif, un pilote.
Utilisez toujours un groupe de sécurité, jamais un compte individuel. Nommez ce groupe de façon explicite, par exemple GPO_C-PC-Chiffrement-BitLocker, pour que le lien entre le groupe et la stratégie soit évident.
Le piège MS16-072. Depuis le correctif de sécurité MS16-072 (juin 2016), les GPO utilisateur sont récupérées dans le contexte de sécurité de l’ordinateur, et non plus de l’utilisateur. Si vous retirez Utilisateurs authentifiés du filtrage de sécurité, la stratégie cesse de s’appliquer, même si le groupe ciblé est correct.
La solution : conservez votre groupe dans le filtrage de sécurité, puis ajoutez dans l’onglet Délégation → Avancé le groupe Utilisateurs du domaine ou Ordinateurs du domaine avec la permission Lecture seule, sans la case « Appliquer la stratégie de groupe ».
C’est la cause n°1 des GPO qui « ne s’appliquent plus sans raison » dans les annuaires qui ont traversé cette période.
Règle n°3 : le filtrage WMI en dernier recours
Un filtre WMI est évalué à chaque traitement des stratégies, sur chaque poste. Une requête mal écrite ou portant sur une classe lente (Win32_Product est l’exemple canonique, elle déclenche une revalidation MSI) peut ajouter plusieurs dizaines de secondes à l’ouverture de session.
Réservez le WMI aux cas que rien d’autre ne couvre : distinction par version d’OS, par type de châssis, par espace disque disponible. Et testez toujours la requête avec Get-CimInstance avant de la mettre en production.
# Vérifier le coût d'une requête WMI avant de la déployer
Measure-Command {
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.%'"
}
Règle n°4 : le ciblage au niveau de l’élément pour les préférences
Pour tout ce qui relève des Préférences de stratégie de groupe (mappages de lecteurs, imprimantes, raccourcis, variables d’environnement, clés de registre), n’utilisez ni filtrage de sécurité ni WMI : utilisez le ciblage au niveau de l’élément.
Il permet de conditionner chaque élément individuellement selon l’appartenance à un groupe, le site AD, la plage IP, le système d’exploitation, la présence d’un fichier, et de combiner ces conditions avec des opérateurs logiques. Une seule GPO de mappages réseau peut ainsi couvrir tous les services de l’entreprise.
C’est le mécanisme le plus souple, le moins coûteux, et le plus sous-utilisé des quatre.
6. Héritage : bloquer ou forcer, mais rarement
Deux mécanismes permettent de casser le flux normal LSDOU. Les deux sont utiles, les deux sont dangereux quand ils deviennent une habitude.
Bloquer l’héritage
Appliqué sur une OU, il empêche toutes les stratégies des niveaux supérieurs de descendre. Utile pour une OU de quarantaine ou un environnement de test totalement isolé.
Le risque : les stratégies de sécurité du domaine ne s’appliquent plus non plus. Une OU avec héritage bloqué devient un angle mort de votre politique de sécurité. Documentez chaque blocage et justifiez-le.
Forcer un lien (Enforced)
Un lien forcé remonte en priorité et ne peut plus être écrasé par les niveaux inférieurs, ni bloqué par un blocage d’héritage. Réservez cet usage aux stratégies de sécurité non négociables, liées haut dans l’arborescence.
L’anti-pattern classique : forcer un lien pour résoudre un conflit qu’on n’arrive pas à diagnostiquer. Cela fonctionne sur le moment, et cela rend l’annuaire progressivement incompréhensible. Si vous avez plus de trois liens forcés, c’est probablement que la structure d’OU est à revoir.
Le cas particulier du mode bouclage (loopback)
Le traitement par bouclage applique les paramètres Utilisateur d’une GPO liée à l’OU de l’ordinateur, quel que soit l’emplacement du compte utilisateur. C’est indispensable sur les serveurs RDS, les kiosques, les postes partagés.
Deux modes :
- Fusion (Merge) : les paramètres utilisateur normaux s’appliquent, puis ceux de l’OU machine par-dessus. Ces derniers gagnent. À utiliser sur RDS pour garder les redirections de dossiers de l’utilisateur tout en ajoutant des restrictions de session.
- Remplacement (Replace) : seuls les paramètres de l’OU machine s’appliquent. À utiliser sur les kiosques ou les postes en libre-service, où le profil utilisateur habituel n’a aucun sens.
Le bouclage est un multiplicateur de complexité au diagnostic. Isolez toujours les machines concernées dans une OU dédiée, et indiquez-le dans le nom de la GPO.
7. Cycle de vie, hygiène et outillage
Le Central Store ADMX
Sans magasin central, chaque poste utilise ses propres modèles d’administration locaux, et l’affichage des paramètres dépend de la machine depuis laquelle vous ouvrez la console. Résultat : des paramètres qui n’apparaissent pas, ou pire, des paramètres orphelins.
# Création du magasin central
$store = "\\contoso.local\SYSVOL\contoso.local\Policies\PolicyDefinitions"
New-Item -Path $store -ItemType Directory -Force
Copy-Item "C:\Windows\PolicyDefinitions\*" -Destination $store -Recurse -Force
Mettez-le à jour à chaque nouvelle version majeure de Windows, et avant tout déploiement d’une nouvelle version d’Edge ou d’Office.
Tester avant de déployer
La séquence recommandée pour toute nouvelle GPO :
- Créer la GPO sans la lier
- La lier à une OU de test contenant deux ou trois machines
- Valider avec
gpresult /h rapport.htmlsur un poste cible - Utiliser la Modélisation de stratégie de groupe pour simuler l’effet sur d’autres OU
- Déployer par vagues via filtrage de sécurité sur un groupe pilote
- Élargir progressivement, puis retirer le filtrage une fois stabilisé
Sauvegarder systématiquement
Il n’existe pas de « Ctrl+Z » dans l’éditeur de stratégie de groupe. Une sauvegarde avant modification est la seule protection.
# Sauvegarde complète de toutes les GPO du domaine
$date = Get-Date -Format "yyyy-MM-dd"
$chemin = "\\srv-backup\GPO\$date"
New-Item -Path $chemin -ItemType Directory -Force
Backup-GPO -All -Path $chemin -Comment "Sauvegarde planifiee $date"
Planifiez cette commande en tâche quotidienne. Le coût est nul, le bénéfice le jour d’une erreur est considérable.
Faire le ménage
Deux catégories de déchets s’accumulent silencieusement.
Les GPO non liées : elles ne s’appliquent nulle part mais restent dans SYSVOL et polluent la console.
# Lister les GPO qui ne sont liées à aucun conteneur
Get-GPO -All | Where-Object {
$xml = [xml](Get-GPOReport -Guid $_.Id -ReportType Xml)
-not $xml.GPO.LinksTo
} | Select-Object DisplayName, CreationTime, ModificationTime
Les GPO vides : créées puis abandonnées, elles sont tout de même traitées par le client.
# Lister les GPO sans aucun paramètre configuré
Get-GPO -All | Where-Object {
$_.User.DSVersion -eq 0 -and $_.Computer.DSVersion -eq 0
} | Select-Object DisplayName, CreationTime
Avant toute suppression : sauvegardez, désactivez le lien pendant deux à quatre semaines, observez, puis supprimez. La désactivation du lien est réversible instantanément, la suppression ne l’est pas.
Déléguer proprement
Évitez de donner « Administrateurs du domaine » à toute personne devant modifier une GPO. La console GPMC permet une délégation fine : droit de créer des GPO, droit de modifier une GPO précise, droit de lier des GPO à une OU donnée. Un technicien support peut ainsi gérer les stratégies des postes sans toucher à celles des serveurs.
Récapitulatif : les dix règles à retenir
- On cible par OU, on affine par filtrage de sécurité, on conditionne les préférences par ciblage au niveau de l’élément.
- Structurez les OU par fonction technique, jamais par organigramme.
- Séparez machines et utilisateurs dès le premier niveau de l’arborescence.
- Adoptez une convention de nommage stricte et appliquez-la rétroactivement.
- Une GPO, un objectif fonctionnel : ni monolithe, ni poussière.
- Désactivez la moitié inutilisée de chaque GPO.
- Limitez WMI aux cas que rien d’autre ne couvre.
- Bloquer et forcer l’héritage sont des exceptions, pas des outils du quotidien.
- Sauvegardez avant chaque modification, testez sur une OU dédiée.
- Commentez chaque GPO : la personne qui reprendra l’annuaire dans trois ans, ce sera peut-être vous.
Par où commencer sur un annuaire existant
Si vous héritez d’un environnement déjà dégradé, ne tentez pas une refonte d’un bloc. L’ordre suivant limite les risques :
- Sauvegarder l’intégralité des GPO, aujourd’hui
- Générer un inventaire complet : nom, liens, filtres, date de dernière modification
- Identifier et désactiver les GPO vides et non liées
- Renommer selon la convention, sans rien modifier d’autre
- Documenter dans le champ Commentaire au fur et à mesure de l’analyse
- Restructurer les OU par lots, en déplaçant les objets progressivement
- Fusionner les doublons fonctionnels une fois la structure stabilisée
Comptez plusieurs semaines pour un annuaire de taille moyenne. Mais chaque étape apporte un gain immédiat, et aucune n’exige de fenêtre de maintenance.
