GPO Windows Server 2022 non appliquées : diagnostic complet AD/SYSVOL, DNS et Kerberos

Les nouvelles GPO ne s’appliquent pas dans votre domaine Windows Server 2022 ? Voici une méthode pas‑à‑pas, axée sur la réplication AD/SYSVOL, DNS, heure/Kerberos et filtrage, pour rétablir une propagation fiable des stratégies dans un environnement local ou hybride.

Sommaire

Impossibilité d’appliquer les stratégies de groupe (GPO) dans un domaine Windows Server 2022

Vue d’ensemble du problème

Dans un domaine Active Directory basé sur Windows Server 2022 (édition d’évaluation), synchronisé avec un service cloud, les GPO nouvellement créées n’atteignent pas les utilisateurs et ordinateurs. L’administrateur suspecte la licence. Bonne nouvelle : l’édition d’évaluation n’empêche pas l’application des GPO pendant la période de grâce (jusqu’à 180 jours). Les causes réelles sont presque toujours techniques : réplication AD/SYSVOL incomplète, résolution DNS incorrecte, dérive d’horloge qui bloque Kerberos, erreurs de filtrage/liaison, ou encore appareils non joints au domaine (Azure AD Join pur) sans liaison hybride.

Réponse & solutions — checklist synthétique

Étape de vérification	Objectif	Commandes / Actions clés
Valider la réplication AD	Confirmer que tous les contrôleurs de domaine partagent la même base AD.	`repadmin /showrepl`, `repadmin /replsum`, `repadmin /showrepl * /csv`
Contrôler la réplication SYSVOL	Les GPO résident dans SYSVOL ; une réplication DFS‑R défaillante empêche leur application.	Consulter les journaux DFS Replication ; vérifier que `\\<dc>\SYSVOL` et `\\<dc>\NETLOGON` ont un contenu identique entre DC.
Tester l’accès client	Écarter les soucis de connectivité et DNS côté poste.	Depuis un client joint : ping DC, `nslookup`, accès à `\\<dc>\SYSVOL` et `\\<dc>\NETLOGON`.
Diagnostiquer côté client	Voir quelles GPO arrivent réellement et pourquoi certaines sont refusées.	`gpupdate /force`, puis `gpresult /h c:\temp\rapport.html` ou `rsop.msc`.
Vérifier l’état de l’horloge	Un décalage > 5 min coupe Kerberos et bloque les GPO.	`w32tm /query /status` sur clients et DC.
Examiner la liaison/filtrage GPO	Confirmer la liaison à l’UO/le domaine, les ACL et le statut GPO.	Console GPMC.msc (héritage, “Appliquer”, “Héritage bloqué”, filtrage de sécurité/WMI, statut utilisateur/ordinateur).
Confirmer la phase d’évaluation	Rassurer : l’édition d’évaluation n’empêche pas la création ni l’application de GPO.	Vérifier simplement que la période n’est pas expirée.

Symptômes caractéristiques à reconnaître

Événements “GroupPolicy” indiquant un échec de traitement ou des GPO “Non appliquées (Refusé)”.
Le rapport gpresult montre la GPO attendue, mais elle n’est pas “Appliquée”.
Le poste ouvre \\<dc>\SYSVOL sur un DC différent à chaque démarrage (mauvaise topologie AD Sites & Services).
Les GPO “Ordinateur” appliquées uniquement après plusieurs redémarrages (réseau pas prêt au démarrage).

Procédure détaillée

Valider la santé d’Active Directory

Un AD sain est un prérequis aux GPO. Contrôlez d’abord la réplication AD (schéma/configuration/domaine) :

dcdiag /v
repadmin /replsum
repadmin /showrepl
netdom query fsmo

Assurez-vous que tous les DC répliquent sans erreur, que les rôles FSMO sont accessibles, et que chaque sous-réseau est mappé à un site AD (Active Directory Sites and Services). Des clients rattachés à un site erroné peuvent contacter un DC distant (latence élevée) et “rater” des fenêtres de traitement GPO.

Contrôler la réplication SYSVOL via DFS‑R

Les objets de stratégie de groupe comportent deux volets :

Le GPC (Group Policy Container) dans AD : CN=Policies,CN=System,DC=...
Le GPT (Group Policy Template) dans SYSVOL : \\<domaine>\SYSVOL\<domaine>\Policies\{GUID}

