Perché l’accesso tramite VPN è lento: profilo, reindirizzamento o file offline

Il portatile accede in una quarantina di secondi in ufficio e impiega minuti a casa, e nel frattempo nessuno ha cambiato criteri. Ciò che è cambiato è il percorso di rete sotto tre funzionalità che sembrano simili e si comportano diversamente. Un profilo mobile carica lo stato del registro e le cartelle del profilo, il reindirizzamento cartelle punta una cartella della shell a una condivisione server, e i file offline mantengono una cache dei dati di rete idonei. Tutte e tre possono aggiungere tempo a un accesso, e di solito solo una è responsabile.

Tre attese con tre responsabili diversi

Il profilo mobile è quello che fa seguire le impostazioni utente a una persona tra computer partecipanti, e il caricamento avviene presto nella sessione. Il ramo del registro dell’utente e le cartelle del profilo vengono copiati o uniti all’accesso, poi riscritti all’uscita. Quel lavoro è sincrono, ed è per questo che un percorso lento verso la condivisione dei profili si percepisce come un desktop lento e non come una copia di file lenta.

Il reindirizzamento cartelle è un altro meccanismo. Sposta cartelle della shell selezionate, Documenti è l’esempio comune, in una posizione di rete supportata e le lascia lì. Il profilo può quindi restare piccolo, perché i dati non sono al suo interno, e il costo si sposta al momento in cui la shell o un’applicazione tocca quella cartella.

I file offline aggiungono una cache locale più la sincronizzazione per i file di rete idonei. Rispondono a un’altra domanda, cioè cosa succede quando il server non è raggiungibile, e possono spendere tempo a sincronizzare all’accesso e all’uscita quando la cache è obsoleta. È trattare le tre come un’unica impostazione che produce criteri lenti in una direzione e inutili nell’altra.

Misurate quale sta davvero aspettando

Iniziate leggendo dove vive il profilo e se viene caricato da un percorso server. Poi misurate il tempo di un elenco di directory su ogni condivisione toccata dalla sessione, perché una condivisione che risponde in millisecondi sulla rete locale può impiegare secondi attraverso un tunnel e un file server occupato.

Questi due fatti restringono il problema più in fretta di qualsiasi audit dei criteri, e non richiedono alcuna modifica di configurazione per essere raccolti. Eseguiteli sul portatile interessato, non su un server che sta accanto alla condivisione.

Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }

Se il percorso del profilo è locale e solo una cartella reindirizzata punta a un server, il caricamento del profilo non è la vostra attesa, qualunque cosa dica il ticket di assistenza. Se il percorso del profilo è remoto e l’elenco impiega secondi, l’accesso attende quella condivisione, e la correzione riguarda il percorso o la dimensione del profilo e non il desktop stesso. Leggete i numeri in quest’ordine e la discussione di solito finisce lì.

La connessione arriva dopo l’inizio dell’attesa

Un tunnel utente che parte dal desktop compare molto dopo che il profilo è stato caricato, quindi non può aiutare la fase che era lenta. Windows nota il percorso non disponibile, torna a credenziali memorizzate nella cache e a un profilo locale, e la sessione alla fine si apre. Per questo lo stesso portatile può impiegare minuti al primo accesso a casa e secondi al secondo, una volta che esista un profilo nella cache. L’attesa è reale, ma la connessione che le serve non esiste in quel momento.

Correggerlo significa spostare la connessione prima, non regolare il profilo. Un tunnel macchina o una connessione prima dell’accesso con autenticazione del computer stabilisce il percorso prima che l’utente acceda, e richiede un proprio ciclo di vita del certificato e proprie regole del firewall. Le credenziali memorizzate nella cache sono l’altra metà del progetto, e funzionano solo per gli account che hanno già effettuato l’accesso.

Provate la sequenza e non i componenti. Disconnettetevi del tutto, avviate il tunnel come farebbe un utente remoto e misurate l’accesso dalla richiesta di credenziali a un desktop utilizzabile.

Tenete i documenti fuori dal profilo

La condivisione dei profili è il posto sbagliato per grandi raccolte di documenti, e la guida di distribuzione dei profili mobili di Microsoft tiene per questo motivo separati l’archiviazione dei profili e le condivisioni delle cartelle reindirizzate. Un profilo che porta una cartella Documenti di diversi gigabyte sarà lento a ogni accesso e uscita, e la dimensione cresce in silenzio finché qualcuno non la misura.

Reindirizzate le cartelle che contengono dati, e lasciate che il profilo contenga impostazioni. Escludete le cache che possono essere ricostruite, come quelle dei browser e i dati temporanei delle applicazioni, perché trasferirle aggiunge tempo e non cambia nulla che l’utente veda. Tenete i dati della casella di posta e gli altri archivi delle applicazioni nella posizione supportata dall’applicazione, e non su un percorso mobile.

Non rendete la condivisione dei profili disponibile offline. I file offline appartengono alle condivisioni di dati idonee, e un ramo del profilo nella cache che si sincronizza in entrambe le direzioni è un rapporto di corruzione in attesa di accadere.

Verificate tutti e quattro gli scenari prima di dichiararlo risolto

Un accesso veloce in ufficio dimostra molto poco. Il progetto deve sopravvivere all’accesso dall’ufficio, al lavoro da casa attraverso il tunnel, al lavoro senza connessione e al ritorno in ufficio, perché è nel quarto caso che compaiono i conflitti di sincronizzazione. Misurate gli stessi quattro con un account controllato e le applicazioni reali, e annotate i numeri.

Raccogliete il registro del servizio profili e l’insieme di criteri risultante dalla sessione interessata, non dalla vostra stazione di lavoro amministrativa.

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }

Confrontate quei tempi con la linea di base dell’ufficio e con la dimensione di ciò che viene trasferito. Un accesso che impiega ancora un minuto con un profilo piccolo e una condivisione veloce non è un problema di profilo, e il prossimo posto da guardare è l’elaborazione dei Criteri di gruppo o uno script di accesso che attende la rete. Se il divario è lì, il profilo non è mai stato il problema. Confermate che il lavoro non sincronizzato sia conservato prima di cambiare criteri delle cartelle o svuotare una cache, poiché la sincronizzazione e un backup recuperabile sono garanzie diverse.