OneDrive e FSLogix su RDS Windows Server 2022: perché la GPO che blocca C: ferma la sincronizzazione (e come risolvere)

In una farm RDS Windows Server 2022 con FSLogix e OneDrive (Files On‑Demand + Storage Sense), l’applicazione della GPO che blocca l’accesso a C: può fermare la sincronizzazione. In questa guida spiego perché succede, come diagnosticarlo e le configurazioni consigliate per risolvere senza indebolire la sicurezza.

Indice

Scenario e sintomi

Ambiente tipico:

Tre host RDS basati su Windows Server 2022.
FSLogix 2210 (u4) con profili utente e container ODFC per OneDrive/Office.
OneDrive distribuito con Files On‑Demand.
Storage Sense per la rimozione periodica dei file locali non usati.

Finché l’unità C: è solo nascosta, tutto funziona. Quando però si applica una policy che blocca l’accesso a C: (es. “Prevent access to drives from My Computer”) OneDrive smette di sincronizzare: l’icona resta in “Inizializzazione” o “In pausa”, i file non si aggiornano, i reparse‑point non si materializzano.

Perché la GPO che blocca C: interrompe OneDrive

Sebbene i dati “pesanti” (cache Office/OneDrive, OST, ecc.) siano reindirizzati nel container ODFC, il client OneDrive continua a dipendere da percorsi posti sotto C:\ per operazioni essenziali:

Installazione ed eseguibile: OneDrive risiede in %ProgramFiles%\Microsoft OneDrive (installazione per‑machine) o in %localappdata%\Microsoft\OneDrive (installazione per‑utente).
Log e impostazioni: scrive continuamente in %localappdata%\Microsoft\OneDrive\* (log, database di stato, impostazioni).
Reparse‑points e metadati FOD: con Files On‑Demand crea oggetti (.cloud, .clouddownload, .clouddfs) e aggiorna gli attributi NTFS nella cache del profilo (che, pur contenuta nel VHDX FSLogix, viene montata nel percorso C:\Users\%username%\AppData\...).
Aggiornamenti: il servizio OneDriveUpdater e i task pianificati (OneDrive Per‑Machine Standalone Update / OneDrive Standalone Update) scaricano e sostituiscono binari e DLL, operando sotto C:.

La policy “Prevent access to drives from My Computer” (o altre regole di hardening equivalenti) nega l’accesso non di sistema a C:. L’effetto pratico è che il processo di OneDrive non riesce più a:

aprire/scrivere i propri file di stato e log;
agganciarsi ai reparse‑point;
installare aggiornamenti o far partire l’updater;
risolvere correttamente i percorsi sotto %localappdata%.

Risultato: la sincronizzazione non parte o si interrompe subito dopo il logon.

Come riconoscere (e dimostrare) il problema

Prima di correre a modificare le policy, conviene raccogliere segnali oggettivi. Ecco un giro di verifica veloce:

Stato del client: clic sull’icona di OneDrive → Impostazioni → Informazioni. Se resta su “Inizializzazione” o segnala “Impossibile accedere al percorso”, è un indizio forte.
Log locali: controlla %localappdata%\Microsoft\OneDrive\logs\. Se la cartella è irraggiungibile o vuota dopo l’errore, la policy sta impedendo le scritture.
Event Viewer:
- Applicazione (eventi da OneDrive.exe o crash di modulo);
- Applications and Services Logs → FSLogix → Apps/ODFC (errori di montaggio o reparse point falliti).
Policy effettive: verifica che sotto Configurazione utente → Modelli amministrativi → Componenti di Windows → Esplora file le voci “Nascondi le unità specificate” e “Impedisci l’accesso alle unità da Risorse del computer” non siano entrambe attive su C:.
Registro (solo a scopo diagnostico): HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer NoDrives (REG_DWORD) ← nasconde NoViewOnDrive (REG_DWORD) ← blocca Per il solo drive C: il bitmask è 4. Se NoViewOnDrive=4 è presente, stai bloccando l’accesso.

