Windows Server AD : instabilité après migration de contrôleur de domaine — corriger la GPO « Drive Mappings » (Replace vs Update)

Après la migration d’un DC, vos applications réseau se ferment et les lecteurs disparaissent dès que l’ancien serveur est éteint ? Ce guide explique la cause racine — une GPO « Drive Mappings » en mode Replace — et fournit une procédure pas‑à‑pas pour corriger et fiabiliser l’environnement.

Sommaire

Vue d’ensemble de la situation

Scénario typique rencontré en PME/ETI :

Ancien serveur : Windows Server Essentials, détenteur de tous les rôles FSMO.
Nouveau serveur : Windows Server Standard joint au domaine, promu en contrôleur de domaine (DC), rôles FSMO transférés, DNS/DHCP configurés.
Partages et lecteurs réseau recréés sur le nouveau serveur. Les postes reçoivent leurs lecteurs via une GPO Preferences > Windows Settings > Drive Maps.
Tant que l’ancien serveur reste allumé, tout fonctionne. Dès qu’on l’éteint ou qu’on le rétrograde, des applications réseau se ferment inopinément, les lecteurs se déconnectent, et l’utilisateur perd l’accès aux fichiers.
Après vérifications (DNS/AD/DHCP/NetBIOS, zones inverses, ping/nslookup, journaux), le problème persiste.

Symptômes observés

Fenêtres d’applications métier qui se ferment « toutes seules » ou deviennent Not Responding lorsque l’ancien DC est éteint.
Lecteurs mappés (X:, P:, S:…) qui basculent en état déconnecté de façon sporadique, puis reviennent quelques minutes plus tard.
Événements récurrents dans Application and Services Logs > Microsoft > Windows > GroupPolicy ou GroupPolicy/Operational, indiquant l’échec de traitement de préférences.
Sur certains postes : réouverture de session obligatoire pour récupérer les lecteurs, ou nécessité d’un gpupdate /force.

Ce que fait réellement « Drive Mappings »

Les lecteurs réseau distribués par GPO utilisent Group Policy Preferences (GPP), qui exposent quatre actions : Create, Replace, Update et Delete. La sémantique précise est fondamentale lors d’une migration.

Action	Comportement à l’application de la GPO	Risque en production	Cas d’usage recommandé
Create	Crée le lecteur s’il n’existe pas. N’altère pas un mappage déjà présent avec le même lecteur.	Faible	Premier déploiement d’un lecteur sans écraser les personnalisations locales.
Update	Met à jour le lecteur si existant (chemin UNC, étiquette, options), sinon le crée. Ne supprime pas le lecteur avant mise à jour.	Faible	Recommandé en migration : permet de corriger le chemin (\nouveau‑serveur\partage) sans casser les sessions.
Replace	Supprime le lecteur, puis le recrée à chaque actualisation de GPO, même si rien n’a changé.	Élevé	À éviter en production continue ; utile uniquement pour réinitialiser massivement des lecteurs à un instant T.
Delete	Supprime le lecteur lorsqu’il est ciblé par la préférence.	Moyen	Nettoyage programmé d’anciens mappages devenus obsolètes.

Pourquoi « Replace » casse tout après la migration

Vos mappages GPP ont été initialement créés avec des chemins UNC de type \\ANCIEN-SRV\Partage.
Vous avez basculé les données vers \\NOUVEAU-SRV\Partage, mais la GPO conserve l’action Replace et/ou des items pointant encore vers l’ancien UNC.
Quand l’ancien serveur est hors ligne, au prochain rafraîchissement de la stratégie (logon, gpupdate, intervalle planifié), GPP tente de supprimer puis recréer les lecteurs. La suppression coupe brutalement les handles fichiers ouverts par les applications.
La recréation échoue (le chemin n’est plus joignable), laissant les lecteurs inexistants ou orphelins ; les logiciels perdent l’accès au stockage et s’arrêtent.

Fréquence d’actualisation des GPO : comprendre le « timing » des pannes

GPO ordinateur : toutes les ~90 minutes (+ aléa), au démarrage, et sur événements réseau.
GPO utilisateur : à chaque ouverture de session, puis ~90 minutes (+ aléa).
Un gpupdate /force relance immédiatement le traitement. C’est souvent à ce moment que les lecteurs « sautent » si l’action est Replace.

La solution éprouvée

Corriger la GPO de mappage de lecteurs : passer l’action de chaque item de Replace à Update (ou Create) et s’assurer que tous les chemins UNC pointent vers le nouveau serveur.

Procédure pas‑à‑pas dans GPMC

Ouvrez Group Policy Management (gpmc.msc) depuis un poste d’admin ou le nouveau DC.
Localisez la GPO qui distribue vos lecteurs (ex : « Drive Mappings – Utilisateurs »).
Éditez la GPO : User Configuration > Preferences > Windows Settings > Drive Maps.
Pour chaque lecteur :
- Double‑cliquez l’item, changez Action : sélectionnez Update.
- Modifiez le Location (UNC) vers \\NOUVEAU-SRV\Partage.
- Cochez Reconnect (persister le lecteur) si souhaité.
- Vérifiez l’onglet Common : ne cochez pas « Remove this item when it is no longer applied » sauf besoin explicite.
- Contrôlez l’Item‑level targeting : supprimez toute cible basée sur l’ancien serveur (nom NetBIOS, OU, groupe…), ou ajustez‑la.
Supprimez les items obsolètes pointant vers \\ANCIEN-SRV\....
Appliquez et fermez.

