Azure Files e Azure File Sync

AZ-802 non chiede se sai creare una share dal portale: chiede che cosa si rompe quando irrigidisci le impostazioni SMB dell’account, quante share Azure servono per tre volumi di un file server, e quale strumento preserva le ACL in migrazione. Sono domande di conseguenza, non di procedura.

Creare la share e decidere come si parla SMB

Le share SMB di Azure Files vivono in uno storage account (Microsoft.Storage): kind FileStorage per il modello provisioned (SSD o HDD), StorageV2 per il pay-as-you-go su HDD. Una singola share non puo’ essere insieme SMB e NFS. Azure File Sync lavora solo con share SMB in storage account.

Le impostazioni del protocollo si configurano sull’account, non sulla singola share. Si leggono con Get-AzStorageFileServiceProperty (un valore null significa «default in vigore», non «disabilitato») e si scrivono con Update-AzStorageFileServiceProperty:

Il profilo di default e’ quello di massima compatibilita’: restringere taglia fuori dei client. Tre conseguenze da sapere a memoria:

• togliere NTLMv2 disabilita il mount con la chiave dello storage account: e’ l’unico meccanismo che la chiave usa. Le credenziali di dominio non passano mai da NTLM;
• lasciare solo AES-256-GCM esclude tutto cio’ che precede Windows 11 / Windows Server 2022, e sui client supportati va comunque forzato con Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM";
• una sessione che non soddisfa i vincoli fallisce con STATUS_ACCESS_DENIED, non con un errore di rete.

Separata da queste c’e’ Require Encryption in Transit for SMB, impostazione per-protocollo: attiva di default sui nuovi account creati dal portale, non selezionata su quelli creati da PowerShell, CLI o REST. Quando e’ attiva, SMB 2.1 e’ escluso comunque, perche’ non sa cifrare il canale.

I due livelli di permesso, e chi vince

L’autenticazione basata su identita’ usa una sola identity source per storage account, valida per tutte le sue share: AD DS on-premises, Microsoft Entra Domain Services, oppure Microsoft Entra Kerberos. Azure Files riceve solo il ticket Kerberos, mai le credenziali. Il controllo d’accesso e’ a due piani, e vince sempre il piu’ restrittivo:

1. share-level: ruoli RBAC di Azure, assegnati sull’oggetto in Microsoft Entra ID;
2. directory e file-level: ACL di Windows (NTFS), applicate dopo aver montato la share.

Con identity source AD DS, il ruolo non si assegna all’oggetto di dominio ma alla sua identita’ ibrida sincronizzata in Entra ID con Entra Connect Sync o Cloud Sync: un gruppo che esiste solo on-premises non e’ assegnabile. Il contrario invece funziona: un utente non sincronizzato prende comunque i permessi di un gruppo sincronizzato, perche’ Azure Files legge i SID dei gruppi dal ticket Kerberos, non l’elenco dei membri nel portale. Se sincronizzare e’ impossibile, resta il default share-level permission (uno solo per account, inizializzato a None), che concede un ruolo a tutte le identita’ autenticate e lascia il lavoro fine alle ACL. Quando coesiste con un’assegnazione puntuale, vince il permesso piu’ alto.

Per scrivere le ACL serve un mount con accesso amministrativo: o il ruolo Storage File Data SMB Admin (che consente takeown quando la ACL esistente nega l’accesso), o la chiave dell’account. Monta con net use, non con PowerShell: una share montata da PowerShell non e’ visibile a File Explorer ne’ a cmd.exe. icacls e File Explorer valgono per le identita’ ibride; per le cloud-only servono il portale o il modulo RestSetAcls.

Azure File Sync: gli oggetti e i vincoli che decidono la topologia

Uno storage sync service contiene registered server e sync group; ogni sync group ha un cloud endpoint (la share Azure) e uno o piu’ server endpoint (un percorso su un server registrato, mai una share di rete). L’agente installa FileSyncSvc.exe e il filtro StorageSync.sys.

