De schijfletter verschijnt bij het aanmelden en opent vervolgens als een lege map, of met een rood kruis en een melding over een niet-beschikbare netwerkbron. De machtigingen zijn meestal in orde. Wat er gebeurde, is dat het koppelcommando liep in het venster waarin de VPN-client bestond maar er geen route naar de fileserver was, en Windows legde die fout vast als de status van de schijf. De oplossing is ophouden het koppelen te behandelen als iets dat bij het aanmelden gebeurt, en het te behandelen als de laatste stap van een verbindingsreeks.

Waarom het koppelen te vroeg loopt

Een aanmeldingsscript begint wanneer de sessie begint. Een VPN-client die tijdens het aanmelden verbindt, voegt zijn eigen tijdlijn erbovenop: het proces kan lopen, de virtuele adapter kan bestaan, en de route naar het kantoorsubnet kan nog ontbreken. Die drie toestanden zien er vanuit een script hetzelfde uit en slechts één ervan werkt.

Sommige omgevingen reageren door bij elke aanmelding dezelfde mislukkende regel te herhalen, wat een gebruiker oplevert die heeft geleerd twee keer op de schijf te klikken, en een script dat nooit uit zichzelf is geslaagd.

De schijf zelf maakt het erger. Een gekoppelde schijf is een sessieobject, en zodra Windows hem als niet beschikbaar heeft gemarkeerd, kan het pictogram nog lang kapot blijven nadat de tunnel gezond is. Daarom werkt handmatig opnieuw koppelen terwijl het script niets lijkt te doen. De sessie onthoudt de fout, niet de bedoeling erachter.

Een verbonden status is geen pad

Het VPN-pictogram in de systeemvak geeft aan of de tunnel omhoog staat. Het zegt niets over of er een route naar een bepaalde server bestaat, of DNS die naam naar het tunneladres vertaalt, of de firewall van de server zelf u doorlaat.

Dat zijn drie afzonderlijke fouten met hetzelfde zichtbare resultaat, en het koppelen aan het pictogram in het systeemvak smelt ze samen tot één onbetrouwbaar signaal.

Een gereedheidscontrole die de server noemt die u echt nodig hebt onderscheidt ze, omdat hij faalt tot het specifieke pad werkt, en niet tot een of andere interface zich als verbonden meldt.

Maak het afhankelijk van de server, niet van de client

Kies één host die alleen via de tunnel bereikbaar is en wacht daarop voordat u iets koppelt. Het fragment hieronder verbindt een opgeslagen Windows VPN-vermelding, peilt de fileserver en koppelt daarna de schijf.

@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

Ping is een gereedheidspeiling, geen machtigingstest. Als ICMP op uw netwerk wordt gefilterd, peil dan in plaats daarvan de dienst die u echt gebruikt: net view \\%server% voor een snelle controle, of een korte TCP-test tegen poort 445 in PowerShell. Beide maken het belangrijke ding afhankelijk.

Voeg een begrensd aantal pogingen toe. Een wachtlus zonder plafond verandert een kapotte tunnel in een sessie die nooit klaar is met aanmelden, en dat is een ergere supportoproep dan een ontbrekende schijfletter.

Maak het herhaalbaar en sessiebewust

Voer het uit binnen de sessie van de gebruiker zelf. Een taak die als SYSTEM draait, plaatst de schijf in een volledig andere sessie, en de aangemelde gebruiker ziet het resultaat nooit. Dat levert een script op dat succes meldt en een bureaublad zonder schijf.

Controleer voordat u koppelt, en verwijder alleen de verouderde vermelding. net use Z: /delete geeft een fout terug wanneer de letter niet in gebruik is, en die fout is veilig te negeren in plaats van een reden om de rest van het script op te geven. Houd /persistent:no aan zodat een mislukte poging later geen permanente herverbindingspoging wordt.

En zet geen wachtwoord in het bestand. rasdial kan de voor de VPN-vermelding opgeslagen inloggegevens hergebruiken, en de share zou zich als de aangemelde gebruiker moeten authenticeren. Als de share echt andere inloggegevens nodig heeft, registreer ze dan één keer per gebruiker met cmdkey in plaats van ze in te bakken in een batchbestand dat op een aanmeldingsshare staat. Iedereen die die share kan lezen, kan het wachtwoord lezen, en dat maakt van een gemak een incident.

Het hele script opnieuw uitvoeren zou onschadelijk moeten zijn, want dat is precies wat er gaat gebeuren. Gebruikers verbinden opnieuw, laptops worden wakker, en hetzelfde codepad loopt opnieuw met een andere begintoestand.

Log genoeg om te bewijzen welke helft te laat was

Schrijf de tijdstempel, het gereedheidsresultaat en de exitcode van het koppelen naar een bestand onder het gebruikersprofiel. Wanneer de volgende melding over een ontbrekende schijf binnenkomt, beantwoordt dat log de enige vraag die ertoe doet: kwam de tunnel te laat, of weigerde de share?

Zonder dat wordt elke herhaling vanaf nul onderzocht, en de gebruikelijke conclusie is een machtigingswijziging die niets oplost.

Test de reeks één keer na een koude start en één keer uit de slaapstand. Het geval van ontwaken is waar de volgorde het vaakst breekt, omdat de sessie wordt hervat voordat het netwerk dat doet, en het script een machine ziet die al uren is aangemeld.

Gerelateerde artikelen