FSLogix in pratica

Perché serve FSLogix

In un host pool pooled la sessione atterra su un session host scelto dall’algoritmo di bilanciamento (breadth-first o depth-first): l’utente oggi lavora sull’host 3, domani sull’host 7. Un profilo salvato sul disco locale, in quello scenario, semplicemente non lo segue. Le soluzioni storiche di roaming copiavano i file all’accesso e alla disconnessione, con logon lentissimi e continui danni ai dati di Outlook e all’indice di ricerca.

FSLogix cambia approccio: il profilo diventa un disco VHDX su una share SMB, montato all’accesso e smontato alla disconnessione. Non si copia nulla, si aggancia un volume — il logon resta rapido a prescindere dalla dimensione del profilo, e l’esperienza è indistinguibile da un profilo locale. Su host pool personal l’host è dedicato, quindi il container non serve per il roaming: si adotta semmai per gestire il ciclo di vita del profilo in modo centralizzato.

Profile container e ODFC container

Il profile container contiene l’intero profilo utente ed è la scelta di default: un container solo, una share da dimensionare, una superficie di guasto sola. L’ODFC container ospita esclusivamente i dati delle applicazioni Microsoft 365 (cache di Outlook, ricerca, cache dei token), e le componenti da includere si selezionano.

Il criterio è quello del ciclo di vita: si aggiunge l’ODFC quando i dati di Office vanno trattati con criteri diversi dal resto — quota, backup, retention, o storage con caratteristiche differenti. Se non esiste questa esigenza, il secondo container aggiunge complessità senza beneficio: due dischi da montare, due share da monitorare, il doppio delle occasioni di rottura.

Sullo storage vale una regola sola: la latenza pesa più della banda, quindi la share sta accanto ai session host. Su Azure Files l’accesso richiede due livelli di autorizzazione — il ruolo RBAC sulla share e le ACL NTFS al suo interno — con autenticazione basata su identità via AD DS, Microsoft Entra Domain Services o Microsoft Entra Kerberos.

Cloud Cache: resilienza, non prestazioni

La Cloud Cache mantiene copie del container su più provider di storage e tiene una cache locale sul session host. Il suo scopo è sopravvivere alla perdita di una share o di una regione: se un provider diventa irraggiungibile, la sessione continua sugli altri.

Questo è il punto che l’esame usa più spesso per confondere. La Cloud Cache non è un’ottimizzazione di prestazioni: scrivendo verso più destinazioni amplifica l’I/O, consuma disco locale e aggiunge complessità operativa. Se il requisito parla di logon lenti o di applicazioni che rispondono male, la risposta è uno storage più veloce o più vicino, non la Cloud Cache. Se il requisito parla di continuità del servizio davanti a un guasto di storage, allora è la risposta giusta.

Application masking e guasti tipici

L’application masking nasconde applicazioni, file, cartelle e chiavi di registro a chi non deve vederle, tramite rule set assegnati a utenti o gruppi. Serve popolazioni diverse dalla stessa immagine: un solo golden image, meno host pool da mantenere, e il rispetto dei vincoli di licenza sulle applicazioni che non tutti possono usare. Va distinto da App attach, che distribuisce dinamicamente le applicazioni a runtime, e da App Control for Business, che è un controllo di sicurezza sull’esecuzione.

I guasti ricorrenti sono pochi e sempre gli stessi. Il profilo temporaneo indica quasi sempre che il container non è stato montato: share irraggiungibile, risoluzione dei nomi, o permessi incompleti su uno dei due livelli. Il container già in uso segnala un lock ancora attivo da una sessione precedente o un accesso concorrente non previsto dalla configurazione. Le esclusioni antivirus mancanti sui file VHD/VHDX producono lentezza diffusa e rischio di corruzione. Lo spazio esaurito sulla share degrada le sessioni in modo poco leggibile: l’occupazione e il tasso di crescita vanno monitorati prima che diventino un incidente.

Trappole tipiche d’esame

• Il profilo deve restare disponibile anche se una share o una regione cade → Cloud Cache: è una scelta di resilienza. Se invece lo scenario lamenta lentezza, la risposta corretta è uno storage più performante o più vicino, mai la Cloud Cache.
• Dopo l’abilitazione di FSLogix gli utenti ricevono un profilo temporaneo → verifica entrambi i livelli di permessi: su Azure Files servono sia il ruolo RBAC sulla share sia le ACL NTFS al suo interno. Averne solo uno è l’errore che l’esame verifica più volentieri.
• Reparti con applicazioni diverse devono condividere una sola immagine → application masking: i rule set nascondono ciò che non compete a quel gruppo. Costruire un secondo host pool o una seconda immagine è la risposta sbagliata ma plausibile.
• Solo i dati di Outlook devono avere quota e backup separati → ODFC container: in aggiunta al profile container, che continua a ospitare tutto il resto. L’ODFC da solo non sostituisce il profilo.
• Le sessioni sono lente ma lo storage non è saturo → esclusioni antivirus sui VHD/VHDX: la scansione in tempo reale del container è una causa classica, spesso mascherata da “problema di rete”.
• Host pool personal e roaming del profilo → il container non è obbligatorio: l’utente torna sempre sul proprio session host. FSLogix qui è una scelta di gestione, non un requisito tecnico come nel pooled.