Køyr ein oppgåve når VPN-en koplar til: hending, avspørjing eller påloggingsinformasjon?
Eit påloggingsskript køyrer før tunnelen finst. Samanlikn ein nettverkshending-triggar, ei ressursavspørjing og lagra påloggingsinformasjon etter kva kvar av dei garanterer.
Eit påloggingsskript som koplar til ein stasjon eller startar ein synkroniseringsjobb, køyrer før tunnelen har ei adresse, så det feilar stille og brukaren reparerer det for hand kvar morgon. Windows tilbyr ikkje dei fleste klientane eit tilbakekall per VPN-tilkopling, men det loggar nettverksendringa, og den posten kan starte arbeidet i rett augneblink. Valet står mellom å reagere på den posten, å spørje ressursen og å fjerne ledeteksta som gjorde feilen synleg.
Å samanlikne dei tre mekanismane etter kva dei garanterer er betre enn å rangere dei etter eleganse. Kvar feilar ulikt, og feilmodusen er det du lever med etterpå.
Kvifor pålogging startar for tidleg
Pålogging og oppstart køyrer før VPN-adapteren får adressa si, så ein stasjonskopling, ein intern URL eller ei databasekopling som vert freista i det augneblinken har korkje rute eller oppløysar. Førespurnaden feilar, og økta vert ståande i ein tilstand brukaren må reparere manuelt. Å flytte det same skriptet til oppstartsmappa endrar ingenting, fordi rekkjefølgjeproblemet følgjer med. Utløysaren må vere ei nettverksendring og ikkje ei økthending.
Ei planlagd oppgåve ved pålogging med vilkårleg forseinking ser ut som ei reparasjon og er eigentleg ei gjetning. Ho verkar på ei rask linje og feilar på ei treg, som er den minst nyttige typen pålitelegheit.
Tre krokars samanlikning
Mekanismane skil seg i kva dei observerer, kor raskt dei reagerer og kva dei gjer med ei attkopling seinare på dagen. Tabellen samanliknar dei på desse tre punkta og ikkje på kor smart kvar av dei høyrest ut.
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
Les tabellen rad for rad. Hendingkroken er raskast og mest støyande, sidan Windows registrerer kvart nettverk, òg Wi-Fi-en på kafeen, så handlinga må stadfeste ressursen før ho gjer noko. Avspørjinga er tregare og meir presis, fordi ho lukkast nøyaktig når delinga eller vertsnamnet svarar, og ho treng ikkje vite kva klient som er installert. Lagra påloggingsinformasjon er slett ikkje eit konkurrerande alternativ: det fjernar passordledeteksta, som er ein andre og uavhengig grunn til at ei kopling ved pålogging feilar.
Valet mellom dei to første avheng av om det finst ei brukbar hending på klienten. Der det finst, er ei hending pluss ein ressurskontroll det betre standardvalet.
Bygg hendingutløysaren rett
Posten ligg i loggen Microsoft-Windows-NetworkProfile/Operational, og ID 10001 markerer eit nettverk som nettopp kopla til. Opprett oppgåva med ein Ved ei hending-utløysar retta mot den loggen, det leverandørnamnet og den identifikatoren. Kvart nettverk maskinen koplar seg til, vil utløyse han, så handlinga treng ein vaktklausul og ikkje ei føresetnad, og ho bør berre køyre medan brukaren er pålogga om arbeidet rører kopla stasjonar.
Vaktklausulen bør teste det oppgåva faktisk treng, som ein delingssti eller ein tenesteport, og avslutte stille når han ikkje er tilgjengeleg. Å teste adapternamnet er ikkje nok, fordi ein klient kan bruke om att ein adapter over fleire profilar. Ei stille avslutning held loggen lesbar og hindrar ein storm av nye forsøk mot eit nettverk som aldri vil levere ressursen.
Test at oppgåva køyrer i rett augneblink
Prov tidspunktet og ikkje konfigurasjonen. Kommandoane nedanfor viser oppgåvedefinisjonen, dei siste nettverksprofilhendingane og om ressursen er tilgjengeleg frå kontoen oppgåva køyrer under. Køyr dei etter ei ekte attkopling og ikkje etter ein manuell start.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiEin oppgåvehistorikkpost som finst medan inga nettverkshending passar, tyder på at utløysaren er feil og ikkje handlinga. Viss hendingane viser seg og oppgåva ikkje køyrer, kan oppgåva køyre under ein konto som ikkje ser ressursen, og utdata frå kontoen er leiartråden. Ein ressurskontroll som går gjennom medan koplinga framleis manglar, peikar på øktkonteksten og ikkje på tilkoplinga. Kvar av dei tre observasjonane sender deg til ei anna reparasjon.
Skriv éi logglinje per køyring med adressa, ressursresultatet og utfallet. Den neste feilen vil då vise om oppgåva køyrde tidleg, køyrde på feil nettverk eller ikkje køyrde i det heile.