Collegarsi alla VPN non riesegue lo script di accesso

Il vostro utente accede da casa, collega la VPN e aspetta la mappatura dell'unità che prima compariva da sola in ufficio. Il tunnel sale, il dominio risponde e nulla viene mappato. Nulla è rotto: uno script di accesso viene eseguito all'accesso, e un tunnel aperto venti minuti dopo l'inizio della sessione non è un accesso. Leggere i due come lo stesso evento manda la gente a cercare un guasto VPN che non esiste.

Quattro decisioni trasformano la sorpresa in un flusso di lavoro che si comporta bene, e la prima è semplicemente sapere su quali eventi cavalca uno script.

Gli script cavalcano eventi del ciclo di vita che non potete riprodurre

I criteri lato computer vengono applicati all'avvio della macchina e quelli lato utente all'accesso, mentre un aggiornamento in background percorre le stesse impostazioni senza riavviare nulla. Quell'aggiornamento elabora l'estensione degli script, ma non riesegue i singoli script, che si attivano solo all'avvio, allo spegnimento, all'accesso o alla disconnessione. Quindi gpupdate /force può riportare successo mentre la mappatura manca ancora, e un aggiornamento pulito non è prova che lo script abbia fatto qualcosa.

La documentazione Microsoft sull'elaborazione dei criteri traccia esattamente quella linea tra l'elaborazione dell'estensione e l'esecuzione di ciò che contiene, ed è la pagina da citare quando qualcuno insiste che un aggiornamento avrebbe dovuto rieseguire lo script.

Non ogni script fallisce anche offline. Uno che legge solo materiale locale o in cache può essere riuscito in parte, mentre uno che tocca una condivisione fallisce in silenzio e non lascia un segno evidente. Controllate il percorso reale dello script e cosa raggiunge prima di dare la colpa alla rete. La stessa verifica spetta a ogni affermazione secondo cui uno script non viene eseguito all'accesso, perché un'attività pianificata o un'azione del client possono fare il lavoro dove nessuno guarda.

Legate il lavoro alla connessione, non all'accesso

Tre lavori diversi si nascondono dietro la frase script di accesso: mappare un'unità dopo che l'utente si collega, applicare la configurazione della macchina prima che qualcuno acceda e recuperare i criteri aggiornati. Hanno scadenze diverse, e solo il secondo ha davvero bisogno di connettività prima dell'accesso. Scrivete il requisito come una frase con una scadenza, per esempio: questa mappatura deve esistere entro un minuto dalla salita del tunnel.

Per il lavoro che deve avvenire dopo la connessione, usate un'attività attivata dalla connessione o l'azione di connessione supportata dal client. Verificate quale evento il client emette davvero, perché un evento sollevato dal client VPN nativo di Windows non viene sollevato da un client di terze parti. Per la configurazione della macchina che deve precedere l'accesso, la risposta supportata è un tunnel di dispositivo o un'altra progettazione pre-accesso, non un'attività che scatta quando appare il desktop. Eseguite il lavoro nell'identità e nella sessione che ne hanno bisogno, poiché una mappatura creata come SYSTEM finisce in una sessione che l'utente non vede mai.

Verificate la preparazione prima di agire, e fallite in modo rumoroso

Un evento di connessione può arrivare prima che il DNS o il file server siano utilizzabili, quindi l'attività deve verificare ciò che le serve invece di presumere. Risolvete il nome specifico, tentate la connessione specifica e riprovate con un limite e un ritardo: Resolve-DnsName files.corp.example dentro un ciclo breve separa non-ancora da mai. Segnalate un guasto concreto dopo l'ultimo tentativo, con il nome e l'errore dentro.

Un ciclo infinito senza log è indistinguibile da un'attività che non è mai iniziata, e nasconde la differenza tra una credenziale scaduta e una regola del firewall.

Verificate quattro cose, poi rendetelo ripetibile

Durante il pilota, registrate quattro osservazioni invece di una: l'evento di connessione è scattato, l'attività è iniziata, la risorsa ha risposto e la modifica richiesta è davvero arrivata. Se il log si ferma a attività iniziata, il guasto reale resta invisibile per quanto aspettiate. Poi eseguite gpresult /scope user /v per vedere quale criterio la sessione crede di avere, e confrontatelo con l'impostazione attesa. Un rapporto che elenca il GPO come applicato non dice ancora nulla su una mappatura.

Rendete il lavoro sicuro da ripetere prima di estenderlo, perché il client si riconnette e l'attività scatta di nuovo. Controllate se la mappatura o la configurazione esiste già prima di crearla, e registrate ciò che avete trovato. Il lavoro duplicato dopo ogni riconnessione transitoria è il modo in cui un'attività utile diventa un incidente.

Dove un trigger automatico non è adatto, un'azione utente approvata che esegue lo stesso script firmato è una progettazione legittima. Rende esplicito il momento invece di fingere che sia avvenuto un evento di accesso.