Når du forbinder til VPN, genafspilles dit logon-script ikke

Din bruger logger ind hjemme, forbinder til VPN'en og venter på det drevmap, der plejede at dukke op af sig selv på kontoret. Tunnelen kommer op, domænet svarer, og intet bliver mappet. Intet er i stykker: et logon-script kører ved logon, og en tunnel, der åbnes tyve minutter inde i sessionen, er ikke et logon. At læse de to som samme hændelse sender folk på jagt efter en VPN-fejl, der ikke findes.

Fire beslutninger forvandler overraskelsen til et arbejdsflow, der opfører sig ordentligt, og den første er simpelthen at vide, hvilke hændelser et script rider på.

Scripts rider på livscyklushændelser, du ikke kan genafspille

Politik på computersiden anvendes, når maskinen starter, og politik på brugersiden, når nogen logger ind, mens en baggrundsopdatering gennemløber de samme indstillinger uden at genstarte noget. Den opdatering behandler script-udvidelsen, men den kører ikke de enkelte scripts igen, som kun udløses ved opstart, nedlukning, logon eller logoff. Så gpupdate /force kan rapportere succes, mens mapningen stadig mangler, og en ren opdatering er ikke bevis på, at scriptet gjorde noget.

Microsofts reference om politikbehandling trækker præcis den grænse mellem at behandle udvidelsen og at køre det, den indeholder, og det er den side, man citerer, når nogen insisterer på, at en opdatering burde have genafspillet scriptet.

Ikke ethvert script fejler heller offline. Et, der kun læser lokalt eller cachet materiale, kan være delvist lykkedes, mens et, der rører en delt ressource, fejler stille og efterlader intet tydeligt spor. Kontroller scriptets faktiske sti og hvad det når, før du bebrejder netværket. Samme granskning hører til enhver påstand om, at et script ikke kører ved logon, for en planlagt opgave eller en klienthandling kan udføre arbejdet, hvor ingen kigger.

Knyt arbejdet til forbindelsen, ikke til logon

Tre forskellige opgaver skjuler sig bag ordet logon-script: at mappe et drev efter brugerens forbindelse, at anvende maskinkonfiguration før nogen logger ind, og at hente opdateret politik. De har forskellige deadlines, og kun den anden har reelt brug for forbindelse før logon. Skriv kravet som en sætning med en deadline, for eksempel: denne mapning skal findes inden for et minut efter tunnelen kommer op.

Til arbejde, der skal ske efter forbindelsen, brug en forbindelsesudløst opgave eller den forbindelseshandling, klienten understøtter. Kontroller, hvilken hændelse klienten faktisk udsender, for en hændelse rejst af den indbyggede Windows VPN-klient rejses ikke af en tredjepartsklient. Til maskinkonfiguration, der skal gå forud for logon, er det understøttede svar en enhedstunnel eller et andet design før logon, ikke en opgave, der udløses, når skrivebordet dukker op. Kør arbejdet i den identitet og session, der har brug for det, da en mapning oprettet som SYSTEM lander i en session, brugeren aldrig ser.

Test parathed, før du handler, og fejl højlydt

En forbindelseshændelse kan ankomme, før DNS eller fileserveren er brugbar, så opgaven bør teste, hvad den har brug for, i stedet for at antage. Slå det konkrete navn op, forsøg den konkrete forbindelse, og prøv igen med en grænse og en forsinkelse: Resolve-DnsName files.corp.example i en kort løkke skiller endnu-ikke fra aldrig. Rapporter en konkret fejl efter det sidste forsøg, med navnet og fejlen i den.

En endeløs løkke uden log kan ikke skelnes fra en opgave, der aldrig startede, og den skjuler forskellen mellem en forældet legitimationsoplysning og en firewallregel.

Verificer fire ting, og gør det derefter gentageligt

Under piloten skal du registrere fire observationer i stedet for én: forbindelseshændelsen blev udløst, opgaven startede, ressourcen svarede, og den ønskede ændring blev faktisk gennemført. Hvis loggen stopper ved opgave startet, forbliver den reelle fejl usynlig, uanset hvor længe du venter. Kør derefter gpresult /scope user /v for at se, hvad sessionen tror, dens politik er, og sammenlign det med den indstilling, du forventede. En rapport, der viser GPO'en som anvendt, siger stadig intet om en mapning.

Gør arbejdet sikkert at gentage, før du udvider det, for klienten genopretter forbindelsen, og opgaven udløses igen. Kontroller for den eksisterende mapning eller konfiguration, før du opretter den, og notér, hvad du fandt. Dobbeltarbejde efter hver kortvarig genopkobling er måden, hvorpå en hjælpsom opgave bliver en hændelse.

Hvor en automatisk udløser er uegnet, er en godkendt brugerhandling, der kører det samme signerede script, et legitimt design. Det gør timingen eksplicit i stedet for at foregive, at en logon-hændelse fandt sted.