Un décalage GPC/GPT ou une réplication SYSVOL en panne empêche l’application des GPO. Vérifiez :

Sur chaque DC, le dossier Policies contient les mêmes GUID et fichiers (dont gpt.ini).
La valeur Version= dans gpt.ini progresse lorsque vous modifiez la GPO.
Les journaux DFS Replication ne montrent pas d’événements d’arrêt (ex. 2213) ou de backlog important.

Commandes utiles :

dfsrdiag pollad
dfsrdiag replicationstate
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC1 /rmem:DC2

DFS‑R bloqué après un arrêt brutal (ex. événement 2213) : relancez la réplication SYSVOL sur le DC affecté :

wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,state
wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where "replicatedfoldername='SYSVOL Share'" call ResumeReplication

Incohérence GPC/GPT : si la version AD (GPC) a avancé mais pas le fichier gpt.ini, éditez la GPO (ajout/retrait d’un paramètre bénin) pour “rebump” la version. Évitez toute manipulation manuelle dans SYSVOL sans plan de restauration.

Tester la résolution DNS et l’accès réseau

Les clients doivent uniquement utiliser le DNS de votre domaine :

ipconfig /all
nslookup _ldap._tcp.dc._msdcs.&lt;domaine&gt;
nltest /dsgetsite
echo %LOGONSERVER%

Vérifiez que le profil réseau est bien identifié en “Domaine”, que le pare‑feu autorise les flux AD/GPO et que les ports nécessaires sont ouverts.

Service	Ports typiques	Commentaires
LDAP / LDAPS	389 / 636	Découverte et annuaire
Kerberos	88	Authentification domaine
SMB	445	Accès `SYSVOL` et `NETLOGON`
RPC & dynamiques	135, 49152–65535	Appels de gestion et réplication
DNS	53	Résolution indispensable aux GPO

Diagnostiquer côté client

Sur un poste impacté, forcez une mise à jour et générez un rapport :

gpupdate /force
gpresult /h c:\temp\rapport.html

Analysez les sections “Stratégies d’ordinateur” et “Stratégies d’utilisateur”, les raisons de “Refusé” (filtrage sécurité/WMI, héritage bloqué, GPO désactivée), et l’onglet “Détails” qui liste les erreurs de traitement des extensions côté client (CSE). Consultez aussi le journal : Observateur d’événements > Journaux des applications et des services > Microsoft > Windows > GroupPolicy > Operational.

Heure, NTP et Kerberos

Un décalage > 5 minutes entre client et DC invalide Kerberos, donc les GPO. Vérifiez et corrigez :

w32tm /query /status
w32tm /query /source
w32tm /resync

Le DC détenteur du rôle PDC Emulator doit synchroniser l’heure auprès d’une source fiable ; les autres DC/clients prennent le PDCe comme référence.

Paramètres de liaison, héritage et filtrage

Dans GPMC, assurez-vous que la GPO est correctement liée à l’UO/le domaine contenant les objets ciblés.
Vérifiez le filtrage de sécurité : les objets doivent avoir “Lire” et “Appliquer la stratégie de groupe”. Par défaut, le groupe “Authenticated Users” suffit.
Contrôlez l’héritage : “Héritage bloqué” ou “Appliquer (Enforced)” peuvent changer la hiérarchie effective.
Regardez le statut de la GPO : “Paramètres ordinateur” ou “Paramètres utilisateur” peuvent être désactivés individuellement.
Filtre WMI : testez-le. Exemple compatible Windows 10/11 pour postes client :
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.%' AND ProductType = 1

Appareils hybrides et coexistence avec le cloud

Azure AD Join pur : les GPO ne s’appliquent pas à un appareil uniquement joint à Azure AD. Les GPO exigent un join AD DS (ou hybride) et une connectivité au DC (local/VPN). Vérifiez l’état : dsregcmd /status.
Hybride + VPN : hors site, activez “Toujours attendre le réseau lors du démarrage et de l’ouverture de session” pour les CSE sensibles (installation logicielle, redirection de dossiers).
Conflits MDM/Intune : quand une même clé est pilotée par MDM et GPO, la règle peut être priorisée côté MDM. Tenez un inventaire des paramètres sensibles (CSP vs ADMX).
Azure AD Connect : la synchro d’identités avec le cloud n’influence pas la capacité d’un poste AD DS à recevoir des GPO. Ne pas confondre panne de sync et panne de GPO.

