Mapovat disk dřív, než je VPN připravená? Podmiňte to serverem

Písmeno disku se objeví při přihlášení a pak se otevře jako prázdná složka, nebo s červeným křížkem a hláškou o nedostupném síťovém prostředku. Oprávnění bývají v pořádku. Stalo se to, že příkaz pro mapování běžel v okně, kdy klient VPN existoval, ale trasa k souborovému serveru ne, a Windows si ten neúspěch zapsal jako stav disku. Řešením je přestat mapování brát jako něco, co se děje při přihlášení, a brát ho jako poslední krok spojovací sekvence.

Proč mapování běží příliš brzy

Přihlašovací skript začíná, když začne session. Klient VPN, který se připojí během přihlášení, přidává svou vlastní časovou osu: proces může běžet, virtuální adaptér může existovat a trasa do kancelářské podsítě může stále chybět. Tyto tři stavy vypadají z pohledu skriptu stejně a funguje jen jeden z nich.

Některá prostředí reagují tak, že při každém přihlášení opakují stejný neúspěšný řádek, což vytváří uživatele, který se naučil klikat na disk dvakrát, a skript, který sám nikdy neuspěl.

Samotný disk to zhoršuje. Namapovaný disk je objekt session, a jakmile ho Windows označí jako nedostupný, ikona může zůstat rozbitá dlouho poté, co je tunel zdravý. Proto ruční přemapování funguje, zatímco skript vypadá, že nic nedělá. Session si pamatuje neúspěch, ne záměr za ním.

Stav připojeno není cesta

Ikona VPN v oznamovací oblasti hlásí, zda je tunel nahoře. Neříká nic o tom, zda existuje trasa ke konkrétnímu serveru, zda DNS překládá to jméno na adresu tunelu, ani zda vás pustí vlastní firewall serveru.

To jsou tři oddělené poruchy se stejným viditelným výsledkem a podmínění ikonou v oznamovací oblasti je slévá v jeden nespolehlivý signál.

Kontrola připravenosti, která pojmenuje server, který skutečně potřebujete je rozliší, protože selhává, dokud nefunguje konkrétní cesta, a ne dokud se nějaké rozhraní neohlásí jako připojené.

Podmiňte to serverem, ne klientem

Vyberte jeden host dostupný jen přes tunel a počkejte na něj, než cokoli namapujete. Úryvek níže připojí uložený záznam Windows VPN, otestuje souborový 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 připravenosti, ne test oprávnění. Pokud je ICMP ve vaší síti filtrovaný, otestujte místo toho službu, kterou skutečně používáte: net view \\%server% pro rychlou kontrolu, nebo krátký TCP test na port 445 v PowerShellu. Obojí se váže k tomu, na čem záleží.

Přidejte omezený počet pokusů. Čekací smyčka bez stropu promění rozbitý tunel v session, která nikdy nedokončí přihlášení, a to je horší call na podporu než chybějící písmeno disku.

Udělejte ho opakovatelně spustitelným a vědomým si session

Spouštějte ho v session samotného uživatele. Úloha běžící jako SYSTEM umístí disk do úplně jiné session a přihlášený uživatel výsledek nikdy neuvidí. Získáte tak skript hlásící úspěch a plochu bez disku.

Před mapováním zkontrolujte a odstraňte jen zastaralý záznam. net use Z: /delete vrátí chybu, když písmeno není použité, a tu chybu je bezpečné ignorovat, ne kvůli ní vzdát zbytek skriptu. Ponechte /persistent:no, aby se neúspěšný pokus později nezměnil v trvalý pokus o opětovné připojení.

A nedávejte do souboru heslo. rasdial může znovu použít přihlašovací údaje uložené pro záznam VPN a share by se měl autentizovat jako přihlášený uživatel. Pokud share opravdu potřebuje jiné údaje, zaregistrujte je jednou na uživatele pomocí cmdkey místo vkládání do batch souboru, který leží na přihlašovacím share. Kdokoli může ten share číst, může číst i heslo, a to mění pohodlí v incident.

Opětovné spuštění celého skriptu by mělo být neškodné, protože přesně to se stane. Uživatelé se znovu připojují, notebooky se probouzejí a stejná cesta kódu běží znovu s jiným počátečním stavem.

Logujte dost na to, abyste dokázali, která polovina přišla pozdě

Zapište časové razítko, výsledek kontroly připravenosti a návratový kód mapování do souboru v profilu uživatele. Až přijde další hlášení o chybějícím disku, ten log odpoví na jedinou důležitou otázku: přišel tunel pozdě, nebo share odmítl?

Bez toho se každý výskyt vyšetřuje od nuly a obvyklým závěrem je změna oprávnění, která nic neopraví.

Otestujte sekvenci jednou po studeném startu a jednou po probuzení ze spánku. Případ probuzení je místo, kde se pořadí láme nejčastěji, protože session se obnoví dřív než síť a skript vidí stroj, který je přihlášený už hodiny.