Spusťte úlohu při připojení VPN: událost, dotazování, nebo přihlašovací údaje?

Přihlašovací skript, který mapuje disk nebo spouští synchronizační úlohu, běží dřív, než tunel získá adresu, takže tiše selže a uživatel ho každé ráno opravuje ručně. Windows většině klientů nenabízí zpětné volání při připojení pro každou VPN, ale změnu sítě zaznamenává, a tento záznam může práci spustit ve správný okamžik. Volba je mezi reakcí na tento záznam, dotazováním zdroje a odstraněním výzvy, která selhání zviditelnila.

Porovnávat tři mechanismy podle toho, co zaručují, je lepší než je řadit podle elegance. Každý selhává jinak a s režimem selhání pak žijete.

Proč se přihlášení spouští příliš brzy

Přihlášení a spuštění systému probíhají dřív, než adaptér VPN dostane adresu, takže mapování disku, interní URL nebo připojení k databázi zkusí v tu chvíli bez trasy i bez překladače. Požadavek selže a relace zůstane ve stavu, který uživatel musí opravit ručně. Přesunutí stejného skriptu do složky po spuštění nic nezmění, protože problém s pořadím cestuje s ním. Triggerem musí být změna sítě, ne událost relace.

Naplánovaná úloha při přihlášení s libovolným zpožděním vypadá jako oprava a ve skutečnosti je to hádání. Funguje na rychlém spoji a selhává na pomalém, což je nejméně užitečný druh spolehlivosti.

Tři háčky v porovnání

Mechanismy se liší v tom, co sledují, jak rychle reagují a co dělají při opětovném připojení později během dne. Tabulka je porovnává ve těchto třech bodech, ne v tom, jak chytře který zní.

Čtěte tabulku řádek po řádku. Háček události je nejrychlejší a nejhlučnější, protože Windows zaznamenává každou síť včetně Wi-Fi v kavárně, takže akce musí zdroj ověřit, než cokoli udělá. Dotazování je pomalejší a přesnější, protože uspěje právě tehdy, když sdílená složka nebo název hostitele odpoví, a nepotřebuje vědět, který klient je nainstalován. Uložené přihlašovací údaje nejsou vůbec konkurenční možnost: odstraňují výzvu k zadání hesla, což je druhý a nezávislý důvod, proč mapování při přihlášení selhává.

Volba mezi prvními dvěma závisí na tom, zda je na klientu použitelná událost. Kde je, je událost plus kontrola zdroje lepší výchozí nastavení.

Postavte trigger události správně

Záznam žije v protokolu Microsoft-Windows-NetworkProfile/Operational a ID 10001 označuje síť, která se právě připojila. Vytvořte úlohu s triggerem Při události zaměřeným na tento protokol, tento název poskytovatele a tento identifikátor. Spustí ho každá síť, ke které se stroj připojí, takže akce potřebuje ochrannou podmínku, ne předpoklad, a pokud práce sahá na mapované disky, měla by běžet jen tehdy, dokud je uživatel přihlášen.

Ochranná podmínka by měla testovat to, co úloha skutečně potřebuje, například cestu ke sdílené složce nebo port služby, a tiše skončit, když není dostupná. Testovat název adaptéru nestačí, protože klient může jeden adaptér použít ve více profilech. Tichý odchod udržuje protokol čitelný a brání bouři opakovaných pokusů proti síti, která zdroj nikdy neposkytne.

Ověřte, že se úloha spustí ve správný okamžik

Dokažte časování, ne konfiguraci. Níže uvedené příkazy ukazují definici úlohy, nedávné události síťového profilu a to, zda je zdroj dostupný z účtu, pod kterým úloha běží. Spusťte je po skutečném opětovném připojení, ne po ručním spuštění.

schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami

Záznam v historii úlohy, který existuje, zatímco žádná síťová událost neodpovídá, znamená, že chybný je trigger, ne akce. Pokud se události objeví a úloha ne, může úloha běžet pod účtem, který zdroj nevidí, a výstup účtu je stopa. Kontrola zdroje, která projde, zatímco mapování stále chybí, ukazuje na kontext relace, ne na konektivitu. Každé z těchto tří pozorování vede k jiné opravě.

Zapište jeden řádek protokolu na každé spuštění s adresou, výsledkem zdroje a výsledkem. Další selhání pak ukáže, zda úloha běžela brzy, běžela ve špatné síti, nebo neběžela vůbec.