Kør en opgave, når VPN'et opretter forbindelse: hændelse, afstemning eller legitimationsoplysning?
Et logon-script kører, før tunnelen findes. Sammenlign en netværkshændelsestrigger, en ressourceafstemning og gemte legitimationsoplysninger på, hvad hver af dem garanterer.
Et logon-script, der mapper et drev eller starter et synkroniseringsjob, kører, før tunnelen har en adresse, så det fejler lydløst, og brugeren retter det manuelt hver morgen. Windows tilbyder ikke de fleste klienter et forbindelses-callback pr. VPN, men det logger netværksændringen, og den post kan starte arbejdet på det rigtige tidspunkt. Valget står mellem at reagere på den post, at afstemme ressourcen og at fjerne den prompt, som gjorde fejlen synlig.
At sammenligne de tre mekanismer på, hvad de garanterer, slår at rangere dem efter elegance. Hver fejler forskelligt, og fejltilstanden er det, du lever med bagefter.
Hvorfor logon starter for tidligt
Logon og opstart kører, før VPN-adapteren får sin adresse, så en drevmapping, en intern URL eller en databaseforbindelse, der forsøges i det øjeblik, har hverken en rute eller en resolver. Anmodningen fejler, og sessionen efterlades i en tilstand, som brugeren må rette manuelt. At flytte det samme script til opstartsmappen ændrer intet, fordi ordensproblemet følger med. Triggeren skal være en netværksændring og ikke en sessionshændelse.
En planlagt opgave ved logon med en vilkårlig forsinkelse ligner en rettelse og er i virkeligheden et gæt. Den virker på en hurtig forbindelse og fejler på en langsom, hvilket er den mindst nyttige form for pålidelighed.
Tre hooks sammenlignet
Mekanismerne adskiller sig i, hvad de observerer, hvor hurtigt de reagerer, og hvad de gør ved en genoprettet forbindelse senere på dagen. Tabellen sammenligner dem på de tre punkter frem for på, hvor smart hver af dem lyder.
| 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 |
Læs tabellen række for række. Hændelseshooket er hurtigst og mest støjende, fordi Windows registrerer alle netværk, også caféens Wi-Fi, så handlingen skal verificere ressourcen, før den gør noget. Afstemningen er langsommere og mere præcis, fordi den lykkes præcis, når delingen eller værtsnavnet svarer, og den behøver ikke at vide, hvilken klient der er installeret. Gemte legitimationsoplysninger er slet ikke en konkurrerende mulighed: de fjerner adgangskodeprompten, hvilket er en anden og uafhængig grund til, at en mapping ved logon fejler.
Valget mellem de to første afhænger af, om der findes en brugbar hændelse på klienten. Hvor der gør, er en hændelse plus et ressourcecheck det bedre standardvalg.
Byg hændelsestriggeren korrekt
Posten ligger i loggen Microsoft-Windows-NetworkProfile/Operational, og ID 10001 markerer et netværk, der netop har oprettet forbindelse. Opret opgaven med en Ved en hændelse-trigger rettet mod den log, det udbydernavn og den identifikator. Alle netværk, maskinen tilslutter sig, vil udløse den, så handlingen har brug for en vagtklausul frem for en antagelse, og den bør kun køre, mens brugeren er logget på, hvis arbejdet rører mappede drev.
Vagtklausulen bør teste, hvad opgaven faktisk har brug for, såsom en delingssti eller en serviceport, og afslutte lydløst, når den ikke kan nås. At teste adapterens navn er ikke nok, fordi en klient kan genbruge én adapter på tværs af flere profiler. En lydløs afslutning holder loggen læsbar og forhindrer en storm af gentagne forsøg mod et netværk, der aldrig vil levere ressourcen.
Test, at opgaven kører på det rigtige tidspunkt
Bevis tidspunktet frem for konfigurationen. Kommandoerne nedenfor viser opgavedefinitionen, de seneste netværksprofilhændelser og om ressourcen kan nås fra den konto, opgaven kører som. Kør dem efter en ægte genoprettet forbindelse frem for efter en manuel start.
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiEn opgavehistorikpost, der findes, mens ingen netværkshændelse passer, betyder, at triggeren er forkert frem for handlingen. Hvis hændelserne vises, og opgaven ikke kører, kører opgaven måske under en konto, der ikke kan se ressourcen, og kontoens output er ledetråden. Et ressourcecheck, der består, mens mappingen stadig mangler, peger på sessionskontekst frem for forbindelse. Hver af de tre observationer sender dig til en anden rettelse.
Skriv én loglinje pr. kørsel med adressen, ressourceresultatet og udfaldet. Den næste fejl vil så vise, om opgaven kørte tidligt, kørte på det forkerte netværk, eller slet ikke kørte.