Da qui segue la risposta a un classico: piu’ volumi di un server non si consolidano in un’unica share Azure. Tre volumi significano tre share Azure e tre sync group. Piu’ share sullo stesso volume invece si consolidano: basta sincronizzare la radice del volume.

Il cloud tiering lascia in locale solo la cache, con due criteri combinabili: volume free space policy (percentuale di spazio libero da mantenere) e date policy (tiera i file non acceduti da N giorni). Non si abilita sul volume di sistema. La share Azure ha sempre la copia completa.

Monitorare: portale, metriche, event log

Le metriche arrivano ad Azure Monitor ogni 15 minuti sullo storage sync service: Sync session result, Files not syncing, Server online status, Cloud tiering low disk space mode, Cloud tiering recall size, Agent version expiration information. Il portale mostra lo stato dei registered server (Online / Appears Offline, quest’ultimo quando AzureStorageSyncMonitor.exe non gira) e la salute dei server endpoint, che non e’ calcolata in cloud: viene dal Telemetry event log del server, in Applications and Services\Microsoft\FileSync\Agent.

Una sessione che fallisce ma con AppliedItemCount che cresce sta progredendo: il server endpoint resta Healthy. Sul server ci sono anche i contatori Perfmon AFS Bytes Transferred e AFS Sync Operations.

Le due migrazioni rimaste in programma

Da DFS-R ad Azure File Sync. L’ordine e’ d’esame: sync group, agente sul server che ha il set completo dei dati, server endpoint senza cloud tiering, upload completo, agente sugli altri server DFS-R, disabilitare DFS-R, server endpoint sugli altri server (sempre senza tiering), verifica, ritiro di DFS-R, e solo alla fine si accende il cloud tiering. Se durante la transizione DFS-R deve restare acceso: cloud tiering disabilitato sui volumi con cartelle replicate, nessun server endpoint su una cartella DFS-R read-only, e un solo server endpoint sovrapposto a una location DFS-R. DFS-N invece convive senza riserve.

Da file share ad Azure Files senza File Sync. Lo strumento e’ RoboCopy, che parla SMB e copia a piena fedelta’; AzCopy sync non e’ adatto perche’ non propaga le cancellazioni. Il comando di riferimento e’ robocopy <origine> <destinazione> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<log>. S e O in /COPY sono le ACL e l’owner; U (auditing) non e’ memorizzabile in Azure Files, quindi /COPYALL non ha senso. /B richiede la console elevata e il mount con la chiave dello storage account. Si fa una prima passata lunga, una o piu’ incrementali, poi si toglie l’accesso agli utenti e si fa l’ultima: e’ quella la finestra di fermo.

Trappole tipiche d’esame

• Togliere NTLMv2 spegne la chiave dello storage account. E’ l’irrigidimento che rompe di piu’: i mount con /user:localhost\<account> smettono di funzionare, mentre Kerberos continua. Lo stesso vale per icacls, se lo stavi facendo montando con la chiave.
• Il ruolo RBAC si assegna all’oggetto Entra ID, non a quello AD DS. Con identity source AD DS serve l’identita’ ibrida sincronizzata; ma un utente non sincronizzato eredita comunque i permessi di un gruppo sincronizzato, perche’ il SID viaggia nel ticket Kerberos.
• Due volumi non entrano in una sola share Azure. Un cloud endpoint sta in un solo sync group e un sync group ammette un solo server endpoint per server registrato: N volumi da sincronizzare = N share Azure = N sync group.
• Durante la convivenza con DFS-R il cloud tiering va spento, e i server endpoint non vanno sulle cartelle replicate read-only. Accendere il tiering e’ l’ultimo passo, dopo il ritiro di DFS-R.
• RoboCopy con /B vuole la chiave, non il dominio. Con un’identita’ di dominio l’errore che ottieni non ti porta alla causa. E /MIR cancella sul target cio’ che non c’e’ sull’origine: se sbagli il livello di cartella, distruggi.
• Azure File Sync non usa SMB verso Azure. Sync e trasferimento file viaggiano su HTTPS/443; la porta 445 serve solo a chi monta la share direttamente.