Feladat futtatása VPN-csatlakozáskor: esemény, lekérdezés vagy hitelesítő adat?

A bejelentkezési szkript, amely meghajtót csatol vagy szinkronizálási feladatot indít, azelőtt fut, hogy az alagútnak címe lenne, ezért csendben meghiúsul, és a felhasználó minden reggel kézzel javítja. A Windows a legtöbb kliensnek nem kínál VPN-enkénti csatlakozási visszahívást, de naplózza a hálózati változást, és ez a bejegyzés a megfelelő pillanatban elindíthatja a munkát. A választás a bejegyzésre való reagálás, az erőforrás lekérdezése és a hibát láthatóvá tevő kérés eltávolítása között van.

A három mechanizmus összehasonlítása aszerint, mit garantálnak, jobb, mint elegancia szerint rangsorolni őket. Mindegyik másképp hibázik, és a hiba módjával él együtt utána.

Miért indul túl korán a bejelentkezés

A bejelentkezés és az indítás azelőtt fut, hogy a VPN-adapter megkapná a címét, ezért az abban a pillanatban megkísérelt meghajtóleképezésnek, belső URL-nek vagy adatbázis-kapcsolatnak nincs sem útvonala, sem feloldója. A kérés meghiúsul, és a munkamenet olyan állapotban marad, amelyet a felhasználónak kézzel kell javítania. Ugyanannak a szkriptnek az indítómappába helyezése semmit sem változtat, mert a sorrend problémája vele együtt utazik. A triggernek hálózati változásnak kell lennie, nem munkamenet-eseménynek.

A bejelentkezéskor önkényes késleltetéssel ütemezett feladat javításnak látszik, valójában találgatás. Gyors kapcsolaton működik, lassún meghiúsul, ami a megbízhatóság legkevésbé hasznos fajtája.

Három horog összevetve

A mechanizmusok abban különböznek, mit figyelnek, milyen gyorsan reagálnak, és mit tesznek a nap későbbi újracsatlakozásakor. A táblázat e három ponton hasonlítja össze őket, nem azon, mennyire okosnak hangzik mindegyik.

Olvassa a táblázatot soronként. Az eseményhorog a leggyorsabb és a leghangosabb, mert a Windows minden hálózatot rögzít, a kávézó Wi-Fi-jét is, ezért a műveletnek ellenőriznie kell az erőforrást, mielőtt bármit tenne. A lekérdezés lassabb és pontosabb, mert pontosan akkor sikerül, amikor a megosztás vagy a gazdagépnév válaszol, és nem kell tudnia, melyik kliens van telepítve. A tárolt hitelesítő adatok egyáltalán nem versengő lehetőség: eltávolítják a jelszókérést, ami második és független oka annak, hogy a bejelentkezéskori leképezés meghiúsul.

Az első kettő közötti választás azon múlik, van-e használható esemény a kliensen. Ahol van, ott az esemény plusz erőforrás-ellenőrzés a jobb alapértelmezés.

Építse fel helyesen az esemény-triggert

A bejegyzés a Microsoft-Windows-NetworkProfile/Operational naplóban él, és az 10001-es azonosító egy éppen csatlakozott hálózatot jelöl. Hozza létre a feladatot egy Esemény esetén triggerrel, amely erre a naplóra, erre a szolgáltatónévre és erre az azonosítóra irányul. Minden hálózat, amelyhez a gép csatlakozik, aktiválja, ezért a műveletnek őrzőfeltételre van szüksége, nem feltevésre, és ha a munka leképezett meghajtókat érint, csak akkor futhat, amíg a felhasználó be van jelentkezve.

Az őrzőfeltételnek azt kell vizsgálnia, amire a feladatnak tényleg szüksége van, például egy megosztási útvonalat vagy egy szolgáltatási portot, és csendben ki kell lépnie, amikor nem érhető el. Az adapter nevének vizsgálata nem elég, mert egy kliens több profilban is újrahasználhat egy adaptert. A csendes kilépés olvashatóvá tartja a naplót, és megakadályozza az újrapróbálkozások viharát egy olyan hálózat ellen, amely soha nem szolgálja ki az erőforrást.

Ellenőrizze, hogy a feladat a megfelelő pillanatban fut

Az időzítést bizonyítsa, ne a konfigurációt. Az alábbi parancsok megmutatják a feladat definícióját, a legutóbbi hálózatiprofil-eseményeket, és azt, hogy az erőforrás elérhető-e abból a fiókból, amely alatt a feladat fut. Valódi újracsatlakozás után futtassa őket, ne kézi indítás után.

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

Az a feladatelőzmény-bejegyzés, amely akkor létezik, amikor egyetlen hálózati esemény sem illeszkedik, azt jelenti, hogy a trigger a hibás, nem a művelet. Ha az események megjelennek, a feladat pedig nem fut, a feladat talán olyan fiók alatt fut, amely nem látja az erőforrást, és a fiók kimenete a nyom. Az az erőforrás-ellenőrzés, amely átmegy, miközben a leképezés még hiányzik, a munkamenet kontextusára utal, nem a kapcsolatra. E három megfigyelés mindegyike más javításhoz vezet.

Futtatásonként írjon egy naplósort a címmel, az erőforrás eredményével és a kimenettel. A következő hiba akkor megmutatja, hogy a feladat korán futott, rossz hálózaton futott, vagy egyáltalán nem futott.