Sophos Device Encryption Fehler systematisch beheben
Sophos Central orchestriert BitLocker und FileVault, die eigentliche Verschlüsselung bleibt jedoch Aufgabe des Betriebssystems. Deshalb kann eine korrekt zugewiesene Policy an TPM, Firmware, Windows-WMI, Gruppenrichtlinien, Benutzersitzung oder Recovery-Key-Verwaltung scheitern. Ein wiederholtes Ein- und Ausschalten der Policy verdeckt den Zustand eher, als dass es ihn repariert.
Die Diagnose beginnt mit dem Central-Alert und endet beim lokalen Fehlercode. Unter Windows ist das wichtigste Sophos-Protokoll:
C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log
Zusätzlich werden manage-bde -status, Windows Application Event Log, TPM-Status und wirksame BitLocker-GPOs geprüft. Auf macOS werden FileVault-, Benutzer-, Secure-Token- und Recovery-Key-Zustand gemeinsam betrachtet.
Erst den Zustand unterscheiden
| Anzeige oder Fehler | Tatsächliche Bedeutung | Nächster Prüfpunkt |
|---|---|---|
Pending | Policy aktiv, Verschlüsselung wartet oder läuft | Benutzer-Prompt, lokale Sitzung, GPO, TPM |
Suspended | Volume ist verschlüsselt, Protector derzeit ausgesetzt | Update, Neustarts, lokaler Admin, manage-bde |
Recovery key is missing | Central besitzt keinen gültigen Key | Kommunikation, lokale Key-Verwaltung, Benutzeränderung |
Device is not encrypted | mindestens ein erwartetes Volume ist unverschlüsselt | Policy, unterstützte Volumes, lokaler Fehlercode |
| Service startet nicht | Agentkomponente beschädigt oder inkompatibel | Event Log und Komponentenlog |
Vor einer Reparatur werden Gerät, Benutzer, Policy, Zeitpunkt, Volume, Fehlercode und aktueller Recovery-Weg dokumentiert. Ein produktives System wird nicht entschlüsselt, solange der vorhandene Recovery-Key-Zustand ungeklärt ist.
Endpoint Self Help in der richtigen Reihenfolge nutzen
Unter About > Endpoint Self Help > Device Encryption werden zuerst Warnungen in Services und Management Communication behoben. Ohne installierte Encryption-Komponente oder aktuelle Central-Policy kann die nachfolgende BitLocker-Diagnose kein gültiges Ergebnis liefern.
Danach werden Installation, BitLocker Error, Policy-Zeitstempel und Volumes geprüft. ESH zeigt pro Volume Verschlüsselungsstand, Lock-Status, Volume ID und aktive Protectors. Numerical password bezeichnet dabei den Recovery Key. Nach jeder kontrollierten Änderung wartet man mindestens 30 Sekunden, wählt Refresh und prüft den neuen Zeitstempel.
Häufige Konflikte entstehen durch GPOs für Verschlüsselungstyp, erlaubte Protectors, TPM-Anforderungen, FIPS oder Recovery-Key-Backup nach Active Directory. Die Central-Policy wird entweder bewusst an die Unternehmens-GPO angepasst oder die GPO an ihrer verwalteten Quelle korrigiert. Alle BitLocker-GPOs lokal auf Not configured zu setzen ist höchstens ein isolierter Diagnosetest, keine Produktionslösung.
BitLocker ist Suspended
Suspended bedeutet nicht entschlüsselt. Das Laufwerk ist weiterhin verschlüsselt, verlangt beim Start aber vorübergehend keinen TPM-PIN oder kein Kennwort. Windows- oder Firmware-Updates können BitLocker für eine bestimmte Zahl von Neustarts automatisch aussetzen und danach wieder aktivieren. Sophos Central meldet diesen Zustand, hebt eine absichtlich gesetzte Suspension jedoch nicht generell selbst auf.
Der lokale Status zeigt, ob noch ungeschützte Neustarts ausstehen:
manage-bde -status
Ist das Update abgeschlossen oder wurde BitLocker durch einen Administrator ausgesetzt, wird der Protector kontrolliert reaktiviert:
manage-bde -protectors -enable C:
Danach folgen Neustart, Central-Synchronisation und erneute Statuskontrolle. Eine Suspension ohne erklärbaren Change wird als Sicherheitsereignis untersucht.
TPM-only scheitert mit 0x80310048
Der Fehler FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED bedeutet, dass Windows den TPM-only-Protector wegen Firmware oder BIOS nicht unterstützt. Die Sophos-Policy ist dabei nicht die Ursache. Zuerst werden BIOS beziehungsweise UEFI und TPM-Firmware nach Herstellerangaben aktualisiert.
Falls die Hardware keinen geeigneten TPM-Betrieb erlaubt, kann eine bewusst gewählte Policy ohne TPM-Protector auf einen Kennwortmodus zurückfallen. Das ist eine Sicherheitsentscheidung und kein stiller Workaround. Bestehende Recovery Keys werden vor Änderungen geprüft.
Ein anderer TPM-only-Fall benötigt schlicht den richtigen Neustart: Hat CDE den Hardwaretest vorbereitet, startet die Verschlüsselung erst nach Restart. Herunterfahren und erneutes Einschalten sowie Sleep genügen dafür nicht. Vor tieferen TPM-Eingriffen wird deshalb ein echter Windows-Neustart ausgeführt und anschliessend CDE.log erneut geprüft.
DMA-fähiges Gerät blockiert BitLocker
Meldet Windows, dass BitLocker wegen eines nicht gegen externen Zugriff geschützten DMA-fähigen Geräts nicht aktiviert werden kann, stammt die Blockierung aus der Windows-DMA-Sicherheitsbewertung. Gerätehersteller beziehungsweise IHV müssen bestätigen, ob der gemeldete Bus nur intern erreichbar und damit sicher ist.
Unter Windows 10 und Windows 11 bis 24H1 kann der Hersteller-Bus nach dieser Bestätigung unter HKLM\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses mit exakter PCI Vendor- und Device-ID zugelassen werden. Der Schlüssel ist geschützt; Eigentums- und ACL-Änderungen werden gesichert und nur für den bestätigten Bus vorgenommen. Ab Windows 11 24H2 ignoriert Windows diesen Schlüssel, daher ist dort ein Registry-Workaround wirkungslos und ein Firmware-, Treiber- oder Hardwarefix erforderlich.
InvalidNamespace 0x8004100E
Meldet CDE.log, dass Volume-Informationen wegen ManagementStatus.InvalidNamespace fehlen, und liefert auch manage-bde -status den Fehler 0x80041002, ist häufig die WMI-Klasse Win32_EncryptableVolume fehlerhaft registriert.
In einer administrativen Eingabeaufforderung wird die Microsoft-MOF-Datei neu registriert:
mofcomp.exe C:\Windows\System32\wbem\win32_encryptablevolume.mof
manage-bde.exe -status
Erst wenn der zweite Befehl wieder gültige Volume-Daten liefert, wird das Gerät neu gestartet und der PIN-Prompt erneut ausgeführt.
Tablet oder Slate akzeptiert keinen Pre-Boot-Protector
Windows blockiert auf als Slate erkannten Geräten einen Protector mit Tastatureingabe, wenn die passende BitLocker-Richtlinie fehlt. Typisch ist 0x803100B6 beim Erstellen des Recovery-Protectors.
Unter Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives wird Enable use of BitLocker authentication requiring preboot keyboard input on slates aktiviert. Danach folgt gpupdate /force oder die normale GPO-Aktualisierung.
Kein UI-Prompt über RDP oder Hyper-V Enhanced Session
Die Zeile No UI user session available in CDE.log bedeutet häufig keinen Dienstfehler. Sophos zeigt den BitLocker-Dialog absichtlich nur in einer lokalen interaktiven Windows-Sitzung. Eine Network-Type-Anmeldung über RDP oder Hyper-V Enhanced Session darf die Verschlüsselung nicht aktivieren und danach einen nicht bedienbaren Pre-Boot-Zustand hinterlassen.
Der betroffene Benutzer meldet sich daher an der lokalen Konsole an und schliesst dort PIN-, Passwort- oder Protector-Setup ab. Erst danach wird Remote-Betrieb wieder verwendet.
Bootmedium verhindert den Start
Ein eingelegtes bootfähiges CD-/DVD-Medium oder ein in einer VM gemountetes bootfähiges ISO kann den BitLocker-Hardwaretest blockieren. Bei der generischen Meldung BitLocker could not be enabled werden solche Medien entfernt beziehungsweise ausgehängt und das Gerät neu gestartet. Nicht bootfähige Datenträger werden nicht pauschal als Ursache angenommen.
Device-Encryption-Service mit BadImageFormatException
Beendet sich Sophos.Encryption.BitLockerService.exe laut Application Event Log mit System.BadImageFormatException, kann log4net.dll im Sophos-Data-Protection-Verzeichnis beschädigt sein. Das offizielle Sophos-KBA verwendet die intakte Kopie aus dem AutoUpdate-Cache.
Nach Sicherung von Logs und Prüfung des exakt passenden Fehlerbilds wird die beschädigte Datei in
C:\Program Files (x86)\Sophos\Sophos Data Protection\
durch log4net.dll aus
C:\ProgramData\Sophos\AutoUpdate\Cache\decoded\enc\ProgramFilesFolder\Sophos\Sophos Data Protection\
ersetzt. Nach dem Neustart muss der Sophos Device Encryption Service wieder laufen. Fehlt die Cache-Datei oder weicht der Fehler ab, wird diese Reparatur nicht improvisiert, sondern SDU und Sophos Support verwendet.
FileVault-Recovery-Key fehlt oder funktioniert nicht
Auf einem bereits verwalteten Mac kann ein Benutzer lokal einen neuen persönlichen FileVault-Key erzeugen. Kann der Sophos-Agent diesen Key nicht validieren, entfernt Central den inzwischen ungültigen Key aus seiner Datenbank. Der neue Schlüssel muss dann vom Benutzer beziehungsweise aus der tatsächlich übernehmenden Verwaltung beschafft werden.
Auch eine spätere Bindung des lokalen Benutzers an Apple ID beziehungsweise iCloud kann die FileVault-Key-Verwaltung verändern. Ein lokal funktionierendes FileVault beweist daher nicht, dass Central einen aktuellen Recovery Key besitzt. Benutzer, Secure Token, Volume Owner, MDM-Escrow und Central-Key-Zeitpunkt werden gemeinsam geprüft.
Verwendet ein AD-gebundener Mac nur einen Netzwerkaccount, kann dieser die Verschlüsselung nicht direkt starten. Man meldet sich mit dem Netzwerkkonto an, erstellt unter System Settings > Users & Groups den angebotenen Mobile account, meldet sich danach mit diesem mobilen Konto an und bestätigt beim Sophos-Dialog Create key mit dem AD-Kennwort. Anschliessend wird in Central geprüft, ob der Recovery Key tatsächlich eingegangen ist. Die sichtbaren macOS-Bezeichnungen können sich je nach Version ändern.
Nach MBR-zu-GPT-Konvertierung startet BitLocker nicht
Wird ein Windows-10-System mit TPM 2.0 von MBR/Legacy BIOS auf GPT/UEFI konvertiert, können die in der Boot Configuration Data gespeicherten GUIDs der Windows Recovery Environment ungültig werden. Das zeigt sich dadurch, dass weder Central noch PowerShell einen TPM-Protector erfolgreich setzen können.
Vor einer Reparatur werden Recovery Key, BCD und aktueller reagentc /info-Status gesichert. Danach wird Windows RE mit reagentc /disable deaktiviert, die veraltete ReAgent-Konfiguration gemäss aktuellem Microsoft-/Sophos-Runbook neu erzeugt und Windows RE mit reagentc /enable wieder registriert. Erst wenn reagentc /info auf die richtige Recovery-Partition zeigt, wird der BitLocker-Protector erneut getestet. Partitionen oder BCD-Einträge werden nicht ohne Systembackup verändert.
Device-Encryption-Logging erhöhen
CDE.log und die Trace-Datei lassen sich über die dokumentierten 32- beziehungsweise 64-Bit-Registry-Schlüssel von FATAL bis TRACE konfigurieren. Die Änderung greift sofort und benötigt keinen Neustart. Zusätzlich können Rollgrösse und Anzahl aufbewahrter Dateien gesetzt werden.
DEBUG oder TRACE wird nur für ein enges reproduzierbares Zeitfenster aktiviert, weil Logs Benutzer-, Volume- und Policyinformationen enthalten und schnell wachsen können. Vorher werden die Standardwerte exportiert. Nach der Reproduktion wird das Loglevel zurückgesetzt und das relevante Archiv zusammen mit Zeit und Fehlercode gesichert.
Wann eskalieren?
Ein Supportfall wird eröffnet, wenn Recovery-Key-Verfügbarkeit ungeklärt ist, die Reparatur nicht exakt zum Sophos-Fehlerbild passt oder Service und Verschlüsselungsstatus nach Neustart weiterhin widersprüchlich sind. Das Paket enthält CDE.log, SDU, manage-bde -status, wirksame BitLocker-GPOs, Central-Event, genaue Zeit und bereits durchgeführte Schritte.
Die Plattformgrundlagen erklären BitLocker mit Sophos Central verwalten und FileVault mit Sophos Central verwalten.