Risolvere sistematicamente gli errori Sophos Device Encryption
Sophos Central orchestra BitLocker e FileVault, ma la cifratura effettiva rimane compito del sistema operativo. Una Policy correttamente assegnata può quindi fallire a causa di TPM, firmware, WMI di Windows, Group Policy, sessione utente o gestione dei Recovery Key. Attivare e disattivare ripetutamente la Policy tende a nascondere lo stato invece di ripararlo.
La diagnosi parte dall’Alert in Central e termina con il codice di errore locale. Su Windows, il Log Sophos più importante è:
C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log
Vengono inoltre controllati manage-bde -status, Windows Application Event Log, stato TPM e BitLocker GPO effettive. Su macOS si analizzano insieme stato di FileVault, utente, Secure Token e Recovery Key.
Distinguere prima lo stato
| Indicazione o errore | Significato effettivo | Verifica successiva |
|---|---|---|
Pending | Policy attiva, cifratura in attesa o in corso | prompt utente, sessione locale, GPO, TPM |
Suspended | volume cifrato, Protector temporaneamente sospeso | Update, riavvii, amministratore locale, manage-bde |
Recovery key is missing | Central non possiede una Key valida | comunicazione, gestione Key locale, modifica utente |
Device is not encrypted | almeno un volume previsto non è cifrato | Policy, volumi supportati, codice errore locale |
| Il servizio non si avvia | componente Agent danneggiato o incompatibile | Event Log e Log del componente |
Prima della riparazione documentare dispositivo, utente, Policy, orario, volume, codice errore e percorso Recovery disponibile. Un sistema produttivo non viene decifrato finché lo stato del Recovery Key esistente non è chiaro.
Usare Endpoint Self Help nell’ordine corretto
In About > Endpoint Self Help > Device Encryption, risolvere prima gli avvisi in Services e Management Communication. Senza servizio Device Encryption attivo e comunicazione MCS corrente, i risultati successivi non sono affidabili; un riavvio non ripara un servizio o percorso mancante.
Controllare poi installazione, BitLocker Error, timestamp della policy e volumi. ESH mostra per volume avanzamento, blocco, protector ed errori; confrontarli con policy effettiva e Last Active in Central.
I conflitti frequenti derivano da GPO per tipo di cifratura, protector, TPM, FIPS o backup del Recovery Key in Active Directory. Stabilire la fonte di ogni opzione prima di cambiare Sophos o Windows.
BitLocker è Suspended
Suspended non significa decifrato. L’unità resta cifrata, ma all’avvio non richiede temporaneamente TPM-PIN o password. Gli Update Windows o firmware possono sospendere BitLocker automaticamente per un determinato numero di riavvii e poi riattivarlo. Sophos Central segnala questo stato, ma non annulla in generale una sospensione impostata intenzionalmente.
Lo stato locale indica se rimangono riavvii non protetti:
manage-bde -status
Quando l’Update è terminato o BitLocker è stato sospeso da un amministratore, il Protector viene riattivato in modo controllato:
manage-bde -protectors -enable C:
Seguono riavvio, sincronizzazione Central e nuovo controllo dello stato. Una sospensione senza un Change spiegabile viene trattata come evento di sicurezza.
TPM-only fallisce con 0x80310048
L’errore FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED significa che Windows non supporta il Protector TPM-only a causa del firmware o del BIOS. La Sophos Policy non ne è la causa. Aggiornare prima BIOS o UEFI e firmware TPM secondo le indicazioni del produttore.
Se l’hardware non consente un funzionamento TPM adatto, una Policy scelta consapevolmente può ripiegare su una modalità password senza TPM Protector. Si tratta di una decisione di sicurezza, non di un Workaround silenzioso. Controllare i Recovery Key esistenti prima delle modifiche.
Un altro caso TPM-only richiede solo il riavvio corretto: se CDE ha preparato l’hardware test, la cifratura parte dopo Restart now nel prompt Sophos. Spegnimento e avvio a freddo successivo non sempre completano lo stesso flusso.
Un dispositivo DMA blocca BitLocker
Se Windows segnala un dispositivo DMA non protetto da accesso esterno, il blocco proviene da Windows DMA Security, non da Sophos. Identificare dispositivo o bus in Event Viewer e confermarne lo scopo con il produttore.
Su Windows 10 e Windows 11 fino a 24H1, il bus confermato può essere inserito in HKLM\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses. Windows 11 24H2 e successivi ignorano la allowlist: correggere firmware, driver o compatibilità. Non autorizzare ampiamente bus sconosciuti.
InvalidNamespace 0x8004100E
Se CDE.log segnala informazioni Volume mancanti per ManagementStatus.InvalidNamespace e anche manage-bde -status restituisce 0x80041002, spesso la classe WMI Win32_EncryptableVolume è registrata in modo errato.
In un Prompt dei comandi amministrativo, registrare nuovamente il file MOF Microsoft:
mofcomp.exe C:\Windows\System32\wbem\win32_encryptablevolume.mof
manage-bde.exe -status
Solo quando il secondo comando restituisce nuovamente dati Volume validi, riavviare il dispositivo ed eseguire di nuovo il prompt PIN.
Un Tablet o Slate non accetta il Pre-Boot Protector
Sui dispositivi riconosciuti come Slate, Windows blocca un Protector con input da tastiera se manca la BitLocker Policy appropriata. Un errore tipico durante la creazione del Recovery Protector è 0x803100B6.
In Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives, attivare Enable use of BitLocker authentication requiring preboot keyboard input on slates. Eseguire quindi gpupdate /force o attendere il normale aggiornamento GPO.
Nessun prompt UI tramite RDP o Hyper-V Enhanced Session
La riga No UI user session available in CDE.log spesso non indica un errore del servizio. Sophos mostra intenzionalmente la finestra BitLocker solo in una sessione Windows interattiva locale. Un accesso Network-Type tramite RDP o Hyper-V Enhanced Session non deve attivare la cifratura e creare poi uno stato Pre-Boot non utilizzabile.
L’utente interessato accede quindi alla console locale e completa lì la configurazione di PIN, password o Protector. Solo dopo torna a usare l’accesso Remote.
Un supporto avviabile impedisce l’avvio
Un CD/DVD avviabile inserito o una ISO avviabile montata in una VM può bloccare l’hardware test BitLocker. Se torna allo stato iniziale dopo il riavvio, rimuovere il supporto, verificare l’ordine di boot e ripetere il prompt Sophos alla console locale.
Servizio Device Encryption con BadImageFormatException
Se, secondo Application Event Log, Sophos.Encryption.BitLockerService.exe termina con System.BadImageFormatException, il file log4net.dll nella directory Sophos Data Protection può essere danneggiato. La KBA Sophos ufficiale utilizza la copia integra dalla cache AutoUpdate.
Dopo aver salvato i Log e verificato che l’errore corrisponda esattamente, sostituire il file danneggiato in
C:\Program Files (x86)\Sophos\Sophos Data Protection\
con log4net.dll da
C:\ProgramData\Sophos\AutoUpdate\Cache\decoded\enc\ProgramFilesFolder\Sophos\Sophos Data Protection\
Dopo il riavvio, Sophos Device Encryption Service deve essere nuovamente in esecuzione. Se il file nella cache manca o l’errore è diverso, non improvvisare questa riparazione ma utilizzare SDU e Sophos Support.
Il Recovery Key FileVault manca o non funziona
Su un Mac già gestito, un utente può generare localmente un nuovo FileVault Key personale. Se l’Agent Sophos non riesce a validarlo, Central elimina dal database la Key ormai non valida. La nuova Key deve quindi essere recuperata dall’utente o dal sistema di gestione che l’ha effettivamente acquisita.
Anche un’associazione successiva dell’utente locale ad Apple ID o iCloud può modificare la gestione del FileVault Key. Un FileVault funzionante localmente non dimostra quindi che Central disponga di un Recovery Key aggiornato. Controllare insieme utente, Secure Token, Volume Owner, MDM Escrow e orario della Key in Central.
Se un Mac associato ad AD usa solo un account di rete, questo non può avviare direttamente la cifratura. Accedere una volta per creare l’account mobile locale e farlo autorizzare da un amministratore con Secure Token. Poi l’utente attiva FileVault e l’agente Sophos deposita la chiave.
BitLocker non parte dopo la conversione MBR-GPT
Dopo la conversione di Windows 10 con TPM 2.0 da MBR/Legacy BIOS a GPT/UEFI, i riferimenti di recupero in Boot Configuration Data possono non corrispondere. Device Encryption resta in attesa benché disco e TPM sembrino pronti.
Salvare Recovery Key, BCD e reagentc /info. Eseguire reagentc /disable e reagentc /enable, verificare la nuova posizione e riavviare. Non proseguire se Windows RE non si abilita o la chiave non è protetta. Dopo il riavvio, controllare nuovamente CDE.log e reagentc /info prima di lasciare proseguire la cifratura.
Aumentare il logging Device Encryption
CDE.log e il trace si configurano da FATAL a TRACE con le chiavi di registro documentate a 32 o 64 bit. Il percorso deve corrispondere all’architettura dell’agente, quindi si riavvia il servizio.
Attivare DEBUG o TRACE solo per un breve periodo riproducibile: i log contengono utente, volume e policy e crescono rapidamente. Ripristinare il livello e trasferire i file come dati sensibili.
Quando effettuare l’escalation?
Aprire un caso di Support se la disponibilità del Recovery Key non è chiara, la riparazione non corrisponde esattamente all’errore Sophos o lo stato del servizio e della cifratura resta contraddittorio dopo il riavvio. Il pacchetto contiene CDE.log, SDU, manage-bde -status, BitLocker GPO effettive, Central Event, orario preciso e passaggi già eseguiti.
Le basi della piattaforma sono illustrate in Gestire BitLocker con Sophos Central e Gestire FileVault con Sophos Central.