Netværksdrev før VPN er klar? Gør det afhængigt af serveren

Drevbogstavet vises ved logon og åbner derefter som en tom mappe, eller med et rødt kryds og en meddelelse om en utilgængelig netværksressource. Rettighederne er normalt i orden. Det, der skete, er, at mapper-kommandoen kørte i det vindue, hvor VPN-klienten fandtes, men der ikke var nogen rute til filserveren, og Windows registrerede den fejl som drevets tilstand. Løsningen er at holde op med at behandle mapperen som noget, der sker ved logon, og behandle den som det sidste trin i en forbindelsessekvens.

Hvorfor mapperen kører for tidligt

Et logon-script starter, når sessionen starter. En VPN-klient, der forbinder under logon, lægger sin egen tidslinje ovenpå: processen kan køre, den virtuelle adapter kan findes, og ruten til kontorets undernet kan stadig mangle. De tre tilstande ser ens ud fra et scripts synspunkt, og kun én af dem virker.

Nogle miljøer reagerer med at gentage den samme fejlende linje ved hvert logon, hvilket giver en bruger, der har lært at klikke på drevet to gange, og et script, der aldrig er lykkedes alene.

Selve drevet gør det værre. Et mappet drev er et sessionsobjekt, og når Windows først har markeret det som utilgængeligt, kan ikonet forblive ødelagt længe efter, at tunnelen er sund. Derfor virker det at mappe igen manuelt, mens scriptet ser ud til ikke at gøre noget. Sessionen husker fejlen, ikke hensigten bag den.

Status som forbundet er ikke en rute

VPN-ikonet i proceslinjen fortæller, om tunnelen er oppe. Det siger intet om, hvorvidt der findes en rute til en bestemt server, om DNS opløser det navn til tunneladressen, eller om serverens egen firewall accepterer dig.

Det er tre separate fejl med samme synlige resultat, og hvis man gør ikonet i proceslinjen til betingelsen, smelter de sammen til ét upålideligt signal.

Et parathedstjek, der navngiver den server, du faktisk har brug for skelner dem, fordi det fejler, indtil den konkrete rute virker, og ikke indtil en eller anden grænseflade melder sig som forbundet.

Gør serveren til betingelsen, ikke klienten

Vælg én vært, der kun kan nås gennem tunnelen, og vent på den, før du mapper noget. Uddraget nedenfor forbinder en gemt Windows VPN-post, undersøger filserveren og mapper derefter drevet.

@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 er en parathedsprobe, ikke en rettighedstest. Hvis ICMP filtreres på dit netværk, så undersøg i stedet den tjeneste, du faktisk bruger: net view \\%server% til et hurtigt tjek, eller en kort TCP-test mod port 445 i PowerShell. Begge gør det, der betyder noget, til betingelsen.

Tilføj et begrænset antal forsøg. En venteløkke uden loft gør en brudt tunnel til en session, der aldrig bliver færdig med at logge ind, og det er et værre supportopkald end et manglende drevbogstav.

Gør den genkørbar og sessionsbevidst

Kør den inde i brugerens egen session. En opgave, der kører som SYSTEM, placerer drevet i en helt anden session, og den loggede bruger ser aldrig resultatet. Det giver dig et script, der rapporterer succes, og en skrivebord uden drev.

Tjek før du mapper, og fjern kun den forældede post. net use Z: /delete returnerer en fejl, når bogstavet ikke er i brug, og den fejl er sikker at ignorere i stedet for at være grund til at opgive resten af scriptet. Behold /persistent:no, så et mislykket forsøg ikke senere bliver til et permanent genopkoblingsforsøg.

Og læg ikke en adgangskode i filen. rasdial kan genbruge de legitimationsoplysninger, der er gemt til VPN-posten, og delingen bør godkende som den loggede bruger. Hvis delingen virkelig har brug for andre oplysninger, så registrer dem én gang pr. bruger med cmdkey i stedet for at indlejre dem i en batch-fil, der ligger på en logon-deling. Alle, der kan læse den deling, kan læse adgangskoden, og det gør en bekvemmelighed til en hændelse.

At køre hele scriptet igen bør være uskadeligt, for det er, hvad der vil ske. Brugere genopkobler, bærbare vågner, og den samme kodesti kører igen med en anden starttilstand.

Log nok til at bevise, hvilken halvdel der var sen

Skriv tidsstemplet, parathedsresultatet og mappernes exitkode til en fil under brugerprofilen. Når den næste rapport om et manglende drev kommer, svarer den log på det eneste spørgsmål, der betyder noget: kom tunnelen for sent, eller afviste delingen?

Uden det undersøges hver gentagelse fra bunden, og den sædvanlige konklusion er en rettighedsændring, der ikke løser noget.

Test sekvensen én gang fra en kold opstart og én gang fra dvale. Vågnetilfældet er der, hvor rækkefølgen oftest bryder sammen, fordi sessionen genoptages, før netværket gør, og scriptet ser en maskine, der har været logget ind i timer.