Problèmes fréquents et corrections ciblées

Réplication DFS‑R non initialisée

Sur un DC fraîchement promu, attendez la fin de l’initialisation et suivez l’avancement :

dfsrdiag pollad
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC1 /rmem:DC2

Profil réseau non identifié comme “Domaine”

Si le poste ne reconnaît pas le domaine (NLA), certaines extensions échouent. Vérifiez les services “Network Location Awareness” et la présence des enregistrements SRV dans DNS.

GPO “ordinateur” appliquées en retard

Activez le traitement synchrone au démarrage :

Configuration ordinateur &gt; Modèles d'administration &gt; Système &gt; Stratégie de groupe
  &gt; Toujours attendre le réseau lors du démarrage et de l’ouverture de session = Activé

Filtre WMI obsolète

Beaucoup de filtres écrits pour Windows 7/8/10 échouent sur Windows 11. Préférez des tests sur la Version (10.x pour Win10/11) et ProductType plutôt que des numéros majeurs rigides.

Token Kerberos trop volumineux

Une appartenance à un trop grand nombre de groupes peut gonfler le jeton Kerberos (PAC) et briser l’authentification : rationalisez les groupes, réduisez les emboîtements, évitez les groupes dominants inutiles. En dernier recours, ajustez MaxTokenSize avec prudence et test.

Magasin central ADMX incohérent

Des modèles ADMX/ADML incohérents peuvent générer des avertissements. Cela n’empêche pas toujours l’application, mais standardisez le Central Store (\\<domaine>\SYSVOL\<domaine>\Policies\PolicyDefinitions) et laissez DFS‑R terminer la réplication.

Scripts et commandes PowerShell prêts à l’emploi

Exécutez ces blocs depuis un DC (PowerShell en administrateur) pour un diagnostic accéléré.

# 1) État rapide des GPO (activées/désactivées) et liaison
Import-Module GroupPolicy
Get-GPO -All | Select-Object DisplayName, GpoStatus, Id | Sort-Object DisplayName

# 2) Rapport HTML de toutes les GPO

Get-GPO -All | ForEach-Object {
$p = "C:\Temp\GPO-Reports$($*.DisplayName).html"
New-Item -ItemType Directory -Force -Path (Split-Path $p) | Out-Null
Get-GPOReport -Guid $*.Id -ReportType Html -Path $p
}

# 3) Backlog DFS-R entre deux DC (ajustez les noms)

dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC1 /rmem:DC2

# 4) Pings, DC du site, LOGONSERVER (depuis un client)

nltest /dsgetsite
echo %LOGONSERVER%

Plan de remédiation pragmatique

AD sain : dcdiag, repadmin. Corrigez toute erreur bloquante (auth, réplication, DNS).
SYSVOL conforme : comparez les dossiers Policies entre DC. Si backlog DFS‑R, attendez la convergence ou relancez la réplication (cas 2213).
Client témoin : isolez un poste de test, nettoyez son cache GPO (C:\Windows\System32\GroupPolicy — prudence), gpupdate, puis gpresult.
Filtrage & héritage : dans GPMC, vérifiez l’ACL “Appliquer” et l’héritage. Désactivez temporairement WMI/filtrages complexes pour valider la chaîne.
Heure/NTP : corrigez toute dérive, resynchronisez et redémarrez “Time Service” si nécessaire.
Hybride/MDM : confirmez le type de jointure (dsregcmd /status). Si Azure AD Join pur, basculez en hybride ou utilisez MDM pour les paramètres équivalents.

Étapes avancées et cas limites

Re‑seeding SYSVOL (situations extrêmes) : pré‑seed avec robocopy /MIR /SEC /R:0 /W:0 depuis un DC sain, après sauvegarde et fenêtre de maintenance.
Vérifier la cohérence GPC/GPT : comparez l’attribut versionNumber du GPC et la valeur Version= de gpt.ini.
Sites AD : assurez-vous que tous les préfixes IP sont associés à un Site AD approprié, pour éviter des DC “lointains”.
Extensions côté client : Installation logicielle (MSI) ne s’exécute qu’au démarrage et en mode synchrone. Scripts PowerShell : tenez compte de l’ExecutionPolicy et de la signature.

FAQ ciblée

