Dove vive il profilo, e perché non può stare sul disco locale

In un host pool pooled l’utente viene indirizzato a un session host scelto dall’algoritmo di bilanciamento, quindi potenzialmente diverso a ogni accesso: un profilo salvato in locale sarebbe irraggiungibile la volta dopo. La risposta è FSLogix, che incapsula il profilo in un container VHDX ospitato su una share SMB e lo aggancia all’host al logon. Il profile container contiene l’intero profilo ed è la scelta di default; l’ODFC container isola i soli dati Office e ha senso solo in scenari specifici, tipicamente in affiancamento; la Cloud Cache scrive su più provider ed è una risposta di resilienza, non un acceleratore di prestazioni. Anche su host pool personal la share resta utile quando l’assegnazione dell’host può cambiare.

Azure Files: la scelta standard

Per la maggior parte dei deployment la share vive su Azure Files, ed è la risposta attesa quando lo scenario non chiede nulla di estremo. I criteri da pesare sono tre. Il performance tier: le share premium sono su SSD e reggono meglio i picchi di logon e logoff, quando decine di container si montano nello stesso quarto d’ora; le share standard costano meno e vanno bene per popolazioni piccole o con orari distribuiti. La ridondanza: locale, zonale o geografica, sapendo che le opzioni geo-redundant non sono disponibili su tutti i tier e che un failover geografico non è pensato per container aperti in scrittura. La distribuzione del carico: i limiti di performance si applicano allo storage account, non alla singola share, quindi con molti utenti concorrenti si spezza la popolazione su più storage account e più share invece di concentrarla su una sola. Metti lo storage account nella stessa region dei session host — la latenza cross-region si paga a ogni logon — e chiudi l’accesso pubblico usando un private endpoint via Azure Private Link.

Azure NetApp Files: quando serve di più

Azure NetApp Files è la risposta quando lo scenario parla esplicitamente di latenza più bassa, throughput superiore o di profili molto pesanti e utenti molto numerosi. Si dimensiona scegliendo il service level del capacity pool (Standard, Premium, Ultra), che determina il throughput in proporzione alla capacità allocata: si compra capacità anche per ottenere velocità. Il prezzo da pagare è architetturale — richiede una subnet delegata nella virtual network e un modello di gestione a capacity pool e volume — e in genere un costo d’ingresso più alto. Se la domanda non cita prestazioni o latenza come requisito, Azure NetApp Files è quasi sempre la risposta sovradimensionata.

I due livelli di permessi: l’errore che l’esame cerca

Perché FSLogix possa montare il container, la share deve avere l’autenticazione basata su identità, in una di tre forme: AD DS, Microsoft Entra Domain Services o Microsoft Entra Kerberos (quest’ultimo richiede identità ibride sincronizzate). Abilitata l’identità, servono due livelli di permesso distinti:

  • il ruolo RBAC sulla share (i ruoli Storage File Data SMB Share, nelle varianti Reader, Contributor ed Elevated Contributor) che stabilisce chi può montare la share e con quale livello;
  • le ACL NTFS dentro la share, che stabiliscono cosa si può fare su cartelle e file una volta montata.

Configurarne uno solo lascia l’accesso rotto in modo silenzioso: l’utente entra ma FSLogix non riesce ad agganciare il VHDX e Windows ripiega su un profilo temporaneo. È la causa numero uno dei profili temporanei e la trappola più ricorrente dell’esame.

Capacità ed esclusioni antivirus

La quota della share si stima moltiplicando il numero di utenti per la dimensione attesa del profilo, con margine per la crescita e per l’espansione dinamica dei VHDX. Infine, l’antivirus: i file dei container vanno esclusi dalla scansione real-time — le estensioni dei dischi e i percorsi dei container, seguendo la lista pubblicata da Microsoft — altrimenti ogni mount viene rallentato o bloccato, con corruzioni e logon lentissimi.

Trappole tipiche d’esame

  • Utenti con profilo temporaneo dopo aver assegnato il ruolo RBAC → mancano le ACL NTFS: il ruolo consente il mount, non l’accesso ai dati. Servono entrambi i livelli, sempre.
  • “Latenza più bassa e throughput elevato per profili di grandi dimensioni” → Azure NetApp Files: se invece lo scenario chiede solo una share condivisa a costo contenuto, la risposta è Azure Files, non NetApp.
  • “Migliorare la resilienza dei profili su più location” → Cloud Cache, non un tier più veloce: la Cloud Cache replica su più provider; il performance tier non c’entra con la resilienza.
  • Molti utenti concorrenti e logon lenti → distribuire su più storage account e share: i limiti sono a livello di storage account; alzare solo la quota della singola share non risolve la contesa.
  • Identità cloud-only e requisito “niente domain controller” → Microsoft Entra Kerberos, con il vincolo delle identità ibride: se le identità non sono sincronizzate, la strada resta AD DS o Microsoft Entra Domain Services.
  • Logon lentissimi e container corrotti dopo il rollout dell’endpoint protection → esclusioni antivirus mancanti: non è un problema di storage tier, ma di scansione real-time sui file dei container.