Bootstrap o GPO: due percorsi per un profilo VPN di Windows
Un profilo distribuito tramite GPO non può essere l’unico modo per raggiungere la condivisione che lo distribuisce. Separate la prima installazione dall’aggiornamento ordinario e versionate entrambi insieme.
Distribuite un profilo VPN da una condivisione di dominio e tutto funziona, fino al portatile che non riesce a raggiungere il dominio. A quel punto la consegna dipende proprio dalla connessione che il profilo esiste per creare. Chi tiene quel portatile è in un posto che l’help desk non vede. Trattate la prima installazione e l’aggiornamento ordinario come due percorsi separati dentro un unico pacchetto, perché falliscono in modi che non hanno nulla in comune.
La prima installazione è un problema diverso
Contano due eventi, e solo uno accade mentre la rete collabora. La tabella li separa in base a ciò che è disponibile, a ciò che avvia il lavoro e a come di solito va storto.
| First install | Routine update | |
|---|---|---|
| Network reachable | Something other than the VPN being installed | The domain or a management channel |
| Trigger | Enrollment, imaging, or a prepared package | A policy refresh or a management push |
| Usual failure | No route to the package at all | Duplicate profiles, or a change that silently does nothing |
Un artefatto revisionato può servire entrambi i percorsi; l’ipotesi sulla connettività non può essere condivisa. Uno script di avvio nasconde quell’ipotesi finché viene eseguito su una scrivania nella rete aziendale, e la espone sul campo. Lo script non è difettoso, gli si chiede semplicemente di girare dove nessuno lo ha progettato per girare.
Cosa deve contenere il pacchetto
Decidete cinque cose prima di creare il pacchetto: quale meccanismo di profilo Windows è supportato, se l’ambito è per utente o per dispositivo, quali certificati o componenti client sono prerequisiti, cosa dice la definizione del profilo e quale azione la applica. ProfileXML è il modo supportato di esprimere le impostazioni VPN, distribuito tramite il CSP VPNv2, e la guida di Microsoft alle opzioni di profilo elenca cosa può contenere. Tutto ciò che sta fuori da quell’elenco è una decisione che state prendendo sul momento.
I parametri di uno script ausiliario appartengono a quello script. Nomi come xmlFilePath o AllUserConnection sono scelte di un autore e non uno standard che ogni installer rispetta; copiarli in un altro script produce un comando che sembra giusto e non fa nulla.
Tenete script e definizione sotto un’unica versione, e verificate da dove vengono entrambi insieme ai loro permessi. Uno script di avvio privilegiato che per caso è leggibile da SYSVOL non per questo è stato revisionato, e distribuire tramite criteri non è una revisione.
Ottenere la prima connessione
La prima installazione avviene mentre il dispositivo è ancora raggiungibile in un altro modo: una rete approvata, un canale di gestione esistente o un flusso di registrazione progettato per questo. I certificati e i prerequisiti di attendibilità del metodo di autenticazione scelto appartengono a quello stesso pacchetto, perché non si può recuperare nulla attraverso un tunnel che non esiste ancora. Chiedete quale di questi tre canali è reale per questo utente prima che qualcuno prometta una data. Un canale che esiste solo sulla carta diventa una telefonata dal campo.
Scrivete che cosa fa davvero il tecnico o l’utente in quel momento. Se la risposta è che l’IT si collega da remoto per aiutare, allora il percorso di prima installazione dipende in silenzio da un secondo strumento di accesso remoto che qualcuno deve anche fornire e supportare.
Gli aggiornamenti richiedono uno stato noto
Quando la macchina raggiunge il dominio, può subentrare il normale processo di dominio o di gestione dei dispositivi. È sull’ambito che si insinuano gli errori, perché uno script di avvio gira nel contesto macchina, mentre un’azione di accesso utente e un’azione di gestione dispositivi possono differire sia per ambito sia per permessi.
Una voce di connessione per tutti gli utenti non è un tunnel di dispositivo pre-accesso, qualunque cosa suggeriscano i nomi. I tunnel di dispositivo portano requisiti propri di piattaforma, protocollo e credenziali, e leggere quei requisiti è l’unico modo per sapere se qui è possibile un tunnel pre-accesso. Un tunnel utente che parte all’accesso offre una garanzia diversa.
Rendete ripetibile il percorso di aggiornamento: trovate il profilo già gestito, mantenete le preferenze utente previste, applicate una definizione compatibile e riportate un esito chiaro. Creare un profilo nuovo a ogni aggiornamento dei criteri è il modo in cui una macchina finisce con cinque voci e un utente che sceglie quella sbagliata.
Il registro che lo rende mantenibile
Tre risposte appartengono al passaggio di consegne: come ottiene la prima connessione un dispositivo appena emesso, chi può modificare il pacchetto e come un amministratore annulla una modifica incompatibile. Con queste scritte, la distribuzione non dipende più da qualcuno che ha già l’accesso da fornire.
Archiviate quel registro accanto alla versione del pacchetto e aggiornate entrambi nello stesso cambiamento. Altrimenti la persona successiva ricostruisce il percorso di bootstrap da un ticket chiuso un anno fa.