La lettre de lecteur apparaît à l'ouverture de session, puis s'ouvre comme un dossier vide, ou avec une croix rouge et un message sur une ressource réseau indisponible. Les autorisations sont généralement correctes. Ce qui s'est passé, c'est que la commande de mappage s'est exécutée pendant la fenêtre où le client VPN existait mais où aucune route vers le serveur de fichiers n'existait, et Windows a enregistré cet échec comme l'état du lecteur. La solution est de cesser de traiter le mappage comme quelque chose qui se produit à l'ouverture de session et de le traiter comme la dernière étape d'une séquence de connexion.

Pourquoi le mappage s'exécute trop tôt

Un script d'ouverture de session démarre quand la session démarre. Un client VPN qui se connecte pendant l'ouverture de session ajoute sa propre chronologie par-dessus : le processus peut tourner, l'adaptateur virtuel peut exister, et la route vers le sous-réseau du bureau peut encore manquer. Ces trois états se ressemblent du point de vue d'un script et un seul d'entre eux fonctionne.

Certains environnements réagissent en répétant la même ligne défaillante à chaque ouverture de session, ce qui produit un utilisateur qui a appris à double-cliquer sur le lecteur et un script qui n'a jamais réussi seul.

Le lecteur lui-même aggrave les choses. Un lecteur mappé est un objet de session, et une fois que Windows l'a marqué comme indisponible, l'icône peut rester cassée longtemps après que le tunnel est sain. C'est pourquoi un remappage manuel fonctionne alors que le script semble ne rien faire. La session se souvient de l'échec, pas de l'intention derrière.

Un état connecté n'est pas un chemin

L'icône VPN de la zone de notification indique si le tunnel est monté. Elle ne dit rien sur l'existence d'une route vers un serveur précis, ni si le DNS résout ce nom vers l'adresse du tunnel, ni si le pare-feu du serveur lui-même vous accepte.

Ce sont trois défaillances distinctes au même résultat visible, et conditionner le tout à l'icône de la zone de notification les fusionne en un seul signal peu fiable.

Une vérification de disponibilité qui nomme le serveur dont vous avez réellement besoin les distingue, car elle échoue tant que le chemin précis ne fonctionne pas, et non tant qu'une interface se déclare connectée.

Conditionnez au serveur, pas au client

Choisissez un hôte accessible uniquement par le tunnel et attendez-le avant de mapper quoi que ce soit. L'extrait ci-dessous connecte une entrée VPN Windows enregistrée, sonde le serveur de fichiers, puis mappe le lecteur.

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

Le ping est une sonde de disponibilité, pas un test d'autorisations. Si l'ICMP est filtré sur votre réseau, sondez plutôt le service que vous utilisez réellement : net view \\%server% pour une vérification rapide, ou un court test TCP sur le port 445 dans PowerShell. L'un ou l'autre conditionne à l'élément qui compte.

Ajoutez un nombre limité de tentatives. Une boucle d'attente sans plafond transforme un tunnel cassé en une session qui ne termine jamais l'ouverture de session, et c'est un appel de support pire qu'une lettre de lecteur manquante.

Rendez-le réexécutable et conscient de la session

Exécutez-le dans la session de l'utilisateur lui-même. Une tâche qui s'exécute en tant que SYSTEM place le lecteur dans une session entièrement différente, et l'utilisateur connecté ne voit jamais le résultat. Vous obtenez ainsi un script qui signale un succès et un bureau sans aucun lecteur.

Vérifiez avant de mapper et ne supprimez que l'entrée obsolète. net use Z: /delete renvoie une erreur quand la lettre n'est pas utilisée, et cette erreur peut être ignorée sans risque plutôt que d'être une raison d'abandonner le reste du script. Conservez /persistent:no pour qu'une tentative échouée ne devienne pas plus tard une tentative de reconnexion permanente.

Et ne mettez pas de mot de passe dans le fichier. rasdial peut réutiliser les informations d'identification enregistrées pour l'entrée VPN, et le partage devrait s'authentifier en tant qu'utilisateur connecté. Si le partage a réellement besoin d'autres informations d'identification, enregistrez-les une fois par utilisateur avec cmdkey au lieu de les intégrer dans un fichier batch qui vit sur un partage d'ouverture de session. Quiconque peut lire ce partage peut lire le mot de passe, ce qui transforme une commodité en incident.

Réexécuter tout le script devrait être inoffensif, car c'est ce qui va se produire. Les utilisateurs se reconnectent, les portables se réveillent, et le même chemin de code s'exécute à nouveau avec un état initial différent.

Consignez assez pour prouver quelle moitié était en retard

Écrivez l'horodatage, le résultat de la vérification de disponibilité et le code de sortie du mappage dans un fichier sous le profil de l'utilisateur. Quand le prochain signalement d'un lecteur manquant arrive, ce journal répond à la seule question qui compte : le tunnel est-il arrivé en retard, ou le partage a-t-il refusé ?

Sans cela, chaque récidive est étudiée depuis zéro, et la conclusion habituelle est un changement d'autorisations qui ne corrige rien.

Testez la séquence une fois depuis un démarrage à froid et une fois depuis la veille. Le cas du réveil est celui où l'ordre se casse le plus souvent, parce que la session reprend avant le réseau et que le script voit une machine ouverte depuis des heures.

Articles similaires