Å koble til VPN spiller ikke av påloggingsskriptet ditt på nytt

Brukeren din logger på hjemme, kobler til VPN og venter på stasjonskoblingen som før dukket opp av seg selv på kontoret. Tunnelen kommer opp, domenet svarer, og ingenting kobles. Ingenting er ødelagt: et påloggingsskript kjøres ved pålogging, og en tunnel som åpnes tjue minutter ut i økten er ikke en pålogging. Å lese de to som samme hendelse sender folk på jakt etter en VPN-feil som ikke finnes.

Fire beslutninger gjør overraskelsen om til en arbeidsflyt som oppfører seg, og den første er rett og slett å vite hvilke hendelser et skript rir på.

Skript rir på livssyklushendelser du ikke kan spille av på nytt

Policy på datamaskinsiden brukes når maskinen starter, og policy på brukersiden når noen logger på, mens en bakgrunnsoppdatering går gjennom de samme innstillingene uten å starte noe på nytt. Den oppdateringen behandler skriptutvidelsen, men kjører ikke de enkelte skriptene på nytt, som bare utløses ved oppstart, avslutning, pålogging eller avlogging. Derfor kan gpupdate /force rapportere suksess mens koblingen fortsatt mangler, og en ren oppdatering er ikke bevis for at skriptet gjorde noe.

Microsofts referanse om policybehandling trekker nøyaktig den grensen mellom å behandle utvidelsen og å kjøre det den inneholder, og det er siden du viser til når noen insisterer på at en oppdatering burde ha spilt skriptet på nytt.

Ikke hvert skript feiler offline heller. Et som bare leser lokalt eller hurtiglagret materiale, kan ha lykkes delvis, mens et som berører en deling, feiler stille og etterlater ikke noe tydelig spor. Sjekk den faktiske skriptbanen og hva den når, før du gir nettverket skylden. Den samme kontrollen hører hjemme i enhver påstand om at et skript ikke kjøres ved pålogging, fordi en planlagt oppgave eller en klienthandling kan gjøre arbeidet der ingen ser.

Knytt arbeidet til tilkoblingen, ikke til påloggingen

Tre forskjellige jobber skjuler seg bak uttrykket påloggingsskript: å koble til en stasjon etter at brukeren kobler seg på, å bruke maskinkonfigurasjon før noen logger på, og å hente oppdatert policy. De har ulike frister, og bare den andre trenger virkelig tilkobling før pålogging. Skriv kravet som en setning med en frist, for eksempel: denne koblingen må finnes innen ett minutt etter at tunnelen kommer opp.

For arbeid som må skje etter tilkoblingen, bruk en oppgave som utløses av tilkoblingen, eller tilkoblingshandlingen klienten støtter. Sjekk hvilken hendelse klienten faktisk sender, fordi en hendelse som den innebygde Windows VPN-klienten reiser, ikke reises av en tredjepartsklient. For maskinkonfigurasjon som må komme før pålogging, er det støttede svaret en enhetstunnel eller en annen løsning før pålogging, ikke en oppgave som utløses når skrivebordet dukker opp. Kjør arbeidet i identiteten og økten som trenger det, fordi en kobling opprettet som SYSTEM havner i en økt brukeren aldri ser.

Test beredskapen før du handler, og feil høylytt

En tilkoblingshendelse kan komme før DNS eller filserveren er brukbar, så oppgaven bør teste det den trenger i stedet for å anta. Slå opp det konkrete navnet, prøv den konkrete tilkoblingen, og prøv på nytt med en grense og en forsinkelse: Resolve-DnsName files.corp.example i en kort løkke skiller ennå-ikke fra aldri. Rapporter en konkret feil etter siste forsøk, med navnet og feilen i.

En endeløs løkke uten logg kan ikke skilles fra en oppgave som aldri startet, og den skjuler forskjellen mellom en utdatert legitimasjon og en brannmurregel.

Verifiser fire ting, og gjør det deretter repeterbart

Under piloten, registrer fire observasjoner i stedet for én: tilkoblingshendelsen utløstes, oppgaven startet, ressursen svarte, og den forespurte endringen ble faktisk gjennomført. Hvis loggen stopper ved oppgave startet, forblir den virkelige feilen usynlig uansett hvor lenge du venter. Kjør deretter gpresult /scope user /v for å se hvilken policy økten tror den har, og sammenlign med innstillingen du forventet. En rapport som lister opp GPO-en som anvendt, sier fortsatt ingenting om en kobling.

Gjør arbeidet trygt å gjenta før du utvider det, fordi klienten kobler til på nytt og oppgaven utløses igjen. Sjekk om koblingen eller konfigurasjonen allerede finnes før du oppretter den, og noter hva du fant. Dobbeltarbeid etter hver kortvarig gjenoppkobling er hvordan en nyttig oppgave blir en hendelse.

Der en automatisk utløser er uegnet, er en godkjent brukerhandling som kjører det samme signerte skriptet, et legitimt design. Den gjør tidspunktet eksplisitt i stedet for å late som en påloggingshendelse fant sted.