Písmeno disku sa objaví pri prihlásení a potom sa otvorí ako prázdny priečinok, alebo s červeným krížikom a hlásením o nedostupnom sieťovom prostriedku. Oprávnenia bývajú v poriadku. Stalo sa to, že príkaz na mapovanie bežal v okne, keď klient VPN existoval, ale trasa k súborovému serveru nie, a Windows si ten neúspech zapísal ako stav disku. Riešením je prestať brať mapovanie ako niečo, čo sa deje pri prihlásení, a brať ho ako posledný krok spojovacej sekvencie.

Prečo mapovanie beží príliš skoro

Prihlasovací skript začína, keď začne session. Klient VPN, ktorý sa pripojí počas prihlásenia, pridáva svoju vlastnú časovú os: proces môže bežať, virtuálny adaptér môže existovať a trasa do kancelárskej podsiete môže stále chýbať. Tieto tri stavy vyzerajú z pohľadu skriptu rovnako a funguje len jeden z nich.

Niektoré prostredia reagujú tak, že pri každom prihlásení opakujú ten istý neúspešný riadok, čo vytvára používateľa, ktorý sa naučil kliknúť na disk dvakrát, a skript, ktorý sám nikdy neuspel.

Samotný disk to zhoršuje. Namapovaný disk je objekt session, a keď ho Windows označí ako nedostupný, ikona môže zostať pokazená dlho po tom, čo je tunel zdravý. Preto ručné premapovanie funguje, zatiaľ čo skript vyzerá, že nič nerobí. Session si pamätá neúspech, nie zámer za ním.

Stav pripojené nie je cesta

Ikona VPN v oznamovacej oblasti hlási, či je tunel hore. Nehovorí nič o tom, či existuje trasa ku konkrétnemu serveru, či DNS prekladá to meno na adresu tunela, ani či vás pustí vlastný firewall serveru.

To sú tri oddelené poruchy s rovnakým viditeľným výsledkom a podmienenie ikonou v oznamovacej oblasti ich zlieva do jedného nespoľahlivého signálu.

Kontrola pripravenosti, ktorá pomenuje server, ktorý skutočne potrebujete ich rozlíši, pretože zlyháva, kým nefunguje konkrétna cesta, a nie kým sa nejaké rozhranie neohlási ako pripojené.

Podmieňte to serverom, nie klientom

Vyberte jeden host dostupný len cez tunel a počkajte naň, kým čokoľvek namapujete. Úryvok nižšie pripojí uložený záznam Windows VPN, otestuje súborový server a potom namapuje disk.

@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 je sonda pripravenosti, nie test oprávnení. Ak je ICMP vo vašej sieti filtrovaný, otestujte namiesto toho službu, ktorú skutočne používate: net view \\%server% na rýchlu kontrolu, alebo krátky TCP test na port 445 v PowerShelli. Oboje sa viaže na to, na čom záleží.

Pridajte obmedzený počet pokusov. Čakacia slučka bez stropu premení pokazený tunel na session, ktorá nikdy nedokončí prihlásenie, a to je horší call na podporu ako chýbajúce písmeno disku.

Urobte ho opakovane spustiteľným a vedomým si session

Spúšťajte ho v session samotného používateľa. Úloha bežiaca ako SYSTEM umiestni disk do úplne inej session a prihlásený používateľ výsledok nikdy neuvidí. Získate tak skript hlásiaci úspech a plochu bez disku.

Pred mapovaním skontrolujte a odstráňte len zastaraný záznam. net use Z: /delete vráti chybu, keď písmeno nie je použité, a tú chybu je bezpečné ignorovať, nie pre ňu vzdať zvyšok skriptu. Ponechajte /persistent:no, aby sa neúspešný pokus neskôr nezmenil na trvalý pokus o opätovné pripojenie.

A nedávajte do súboru heslo. rasdial môže znova použiť prihlasovacie údaje uložené pre záznam VPN a share by sa mal autentizovať ako prihlásený používateľ. Ak share naozaj potrebuje iné údaje, zaregistrujte ich raz na používateľa pomocou cmdkey namiesto vkladania do batch súboru, ktorý leží na prihlasovacom share. Ktokoľvek môže ten share čítať, môže čítať aj heslo, a to mení pohodlie na incident.

Opätovné spustenie celého skriptu by malo byť neškodné, pretože presne to sa stane. Používatelia sa znova pripájajú, notebooky sa prebúdzajú a tá istá cesta kódu beží znova s iným počiatočným stavom.

Logujte dosť na to, aby ste dokázali, ktorá polovica prišla neskoro

Zapíšte časovú pečiatku, výsledok kontroly pripravenosti a návratový kód mapovania do súboru v profile používateľa. Keď príde ďalšie hlásenie o chýbajúcom disku, ten log odpovie na jedinú dôležitú otázku: prišiel tunel neskoro, alebo share odmietol?

Bez toho sa každý výskyt vyšetruje od nuly a obvyklým záverom je zmena oprávnení, ktorá nič neopraví.

Otestujte sekvenciu raz po studenom štarte a raz po prebudení zo spánku. Prípad prebudenia je miesto, kde sa poradie láme najčastejšie, pretože session sa obnoví skôr než sieť a skript vidí stroj, ktorý je prihlásený už hodiny.

Súvisiace články