Et påloggingsskript som mapper en stasjon eller starter en synkroniseringsjobb, kjører før tunnelen har en adresse, så det feiler stille og brukeren reparerer det for hånd hver morgen. Windows tilbyr ikke de fleste klienter et tilbakekall per VPN-tilkobling, men det logger nettverksendringen, og den posten kan starte arbeidet i rett øyeblikk. Valget står mellom å reagere på den posten, å avspørre ressursen og å fjerne ledeteksten som gjorde feilen synlig.

Å sammenligne de tre mekanismene etter hva de garanterer er bedre enn å rangere dem etter eleganse. Hver feiler forskjellig, og feilmodusen er det du lever med etterpå.

Hvorfor pålogging starter for tidlig

Pålogging og oppstart kjører før VPN-adapteren får adressen sin, så en stasjonsmapping, en intern URL eller en databaseforbindelse som forsøkes i det øyeblikket har verken rute eller oppløser. Forespørselen feiler, og økten blir stående i en tilstand brukeren må reparere manuelt. Å flytte det samme skriptet til oppstartsmappen endrer ingenting, fordi rekkefølgeproblemet følger med. Utløseren må være en nettverksendring og ikke en økthendelse.

En planlagt oppgave ved pålogging med vilkårlig forsinkelse ser ut som en reparasjon og er egentlig en gjetning. Den virker på en rask linje og feiler på en treg, som er den minst nyttige typen pålitelighet.

Tre kroker sammenlignet

Mekanismene skiller seg i hva de observerer, hvor raskt de reagerer og hva de gjør med en gjentilkobling senere på dagen. Tabellen sammenligner dem på disse tre punktene og ikke på hvor smart hver enkelt høres ut.

MechanismReacts toCovers a mid-session reconnectTypical failure
Network profile eventA network connect recordYes, when the event repeatsRuns on the wrong network
Resource poll with backoffThe resource becoming reachableYesLog noise and a wasted window
Stored credentials aloneNothing; it removes a promptNoStill fires before the tunnel

Les tabellen rad for rad. Hendelseskroken er raskest og mest støyende, siden Windows registrerer hvert nettverk, også kaféens Wi-Fi, så handlingen må verifisere ressursen før den gjør noe. Avspørringen er tregere og mer presis, fordi den lykkes nøyaktig når delingen eller vertsnavnet svarer, og den trenger ikke vite hvilken klient som er installert. Lagret påloggingsinformasjon er slett ikke et konkurrerende alternativ: det fjerner passordledeteksten, som er en andre og uavhengig grunn til at en mapping ved pålogging feiler.

Valget mellom de to første avhenger av om det finnes en brukbar hendelse på klienten. Der det finnes, er en hendelse pluss en ressurskontroll det bedre standardvalget.

Bygg hendelsesutløseren riktig

Posten ligger i loggen Microsoft-Windows-NetworkProfile/Operational, og ID 10001 markerer et nettverk som nettopp koblet til. Opprett oppgaven med en Ved en hendelse-utløser rettet mot den loggen, det leverandørnavnet og den identifikatoren. Hvert nettverk maskinen kobler seg til, vil utløse den, så handlingen trenger en vaktklausul og ikke en antakelse, og den bør bare kjøre mens brukeren er pålogget hvis arbeidet berører mappede stasjoner.

Vaktklausulen bør teste det oppgaven faktisk trenger, som en delingssti eller en tjenesteport, og avslutte stille når den ikke er tilgjengelig. Å teste adapternavnet er ikke nok, fordi en klient kan gjenbruke én adapter på tvers av flere profiler. En stille avslutning holder loggen lesbar og forhindrer en storm av nye forsøk mot et nettverk som aldri vil levere ressursen.

Test at oppgaven kjører i rett øyeblikk

Bevis tidspunktet og ikke konfigurasjonen. Kommandoene nedenfor viser oppgavedefinisjonen, de siste nettverksprofilhendelsene og om ressursen er tilgjengelig fra kontoen oppgaven kjører under. Kjør dem etter en ekte gjentilkobling og ikke etter en manuell start.

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

En oppgavehistorikkpost som finnes mens ingen nettverkshendelse passer, betyr at utløseren er feil og ikke handlingen. Hvis hendelsene vises og oppgaven ikke kjører, kan oppgaven kjøre under en konto som ikke ser ressursen, og kontoens utdata er ledetråden. En ressurskontroll som består mens mappingen fortsatt mangler, peker på øktkonteksten og ikke på tilkoblingen. Hver av de tre observasjonene sender deg til en annen reparasjon.

Skriv én logglinje per kjøring med adressen, ressursresultatet og utfallet. Den neste feilen vil da vise om oppgaven kjørte tidlig, kjørte på feil nettverk eller ikke kjørte i det hele tatt.

Relaterte artikler