Validation immédiate sur un poste pilote

Exécutez gpupdate /target:user /force (voire /target:computer si des mappages sont côté ordinateur).
Fermez / rouvrez la session utilisateur.
Contrôlez l’état : net use Get-PSDrive -PSProvider FileSystem
Vérifiez que les lecteurs pointent vers \\NOUVEAU-SRV\... et restent stables.
Testez l’arrêt de l’ancien serveur en environnement de recette : aucune coupure ne doit survenir.

Check‑list de migration DC/fichiers

Étape	Bonne pratique lors d’une migration DC/fichiers
DNS	S’assurer que les nouveaux contrôleurs sont les seuls serveurs DNS dans les cartes réseau ; nettoyer les enregistrements NS et SRV relatifs à l’ancien DC.
DHCP	Mettre à jour l’option 006 (DNS Servers) et l’option 015 (DNS Suffix) ; envisager un failover DHCP pour la haute dispo.
GPO	1) Rechercher les mappages et scripts référencés à `\\ANCIEN-SRV\` ; 2) préférer Update pour les lecteurs existants ; 3) documenter et supprimer les GPO obsolètes.
Partages	Conserver le même nom de partage qu’avant pour éviter les liens codés en dur ; sinon, prévoir une redirection DFS ou un alias CNAME correctement préparé.
Nettoyage	Après 15–30 jours, exécuter `dnscmd /AgeAllRecords` ou activer le scavenging automatique pour purger les enregistrements fantômes.
Validation	Utiliser `dcdiag /v`, `repadmin /replsummary`, puis un test de déconnexion de l’ancien serveur hors production pour vérifier qu’aucune dépendance ne subsiste.

Outils de diagnostic utiles

Résultat de stratégie : gpresult /h c:\temp\gp.html puis ouvrir le rapport pour confirmer l’application des Drive Maps.
RSOP : rsop.msc ou l’assistant « Group Policy Results » dans GPMC sur un poste impacté.
Journaux : Observateur d’événements > Journaux des applications et services > Microsoft > Windows > GroupPolicy (et GroupPolicy/Operational), ainsi que Folder Redirection si utilisé.
Réseau : nslookup -type=SRV _ldap._tcp.dc._msdcs.<domaine> nltest /dsgetdc:<domaine> ipconfig /all
Contrôle des partages côté serveur : Get-SmbShare Get-SmbOpenFile Get-SmbSession

Audit express des références à l’ancien serveur

Avant d’éteindre définitivement l’ancien hôte, traquez toutes les références \\ANCIEN-SRV\ dans vos GPO (Drives, Shortcuts, Printers, scripts). Voici un script PowerShell d’audit rapide du SYSVOL :

# Remplacez DOMAINE.LOCAL et ANCIEN-SRV selon votre environnement
$domain = "DOMAINE.LOCAL"
$old    = "\\ANCIEN-SRV\"
$pol    = "\\$domain\SYSVOL\$domain\Policies"

Get-ChildItem -Path $pol -Recurse -Include *.xml,*.ini,*.vbs,*.cmd,*.ps1 |
Select-String -SimpleMatch -Pattern $old |
Select-Object Path, LineNumber, Line |
Sort-Object Path, LineNumber

Vous identifierez instantanément les GPO et fichiers qui pointent encore vers l’ancien serveur.

Bonnes pratiques pour fiabiliser les chemins UNC

Privilégier un nom stable côté client

DFS Namespaces : exposez \\domaine.local\DFS\Donnees et basculez les folder targets en arrière‑plan lors des migrations. Les postes ne changent jamais de chemin.
Alias DNS + SPN CIFS : si vous préférez un alias (\\files\Donnees), créez un CNAME vers le serveur de fichiers et enregistrez l’SPN adéquat : setspn -S cifs/files.domaine.local DOMAINE\NOUVEAU-SRV$ Pour certains scénarios, un alias SMB côté serveur peut être requis selon la version de Windows ; documentez et testez avant production. DFS reste la voie la plus robuste.
Scripts & applis : bannissez les chemins codés en dur vers un nom d’hôte nominal. Préférez DFS ou un alias logique pérenne (\\files\...).

Éviter les déconnexions côté client

Évitez l’action Replace dans la durée. Utilisez Update pour corriger un chemin existant sans rupture.
Décochez les options de suppression automatique non nécessaires (onglet Common).
Sur les postes mobiles, vérifiez Offline Files si la redirection de dossiers est activée, pour éviter des conflits lors des bascules.

Plan de remédiation type

Figer la configuration actuelle : exporter vos GPO (Backup-GPO -All), lister les partages (Get-SmbShare).
Corriger les GPP : passer tous les Drive Maps en Update, uniformiser les UNC.
Nettoyer les références à \\ANCIEN-SRV (GPP, scripts, liens, imprimantes).
Valider en pré‑production : arrêt contrôlé de l’ancien serveur, sessions utilisateurs ouvertes, monitoring des journaux.
Basculer en prod : extinction définitive de l’ancien DC ou rétrogradation, surveillance des tickets.

FAQ express

Faut‑il cocher « Remove this item when it is no longer applied » ?
Non, sauf scénario précis de retrait. En migration, cette option aggrave les déconnexions.

Pourquoi mes applis se ferment ?
Parce que l’action Replace démonte le lecteur actif. Les handles ouverts deviennent invalides et l’appli lève une erreur fatale.

Je veux renommer mon serveur de fichiers. Des précautions ?
Oui : utilisez DFS ou un alias + SPN CIFS, puis migrez les cibles sans changer les chemins clients.

Étapes de contrôle détaillées

Contrôle	Commande / Action	Résultat attendu
Réplication AD saine	`repadmin /replsummary`	Erreurs 0, latence normale
Découverte DC par SRV	`nslookup -type=SRV _ldap._tcp.dc._msdcs.<domaine>`	Uniquement les nouveaux DC
Résolution DNS côté poste	`ipconfig /all`	Serveurs DNS = nouveaux DC
État des lecteurs	`net use`, `Get-PSDrive`	UNC vers `\\NOUVEAU-SRV\...`
Application GPO	`gpresult /h` ou GPMC Group Policy Results	Drive Maps appliqués en Update
Échec GPP résolu	Observateur d’événements	Plus d’erreurs Drive Maps / GPP

Scripts de contrôle complémentaires

Lister les Drive Maps actifs d’un utilisateur courant :

Get-ChildItem HKCU:\Network |
  ForEach-Object {
    $l = Get-ItemProperty -Path ("HKCU:\Network\" + $_.PSChildName)
    [PSCustomObject]@{
      Lettre = $_.PSChildName
      UNC    = $l.RemotePath
      Persiste = $l.ConnectionType
    }
  } | Sort-Object Lettre

Inventorier les partages sur le nouveau serveur :

Get-SmbShare | Where-Object {$_.Name -ne "IPC$"} |
  Select-Object Name, Path, Description, FolderEnumerationMode, ConcurrentUserLimit

Exporter un rapport HTML des GPO :

Get-GPO -All | ForEach-Object {
  $p = "C:\Temp\GPO\$($_.DisplayName).html"
  Get-GPOReport -Guid $_.Id -ReportType Html -Path $p
}

Cas réels et leçons apprises

Sur des environnements avec GPP en Replace, les pannes apparaissent de manière « aléatoire » car elles suivent le cycle de rafraîchissement GPO. Le passage à Update stabilise immédiatement les clients, sans toucher à DNS/AD.
Les suites bureautiques, ERP et outils graphiques sont particulièrement sensibles : dès que leur répertoire de travail n’est plus monté, elles se ferment pour éviter la corruption de fichiers.
La cause peut rester masquée tant que l’ancien serveur répond au nom UNC. C’est l’extinction ou la rétrogradation qui révèle la mauvaise configuration.

Conclusion

Lorsque des applications réseau deviennent instables après une migration de contrôleur de domaine, ne vous focalisez pas uniquement sur DNS/AD. Vérifiez d’abord la GPO de mappage de lecteurs : bannissez l’action Replace en exploitation, migrez vos chemins UNC via Update et standardisez côté client avec DFS ou un alias durable. En appliquant ces contrôles, la migration se clôt sans interruption des applications et demeure résiliente pour les futures évolutions.

Informations complémentaires utiles

Étape	Bonne pratique lors d’une migration DC/fichiers
DNS	S’assurer que les nouveaux contrôleurs sont les seuls serveurs DNS référencés dans les cartes réseau ; nettoyer les enregistrements NS et SRV relatifs à l’ancien DC.
DHCP	Mettre à jour l’option 006 (DNS Servers) et l’option 015 (DNS Suffix) ; envisager la failover DHCP pour la haute dispo.
GPO	1) Rechercher les mappages et scripts qui font encore référence à l’ancien nom `\\SERVER\` ; 2) préférer « Update » pour les lecteurs existants ; 3) documenter puis supprimer les GPO obsolètes.
Partages	Donner aux nouveaux partages le même nom que l’ancien pour éviter de modifier des liens codés en dur ; sinon, prévoir une redirection DFS ou un alias CNAME.
Nettoyage	Après 15–30 jours, exécuter `dnscmd /AgeAllRecords` ou activer le scavenging automatique pour purger les enregistrements fantômes.
Validation	Utiliser `dcdiag /v`, `repadmin /replsummary`, puis un test de déconnexion de l’ancien serveur hors production pour vérifier que rien n’y dépend encore.

En corrigeant la stratégie de mappage de lecteurs et en adoptant ces bonnes pratiques, vous éliminez la cause principale des déconnexions post‑migration et vous durcissez votre socle Windows Server pour les prochaines années.

Windows Server AD : instabilité après migration de contrôleur de domaine — corriger la GPO « Drive Mappings » (Replace vs Update)