Vous déployez des lecteurs réseau sur cent postes, et pourtant la moitié des utilisateurs ne les voient pas au démarrage. Ce scénario, tout administrateur Active Directory l’a vécu. Le mappage de lecteur réseau par GPO est une technique fiable – à condition de comprendre exactement ce qui se passe sous le capot, depuis la configuration initiale jusqu’aux pièges les moins documentés.
GPO et mappage de lecteur réseau : comprendre les bases avant de configurer
Les Group Policy Objects (GPO) existent depuis Windows 2000, mais la possibilité de mapper des lecteurs réseau nativement via des préférences de stratégie de groupe est arrivée plus tard. Les Group Policy Preferences (GPP) étaient à l’origine un produit tiers baptisé PolicyMaker, que Microsoft a racheté puis intégré directement dans Windows Server 2008. Ce rachat a changé la donne pour les administrateurs système.
Avant cette intégration, mapper un lecteur réseau à l’ouverture de session impliquait obligatoirement un script de logon. Cette approche fonctionnait, mais elle introduisait de la complexité : maintenance des scripts, gestion des erreurs, lisibilité réduite pour les équipes qui reprenaient l’infrastructure.
Avec les GPP, tout se gère depuis la console GPMC, sans une seule ligne de code. Les Client Side Extensions (CSE), qui exécutent ces préférences côté poste client, sont intégrées nativement dans Windows 7, Windows Server 2008 et au-delà. Pour Windows XP, Server 2003 et Vista, une installation manuelle des CSE restait nécessaire – un détail qui compte encore dans les environnements mixtes anciens.
Comment configurer un mappage de lecteur réseau via une GPO?
Le chemin de configuration dans la console GPMC est le suivant : Configuration utilisateur > Préférences > Paramètres Windows > Mappages de lecteurs. Vous faites un clic droit dans le volet de droite, puis « Nouveau » pour créer une entrée.
Quatre actions sont disponibles dans la liste déroulante « Action » :
- Créer : crée le lecteur s’il n’existe pas encore sur le poste.
- Supprimer : retire un lecteur mappé existant.
- Remplacer : supprime le lecteur existant puis le recrée entièrement – utile pour forcer une mise à jour propre du chemin UNC.
- Mettre à jour : modifie uniquement les paramètres définis dans la GPO ; si le lecteur n’existe pas, il le crée.
L’option Reconnecter, accessible dans le même formulaire, rend le lecteur persistant : il sera remonté à chaque ouverture de session, même si la connexion a été interrompue entre-temps. Une même GPO peut contenir plusieurs mappages de lecteurs différents, avec des lettres et des chemins UNC distincts.
Comment utiliser la variable %username% pour personnaliser les lecteurs mappés?
Plutôt que de mapper le même répertoire partagé pour tous les utilisateurs, vous pouvez personnaliser le chemin UNC avec la variable %username%. Dans le champ « Chemin », saisissez par exemple \\serveur\profils$\%username% : chaque utilisateur se verra monter son propre dossier personnel, sans configuration individuelle.
Windows résout la variable au moment de l’application de la GPO, en la remplaçant par le nom de compte de l’utilisateur connecté. Les droits NTFS sur les sous-dossiers sont gérés automatiquement si le partage est configuré en conséquence, ce qui évite les erreurs d’accès croisé entre comptes.
L’équivalent en script batch utilise la même logique. La syntaxe est :
Net use P: \\nomduserveur\profils$\%username%
Cette commande fonctionne dans un script de logon et produit le même résultat qu’une préférence de groupe Windows appliquée en contexte utilisateur. La GPP reste préférable pour la lisibilité et la traçabilité dans des environnements managés.
Pourquoi une GPO de mappage lecteur ne s’applique pas ou reste grisée?
Depuis juin 2016, Microsoft a modifié le comportement d’application des GPO pour des raisons de sécurité : même une GPO configurée dans le contexte utilisateur s’exécute désormais dans le contexte de sécurité « computer ». Cette décision, documentée dans les bulletins de support Microsoft, est directement responsable du problème de l’option « Se connecter en tant que » grisée dans les propriétés de mappage de lecteur.
Concrètement, le compte machine tente de lire la GPO, mais n’a pas forcément les permissions de lecture sur l’objet. Le lecteur ne se monte pas, sans message d’erreur explicite pour l’utilisateur final.
Deux autres causes fréquentes méritent votre attention :
- Lettre de lecteur déjà occupée : si la lettre choisie (par exemple D:) est déjà attribuée à un lecteur local ou optique, Windows ignore silencieusement le mappage GPO.
- Conflit UAC : quand le Contrôle de compte d’utilisateur est actif, Windows maintient deux sessions parallèles – une en droits standard, une en mode élevé. Un lecteur mappé dans la session standard n’est pas visible dans une fenêtre ouverte avec élévation, et inversement.
Le délai de réplication entre contrôleurs de domaine est une source d’erreur moins évidente. Une GPO créée sur un DC peut prendre jusqu’à plusieurs dizaines de minutes pour se propager aux autres DC. Si l’utilisateur se connecte sur un poste qui interroge un DC non encore synchronisé, la stratégie ne s’applique tout simplement pas.
Les solutions officielles quand le mappage de lecteur GPO ne fonctionne pas
La correction documentée par Microsoft pour le problème de contexte de sécurité « computer » est précise : dans l’onglet « Délégation » de la GPO (via la console GPMC), ajoutez le groupe Authenticated Users avec la permission de lecture. Ce groupe couvre tous les utilisateurs et ordinateurs authentifiés du domaine.
Si vous utilisez un filtrage de sécurité restrictif – c’est-à-dire si vous avez retiré Authenticated Users pour ne cibler que des groupes spécifiques – vous devez ajouter Domain Computers avec permission de lecture séparément. Sans cela, le contexte machine ne peut pas lire la GPO et le mappage échoue.
Pour forcer l’application immédiate sans attendre le cycle automatique, exécutez gpupdate /force sur le poste concerné. Pour diagnostiquer quelles GPO s’appliquent réellement, la commande gpresult /h appliedgpo.htm génère un rapport HTML lisible qui liste chaque stratégie appliquée ou filtrée, avec les raisons d’exclusion.
Rappelons que le cycle de rafraîchissement par défaut des stratégies de groupe est de 90 minutes, auquel s’ajoute un décalage aléatoire pouvant aller jusqu’à 30 minutes – soit un délai maximum de 120 minutes avant application automatique sur un poste actif.
Script pour mapper un lecteur réseau : quand faut-il préférer cette alternative à la GPO?
Les GPP couvrent la grande majorité des besoins de mappage en entreprise. Pourtant, deux situations justifient encore de revenir à un script de logon (.bat ou PowerShell).
La première : les postes qui tournent sous des systèmes anciens sans CSE natif, ou les environnements hétérogènes où des machines hors domaine doivent aussi accéder aux partages. La deuxième : la logique conditionnelle complexe – mapper un lecteur différent selon l’heure, le site réseau détecté, ou le résultat d’un test de connectivité préalable. Ce type de branchement conditionnel est difficile à exprimer proprement avec les filtres d’éléments GPP, alors qu’un script PowerShell le gère en quelques lignes.
La syntaxe PowerShell pour un mappage conditionnel ressemble à :
New-PSDrive -Name "Z" -PSProvider FileSystem -Root "\\serveur\partage" -Persist
Le paramètre -Persist assure la persistance entre les sessions, à l’image de l’option « Reconnecter » dans les GPP. Pour un script batch classique, Net use Z: \\serveur\partage /persistent:yes produit le même effet.
Les bonnes pratiques pour un déploiement GPO de lecteurs réseau fiable en entreprise
Un déploiement GPO qui tient dans la durée repose d’abord sur un nommage cohérent des objets. Préfixer chaque GPO avec sa fonction et sa cible – par exemple GPO_MAPPAGE_LECTEURS_COMPTA – évite les confusions lors des audits ou des reprises de parc.
La portée d’application doit être contrôlée via les Unités d’Organisation (OU) et les groupes de sécurité, pas via des filtres WMI sauf nécessité absolue. Un filtre WMI mal configuré peut bloquer l’application d’une GPO sans laisser de trace évidente dans les journaux.
Vérifiez systématiquement les droits NTFS sur les partages cibles avant tout déploiement. Un lecteur monté sans droit d’accès en lecture sur le partage reste inutilisable – l’utilisateur voit la lettre dans l’Explorateur mais ne peut pas naviguer dedans. Cette vérification en amont évite les tickets de support inutiles.
Tenez compte du cycle de rafraîchissement dans votre planification de déploiement : avec 90 minutes de base plus jusqu’à 30 minutes de décalage aléatoire, un changement de GPO peut prendre près de deux heures à se propager sur un poste actif. Pour les déploiements urgents, gpupdate /force reste votre outil de référence. Une configuration solide des plages horaires de support permet aussi d’anticiper les créneaux où des redémarrages de postes peuvent être planifiés sans impact utilisateur.
Enfin, les options avancées de gestion Windows peuvent compléter votre outillage pour auditer l’état des lecteurs mappés sur un parc. Un administrateur qui documente ses GPO, vérifie les permissions en amont et teste sur un groupe pilote avant le déploiement général transforme un déploiement risqué en opération routinière.