Mappa enheten innan VPN är klart? Gör det beroende av servern

Enhetsbokstaven dyker upp vid inloggning och öppnas sedan som en tom mapp, eller med ett rött kryss och ett meddelande om en otillgänglig nätverksresurs. Behörigheterna är oftast i ordning. Det som hände är att mappningskommandot kördes i fönstret där VPN-klienten fanns men det inte fanns någon rutt till filservern, och Windows registrerade det felet som enhetens tillstånd. Lösningen är att sluta behandla mappningen som något som sker vid inloggning och behandla den som det sista steget i en anslutningssekvens.

Varför mappningen körs för tidigt

Ett inloggningsskript börjar när sessionen börjar. En VPN-klient som ansluter under inloggningen lägger sin egen tidslinje ovanpå: processen kan köra, den virtuella adaptern kan finnas, och rutten till kontorets subnät kan fortfarande saknas. Dessa tre tillstånd ser likadana ut från ett skripts synvinkel och bara ett av dem fungerar.

Vissa miljöer svarar med att upprepa samma misslyckade rad vid varje inloggning, vilket ger en användare som lärt sig klicka två gånger på enheten och ett skript som aldrig lyckats själv.

Själva enheten gör det värre. En mappad enhet är ett sessionsobjekt, och när Windows har markerat den som otillgänglig kan ikonen förbli trasig långt efter att tunneln är frisk. Det är därför manuell ommappning fungerar medan skriptet verkar göra ingenting. Sessionen minns felet, inte avsikten bakom det.

Statusen ansluten är inte en väg

VPN-ikonen i aktivitetsfältet anger om tunneln är uppe. Den säger ingenting om huruvida det finns en rutt till en viss server, om DNS löser upp det namnet till tunnelns adress, eller om serverns egen brandvägg släpper igenom dig.

Det är tre separata fel med samma synliga resultat, och att göra aktivitetsfältets ikon till villkoret smälter dem samman till en enda opålitlig signal.

En beredskapskontroll som namnger servern du faktiskt behöver skiljer dem, eftersom den misslyckas tills den specifika rutten fungerar, och inte förrän något gränssnitt rapporterar sig som anslutet.

Gör servern till villkoret, inte klienten

Välj en värd som bara nås genom tunneln och vänta på den innan du mappar något. Utdraget nedan ansluter till en sparad Windows VPN-post, kontrollerar filservern och mappar sedan enheten.

@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 är en beredskapsprobe, inte ett behörighetstest. Om ICMP filtreras i ditt nätverk, kontrollera i stället tjänsten du faktiskt använder: net view \\%server% för en snabb kontroll, eller ett kort TCP-test mot port 445 i PowerShell. Båda gör det som spelar roll till villkoret.

Lägg till ett begränsat antal försök. En vänteloop utan tak gör en trasig tunnel till en session som aldrig blir klar med inloggningen, och det är ett värre supportärende än en saknad enhetsbokstav.

Gör den körbar igen och sessionsmedveten

Kör den i användarens egen session. En uppgift som körs som SYSTEM placerar enheten i en helt annan session, och den inloggade användaren ser aldrig resultatet. Det ger dig ett skript som rapporterar framgång och ett skrivbord utan enhet.

Kontrollera innan du mappar och ta bort bara den inaktuella posten. net use Z: /delete returnerar ett fel när bokstaven inte används, och det felet är säkert att ignorera i stället för att vara skäl att överge resten av skriptet. Behåll /persistent:no så att ett misslyckat försök inte senare blir ett permanent återanslutningsförsök.

Och lägg inte ett lösenord i filen. rasdial kan återanvända de uppgifter som sparats för VPN-posten, och utdelningen bör autentisera som den inloggade användaren. Om utdelningen verkligen behöver andra uppgifter, registrera dem en gång per användare med cmdkey i stället för att bädda in dem i en batchfil som ligger på en inloggningsutdelning. Den som kan läsa den utdelningen kan läsa lösenordet, och det gör en bekvämlighet till en incident.

Att köra hela skriptet igen bör vara ofarligt, för det är precis vad som kommer att hända. Användare återansluter, bärbara datorer vaknar, och samma kodväg körs igen med ett annat starttillstånd.

Logga tillräckligt för att bevisa vilken halva som var sen

Skriv tidsstämpeln, beredskapsresultatet och mappningens utgångskod till en fil under användarprofilen. När nästa rapport om en saknad enhet kommer svarar den loggen på den enda fråga som spelar roll: kom tunneln för sent, eller nekade utdelningen?

Utan det undersöks varje upprepning från början, och den vanliga slutsatsen är en behörighetsändring som inte rättar något.

Testa sekvensen en gång från en kall start och en gång från viloläge. Uppvakningsfallet är där ordningen oftast brister, eftersom sessionen återupptas innan nätverket gör det och skriptet ser en maskin som varit inloggad i timmar.