Resolver erros do Sophos Device Encryption
O Sophos Central orquestra BitLocker e FileVault, mas a encriptação propriamente dita continua a ser realizada pelo sistema operativo. Por isso, uma Policy corretamente atribuída pode falhar devido a TPM, Firmware, Windows WMI, Group Policies, sessão do utilizador ou gestão do Recovery Key. Ativar e desativar repetidamente a Policy tende a ocultar o estado em vez de o reparar.
O diagnóstico começa no Central Alert e termina no código de erro local. No Windows, o principal Log da Sophos é:
C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log
Também se verificam manage-bde -status, Windows Application Event Log, estado do TPM e BitLocker GPOs efetivas. No macOS, são analisados em conjunto os estados de FileVault, utilizador, Secure Token e Recovery Key.
Distinguir primeiro o estado
| Indicação ou erro | Significado real | Verificação seguinte |
|---|---|---|
Pending | Policy ativa; encriptação aguarda ou está em curso | User Prompt, sessão local, GPO, TPM |
Suspended | Volume encriptado, Protector temporariamente suspenso | Update, reinícios, Local Admin, manage-bde |
Recovery key is missing | Central não possui um Key válido | comunicação, gestão local do Key, alteração do utilizador |
Device is not encrypted | pelo menos um Volume esperado não está encriptado | Policy, Volumes suportados, código de erro local |
| serviço não inicia | componente do agente danificado ou incompatível | Event Log e Component Log |
Antes da reparação, documentam-se dispositivo, utilizador, Policy, hora, Volume, código de erro e Recovery Path atual. Um sistema de produção não é desencriptado enquanto o estado do Recovery Key existente não estiver esclarecido.
Usar Endpoint Self Help pela ordem correta
Em About > Endpoint Self Help > Device Encryption, resolva primeiro os avisos em Services e Management Communication. Sem serviço Device Encryption ativo e comunicação MCS atual, os resultados seguintes não são fiáveis; reiniciar não repara um serviço ou caminho ausente.
Depois, verifique instalação, BitLocker Error, timestamp da Policy e volumes. O ESH mostra progresso, bloqueio, protector e erros por volume; compare-os com a Policy efetiva e Last Active no Central.
Conflitos frequentes vêm de GPO para tipo de encriptação, protectors, TPM, FIPS ou backup do Recovery Key no Active Directory. Determine a origem de cada opção antes de alterar Sophos ou Windows.
BitLocker está Suspended
Suspended não significa desencriptado. A unidade continua encriptada, mas temporariamente não exige TPM PIN nem palavra-passe no arranque. Windows Updates ou Firmware Updates podem suspender automaticamente BitLocker durante um determinado número de reinícios e reativá-lo depois. Sophos Central comunica este estado, mas não termina genericamente uma suspensão definida intencionalmente.
O estado local mostra se ainda existem reinícios desprotegidos pendentes:
manage-bde -status
Se a atualização estiver concluída ou BitLocker tiver sido suspenso por um administrador, o Protector é reativado de forma controlada:
manage-bde -protectors -enable C:
Seguem-se reinício, sincronização com o Central e nova verificação do estado. Uma suspensão sem Change explicável é investigada como Security Event.
TPM-only falha com 0x80310048
O erro FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED significa que o Windows não suporta o TPM-only Protector devido ao Firmware ou BIOS. A Sophos Policy não é a causa. Primeiro atualizam-se BIOS ou UEFI e TPM Firmware segundo as instruções do fabricante.
Se o hardware não permitir um funcionamento TPM adequado, uma Policy conscientemente escolhida sem TPM Protector pode recorrer ao modo de palavra-passe. Esta é uma decisão de segurança, não um Workaround silencioso. Os Recovery Keys existentes são verificados antes da alteração.
Outro caso TPM-only requer apenas o reinício correto: se o CDE preparou o hardware test, a encriptação começa após Restart now no Sophos. Encerrar e arrancar a frio depois nem sempre conclui o mesmo processo.
Um dispositivo DMA bloqueia o BitLocker
Se o Windows comunicar um dispositivo DMA sem proteção contra acesso externo, o bloqueio vem do Windows DMA Security e não do Sophos. Identifique dispositivo ou bus no Event Viewer e confirme a finalidade com o fabricante.
No Windows 10 e Windows 11 até 24H1, o bus confirmado pode ser inserido em HKLM\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses. O Windows 11 24H2 e posterior ignora a allowlist: corrija firmware, driver ou compatibilidade. Não autorize amplamente buses desconhecidos.
InvalidNamespace 0x8004100E
Se CDE.log indicar que faltam informações de Volume devido a ManagementStatus.InvalidNamespace e manage-bde -status também apresentar 0x80041002, a classe WMI Win32_EncryptableVolume está frequentemente registada de forma incorreta.
Numa linha de comandos administrativa, volta a registar-se o ficheiro Microsoft MOF:
mofcomp.exe C:\Windows\System32\wbem\win32_encryptablevolume.mof
manage-bde.exe -status
O dispositivo só é reiniciado e o PIN Prompt repetido depois de o segundo comando voltar a fornecer dados de Volume válidos.
Tablet ou Slate não aceita Pre-Boot Protector
Em dispositivos que o Windows identifica como Slate, um Protector com introdução por teclado é bloqueado se faltar a BitLocker Policy adequada. É típico ocorrer 0x803100B6 ao criar o Recovery Protector.
Em Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives, ativa-se Enable use of BitLocker authentication requiring preboot keyboard input on slates. Depois executa-se gpupdate /force ou a atualização GPO normal.
Sem UI Prompt por RDP ou Hyper-V Enhanced Session
A linha No UI user session available em CDE.log muitas vezes não significa uma falha do serviço. A Sophos apresenta o BitLocker Dialog intencionalmente apenas numa sessão Windows interativa local. Um Network-Type Login por RDP ou Hyper-V Enhanced Session não deve ativar a encriptação e deixar depois um estado Pre-Boot impossível de operar.
Por isso, o utilizador afetado inicia sessão na consola local e conclui aí o PIN, palavra-passe ou Protector Setup. Só depois se volta ao funcionamento remoto.
Um suporte de arranque impede o início
Um CD/DVD bootable inserido ou ISO bootable montado numa VM pode bloquear o hardware test do BitLocker. Se o teste voltar ao início após reiniciar, remova o suporte, verifique a ordem de arranque e repita o prompt Sophos na consola local.
Device Encryption Service com BadImageFormatException
Se, segundo o Application Event Log, Sophos.Encryption.BitLockerService.exe terminar com System.BadImageFormatException, o ficheiro log4net.dll no diretório Sophos Data Protection pode estar danificado. O KBA oficial da Sophos utiliza a cópia intacta do AutoUpdate Cache.
Depois de guardar os Logs e confirmar que o erro corresponde exatamente, substitui-se o ficheiro danificado em
C:\Program Files (x86)\Sophos\Sophos Data Protection\
por log4net.dll de
C:\ProgramData\Sophos\AutoUpdate\Cache\decoded\enc\ProgramFilesFolder\Sophos\Sophos Data Protection\
Após o reinício, o Sophos Device Encryption Service tem de voltar a funcionar. Se o ficheiro não existir no Cache ou o erro for diferente, a reparação não é improvisada; utilizam-se SDU e Sophos Support.
FileVault Recovery Key em falta ou inválido
Num Mac já gerido, um utilizador pode criar localmente um novo Personal FileVault Key. Se o Sophos Agent não conseguir validá-lo, o Central remove da base de dados o Key entretanto inválido. O novo Key tem então de ser obtido junto do utilizador ou da gestão que efetivamente assumiu o dispositivo.
Uma associação posterior do utilizador local ao Apple ID ou iCloud também pode alterar a gestão do FileVault Key. Um FileVault que funciona localmente não prova, por isso, que o Central tenha um Recovery Key atual. User, Secure Token, Volume Owner, MDM Escrow e hora do Central Key são verificados em conjunto.
Se um Mac ligado ao AD usa apenas uma conta de rede, esta não pode iniciar diretamente a encriptação. Inicie sessão uma vez para criar a conta móvel local e autorize-a com um administrador que tenha Secure Token. Depois, o utilizador ativa FileVault e o agente Sophos deposita a chave.
BitLocker não inicia após conversão MBR para GPT
Após converter Windows 10 com TPM 2.0 de MBR/Legacy BIOS para GPT/UEFI, as referências de recuperação em Boot Configuration Data podem deixar de coincidir. Device Encryption fica pending embora disco e TPM pareçam prontos.
Guarde Recovery Key, BCD e reagentc /info. Execute reagentc /disable e reagentc /enable, confirme a nova localização e reinicie. Não continue sem Windows RE ativo e chave protegida. Após reiniciar, verifique novamente CDE.log e reagentc /info antes de permitir que a encriptação continue.
Aumentar o logging de Device Encryption
CDE.log e o trace configuram-se de FATAL a TRACE com as chaves de registo documentadas de 32 ou 64 bits. O caminho deve corresponder à arquitetura do agente; depois reinicia-se o serviço.
Ative DEBUG ou TRACE apenas num período curto e reproduzível: os logs contêm utilizador, volume e Policy e crescem depressa. Reponha o nível e transfira os ficheiros como dados sensíveis.
Quando escalar?
Abre-se um pedido de suporte quando a disponibilidade do Recovery Key não está esclarecida, a reparação não corresponde exatamente ao erro documentado pela Sophos ou o estado do serviço e da encriptação continua contraditório após o reinício. O pacote contém CDE.log, SDU, manage-bde -status, BitLocker GPOs efetivas, Central Event, hora exata e passos já executados.
As bases das plataformas são explicadas em Gerir BitLocker com Sophos Central e Gerir FileVault com Sophos Central.