La licence d’évaluation bloque‑t‑elle les GPO ? Non. Durant la période d’évaluation, Windows Server 2022 fonctionne pleinement pour AD/GPO. Même au‑delà (avant activation), les GPO restent techniques ; vous verrez surtout des rappels/redémarrages intempestifs, mais pas d’interdiction d’appliquer des stratégies.

Les GPO s’appliquent‑elles aux appareils Azure AD Join ? Non. Les GPO exigent un join AD DS ou un hybride. Pour Azure AD Join pur, utilisez MDM/Intune.

Un VPN est‑il requis pour les télétravailleurs ? Oui, si vous souhaitez appliquer des GPO AD classiques. Sinon, préférez des politiques MDM.

Un filtre WMI peut‑il bloquer silencieusement ? Oui. En cas de doute, retirez temporairement le filtre WMI ou mettez une clause très large pour valider le pipeline d’application.

Modèle de check‑list de clôture

Tous les DC sont Pass dans dcdiag ; repadmin /replsum sans échec.
Backlog DFS‑R nul ; Policies identiques d’un DC à l’autre.
Clients résolvent le domaine chez le DNS AD ; ports requis ouverts.
gpresult montre la GPO comme “Appliquée”.
Heure synchronisée (écart < 5 min) ; authent Kerberos OK.
Liaison GPO correcte ; filtrage sécurité et WMI conformes.
Type de jointure conforme (AD DS ou hybride) pour les postes cibles.

Annexes utiles

Commande de triage tout‑en‑un côté client

:: À exécuter en tant qu'administrateur local/domain
echo --- DC & Site ---
nltest /dsgetsite
echo LOGONSERVER=%LOGONSERVER%

echo --- DNS & SYSVOL ---
nslookup _ldap._tcp.dc._msdcs.
dir \%LOGONSERVER%\SYSVOL
dir \%LOGONSERVER%\NETLOGON

echo --- Heure & Kerberos ---
w32tm /query /status

echo --- GPO ---
gpupdate /force
gpresult /h c:\temp\rapport.html
start c:\temp\rapport.html

Vérification de l’ACL minimale d’une GPO

Dans GPMC, ouvrez l’onglet Délégation de la GPO : assurez-vous que “Authenticated Users” a “Lire” et “Appliquer la stratégie de groupe”. Pour cibler finement, remplacez par un groupe spécifique, mais évitez de supprimer l’autorisation “Lire” au compte Domain Computers si des paramètres “Ordinateur” existent.

Bonnes pratiques de conception GPO

Privilégiez des GPO thématiques (sécurité, UX, réseau) plutôt qu’une “grosse” GPO fourre‑tout.
Utilisez les niveaux UO pour organiser les liaisons, et réservez “Enforced” aux rares cas nécessaires.
Documentez chaque GPO : but, périmètre, filtre WMI, contacts, date de dernier changement.
Testez sur une UO “Pilote” avec quelques utilisateurs/ordinateurs représentatifs.

Conclusion

Dans la quasi‑totalité des incidents “les GPO ne s’appliquent plus”, la cause se situe dans la couche réplication SYSVOL (DFS‑R), la résolution DNS, la sync horaire/Kerberos, ou un filtrage/liaison inadapté. L’édition d’évaluation de Windows Server 2022 n’est pas en cause. En suivant la procédure ci‑dessus (du socle AD vers le poste), vous localisez rapidement la panne, réparez la chaîne GPC/GPT et rétablissez une application fiable des stratégies.

Informations complémentaires utiles

DFS‑R non initialisé : après promotion d’un DC, utilisez dfsrdiag pollad puis dfsrdiag backlog pour suivre la réplication.
Pare‑feu et ports : ouvrez RPC 135, SMB 445, LDAP 389/636, Kerberos 88, DNS 53 et la plage RPC dynamique 49152‑65535 entre DC et clients.
Niveau fonctionnel : un domaine au niveau Windows Server 2016 ou supérieur est recommandé (DFS‑R par défaut pour SYSVOL).
Permissions : les comptes cibles doivent avoir au minimum “Lire” et “Appliquer la stratégie de groupe” sur la GPO.

En appliquant cette méthode, vous obtenez un diagnostic reproductible et documenté, tout en évitant le piège classique d’incriminer la licence. Le résultat : une infrastructure GPO maîtrisée et des déploiements cohérents, en local comme en hybride.