Strategie di risoluzione

In molti ambienti RDS, la mossa vincente è non bloccare C: ma nasconderla e irrobustire il controllo applicativo con AppLocker o WDAC. Se però il blocco è un requisito, serve costruire eccezioni mirate per i percorsi critici di OneDrive.

Approccio	Vantaggi	Svantaggi / Attenzioni
Usare solo “Hide these specified drives” (nascondere, non bloccare)	Gli utenti non vedono C: in Esplora File; OneDrive continua a funzionare senza eccezioni speciali.	La root C: resta raggiungibile digitando il percorso. Mitigabile con AppLocker/WDAC e permessi NTFS sui punti sensibili.
Consentire eccezioni mirate sul blocco	Proteggi quasi tutta C: e lasci libero accesso solo a: `%ProgramFiles%\Microsoft OneDrive\` `%localappdata%\Microsoft\OneDrive\` `%systemdrive%\Users\%username%\AppData\Local\Microsoft\OneDrive\*`	Richiede regole granulari (AppLocker/WDAC, ACL mirate). Test approfondito per preservare aggiornamenti e reparse‑points.
Installazione OneDrive per‑machine su volume diverso (es. D:)	Riduci l’impatto del blocco su `%ProgramFiles%`.	Anche con binari su D:, i percorsi utente sotto `C:\Users\...` restano critici. Spostare i profili su altra lettera complica FSLogix.
Evitare il blocco totale e usare AppLocker/WDAC/Defender Exploit Guard	Controllo applicazioni più fine; meno interferenze con servizi in background (come OneDriveUpdater).	Richiede messa a punto di regole e fase iniziale in Audit per evitare falsi positivi.

Implementazione dettagliata

Opzione A — Nascondere C: e controllare l’esecuzione

GPO (Utente → Modelli amministrativi → Componenti di Windows → Esplora file):
- Nascondi le unità specificate in Risorse del computer = Abilitato (C:).
- Impedisci l’accesso alle unità da Risorse del computer = Non configurato.
AppLocker (o WDAC) per impedire esecuzioni indesiderate:
- Imposta Default rules che consentano %WINDIR% e %ProgramFiles%.
- Aggiungi regole Deny per eseguibili/scritte da %USERPROFILE%\Downloads, %TEMP%, %APPDATA% (se non necessario), lasciando OneDrive e Office liberi di operare.
- Fase iniziale in Audit Only per 1–2 settimane, poi Enforced.
Defender Attack Surface Reduction (ASR) facoltativo:
- Regole che bloccano esecuzioni da email/download e macro non affidabili.

Perché funziona: agli utenti la C: non “esiste” in Explorer, ma i servizi (OneDrive incluso) possono ancora accedere ai percorsi legittimi. Il rischio di esecuzioni malevole è mitigato da AppLocker/WDAC/ASR.

Opzione B — Mantenere il blocco con eccezioni sicure

Se il blocco è richiesto da policy interne o compliance, devi prevedere eccezioni esplicite per i percorsi di OneDrive. Due strade possibili (spesso combinabili):

1) Controllo applicativo (consigliata)

AppLocker:
- Executables, Windows Installer, Scripts, Packaged apps.
- Consenti i binari firmati Microsoft e le directory di sistema (%WINDIR%, %ProgramFiles%).
- Consenti in modo esplicito %ProgramFiles%\Microsoft OneDrive\OneDrive.exe e OneDriveStandaloneUpdater.exe.
WDAC:
- Policy di base “Microsoft Signed Only” (o equivalente) con Supplemental policy per eventuali tool interni.
- Vantaggio: regole a firma (meno dipendenti dal percorso su C:).

2) Eccezioni sui percorsi

Alcune organizzazioni applicano il blocco a C: tramite strumenti di hardening/EDR che consentono allow‑list di directory. In tal caso:

C:\Program Files\Microsoft OneDrive\
C:\Users\%username%\AppData\Local\Microsoft\OneDrive\*
%localappdata%\Microsoft\OneDrive\*

Nota: la classica GPO “Impedisci l’accesso alle unità” non prevede eccezioni per percorsi; se il tuo strumento non supporta allow‑list, valuta seriamente l’Opzione A.

Opzione C — Per‑machine su D:

L’installazione per‑machine (%ProgramFiles%) riduce le copie di OneDrive e semplifica gli aggiornamenti su RDS. Spostare i binari su D: può attenuare gli effetti collaterali del blocco su C:, ma:

OneDrive continuerà ad accedere a %localappdata% (montato in C:\Users\...), quindi servono comunque eccezioni per la parte utente.
Modifiche al percorso di %ProgramFiles% o junction dalla C: non sono sempre supportate e vanno testate con attenzione, soprattutto per gli update.

Configurazione consigliata (RDS + FSLogix + OneDrive)

Una baseline che funziona bene nella maggior parte delle farm:

FSLogix:
- Profili utente in VHDX su storage robusto (I/O basso, latenza stabile).
- ODFC abilitato per spostare la cache Office/OneDrive fuori dal disco del server.
- Esclusioni/inclusioni predefinite per %localappdata% mantenute.
OneDrive:
- Modalità Files On‑Demand attiva per minimizzare i download sul server.
- Distribuzione per‑machine su RDS per avere un solo OneDrive.exe per host.
- Assicurati che OneDriveUpdater e i relativi task possano eseguire.
Storage Sense:
- Abilita la disidratazione automatica dei file OneDrive non usati (soglia coerente con il profilo di utilizzo).
GPO su C:
- Nascondi le unità specificate = Abilitato (C:).
- Impedisci l’accesso alle unità = Non configurato.
- Rimuovi “Esegui” dal menu Start, disabilita prompt di comando se necessario.
Controllo applicativo:
- AppLocker/WDAC in modalità Allow‑list (consenti solo ciò che serve), audit iniziale → enforcement.
- Regola di blocco per esecuzioni da %USERPROFILE%\Downloads e %TEMP%.

Passi operativi rapidi

Sostituisci la policy “blocca C:” con “nascondi C:”; in molti casi è sufficiente e non rompe OneDrive.
Se il blocco è obbligatorio, prepara un gruppo di eccezioni (AppLocker/WDAC o meccanismi dell’EDR) per i percorsi critici di OneDrive indicati sopra.
Verifica che il servizio OneDrive Updater e il task schedulato OneDrive Per‑Machine Standalone Update possano avviarsi.
Dopo ogni modifica, effettua un logoff/logon (o reset del container FSLogix) e verifica che la sincronizzazione riparta.

Checklist di troubleshooting

Icona OneDrive → stato coerente (nessun loop di inizializzazione).
Creazione file di prova: crea un TXT nella cartella OneDrive dell’utente e osserva se diventa “Spunta verde”.
Reparse‑points: i file online‑only mostrano l’attributo “Disponibile quando connesso”.
Log: la cartella %localappdata%\Microsoft\OneDrive\logs viene popolata al logon.
Eventi FSLogix: nessun errore di montaggio ODFC o di accesso negato su %localappdata%.

Domande frequenti

È possibile lasciare “blocca C:” e far funzionare comunque OneDrive senza eccezioni?

Nella pratica, no. Il client necessita di accedere a percorsi sotto C:\Users\... e alla propria cartella in %ProgramFiles%/%localappdata%. Senza allow‑list o senza cambiare approccio (nascondere + controllo applicativo) la sincronizzazione fallirà.

Posso spostare la cartella `%UserProfile%` fuori da C: per aggirare il blocco?

Non è consigliato in scenari FSLogix: i profili sono già virtualizzati nel VHDX e vengono montati sotto C:\Users. Cambiare lettera aggiunge complessità e non risolve i requisiti di OneDrive/ODFC.

La sola policy “Nascondi unità” è sicura?

Nascondere non è un controllo di sicurezza: serve a ridurre l’esposizione in Explorer. La sicurezza va affidata a AppLocker/WDAC, permessi NTFS e hardening a livello di processo. Questa combinazione mantiene la fruibilità senza compromettere la postura di sicurezza.

Gli aggiornamenti di OneDrive sono davvero necessari su RDS?

Sì: includono fix di compatibilità con FSLogix/ODFC, miglioramenti FOD e correzioni di sicurezza. Bloccarli spesso è la causa indiretta di errori e consumo anomalo di CPU/RAM.

Esempi di configurazione (da adattare)

Abilitare “Nascondi C:” e rimuovere “Blocca C:” via registro (solo test lab)

Usare in laboratorio o in uno script di hardening controllato. In produzione applicare GPO centralizzate.

reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoDrives /t REG_DWORD /d 4 /f
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoViewOnDrive /f

Regole AppLocker di base

Executables:
- Allow path %WINDIR%\, %ProgramFiles%\.
- Allow %ProgramFiles%\Microsoft OneDrive\OneDrive.exe e OneDriveStandaloneUpdater.exe.
- Deny path utente ad alto rischio: %USERPROFILE%\Downloads\, %TEMP%\.
Scripts/MSI: analoghe regole Allow per directory di sistema e Deny per percorsi utente.

Prestazioni e stabilità: consigli pratici

Storage dei VHDX: latenza < 5–8 ms, cache write‑back abilitata dove possibile.
Dimensionamento ODFC: sufficiente spazio nel container per reparse‑points e metadati; monitorare la crescita.
Antivirus: escludi i percorsi dei VHDX FSLogix e la cartella OneDrive in %localappdata% per evitare lock.
Patch cadence: mantieni OneDrive e FSLogix aggiornati (stessa “onda” di rilascio nel parco RDS).

Errori comuni da evitare

Abilitare sia “Nascondi unità” sia “Impedisci l’accesso” sulla stessa lettera.
Bloccare C:\Users\%username%\AppData\Local\Microsoft\OneDrive pensando che i dati siano “tutti nel VHDX”. Quel percorso è la porta verso il VHDX.
Disabilitare l’updater di OneDrive: alla lunga genera incompatibilità con FOD e corruzione dei reparse‑points.
Usare solo l’EDR per negare le scritture su C: senza un’allow‑list per OneDrive.

Appendice — Bitmask delle policy Explorer

Le due policy utente più rilevanti (Nascondi… e Impedisci l’accesso…) usano una maschera di bit per le lettere di unità. Valori comuni:

Drive	Bit	Valore
A:	2⁰	1
B:	2¹	2
C:	2²	4
D:	2³	8
E:	2⁴	16

Esempio: nascondere C: = NoDrives=4; bloccare C: = NoViewOnDrive=4. Somma i valori per più unità.

Nota finale

Nel thread originale non è stata fornita una soluzione “chiavi in mano”. È stato suggerito di ripostare la domanda su un canale di supporto specialistico (tag FSLogix e OneDrive). Le opzioni qui sopra derivano da documentazione ufficiale e buone pratiche comunemente adottate negli ambienti RDS/FSLogix.

Conclusioni

OneDrive su RDS con FSLogix funziona in modo affidabile quando non si impedisce al client di accedere ai propri percorsi su C:. La combinazione “C: nascosta + controllo applicativo + ODFC + Storage Sense” offre la migliore esperienza per gli utenti e mantiene un profilo di rischio basso. Se la tua compliance pretende il blocco di C:, prevedi un’allow‑list specifica per i binari e le cartelle di OneDrive e valida tutto in laboratorio prima di andare in produzione.

In sintesi operativa: evita la policy di blocco totale quando puoi; altrimenti, costruisci eccezioni precise, garantisci l’updater, e testa dopo ogni cambiamento con logoff/logon o reset del container FSLogix. Così OneDrive tornerà a sincronizzare senza sacrificare la sicurezza del tuo ambiente RDS.