Preparar Sophos Endpoint numa VDI Gold Image
Um Endpoint instalado normalmente não pode ser simplesmente clonado como VDI Template. Isso cria identidades duplicadas, Policies erradas e Health não fiável. A Sophos fornece um modo próprio para Windows Gold Images.
São suportados Windows Client e Server atuais a partir de Windows 10 ou Server 2016, com as versões mínimas exigidas de Thin Installer e Core Agent. Antes da criação verificam-se Supported Systems.
Limitações
Uma Gold Image não é preparada com Server Lockdown, Update Cache ou BitLocker Device Encryption. Estas funções contradizem o Image Lifecycle ou criam um estado que não pode ser transferido corretamente para Clones.
Tamper Protection é desativada de forma controlada durante a preparação e reativada antes do fim. O Master permanece protegido administrativamente e não é usado como Endpoint normal.
Persistent ou non-persistent
Em Persistent Desktops, a identidade permanece depois do deployment. Non-persistent Desktops são recriados regularmente e exigem o Installer Parameter --nonpersistent para serem tratados corretamente pelo Sophos Central.
Esta escolha também afeta a limpeza no Central. Para non-persistent VDI, uma regra em Removal of Inactive Devices pode remover definitivamente Clones antigos. O Master criado com --goldimage não é abrangido por estas regras.
Preparar o Master
O sistema base limpo recebe todos os Patches e Production Applications. Só depois se instala Sophos no Gold Image Mode previsto. Exemplo simplificado:
SophosSetup.exe --quiet --goldimage --products=endpoint --devicegroup="VDI\Persistent"
Para non-persistent acrescenta-se a opção correspondente. Group, Proxy, Relay e restantes parâmetros são definidos conscientemente como num rollout normal.
O Timeout padrão de preparação é 120 segundos e pode ser ajustado entre 0 e 900 segundos. Um valor superior não é uma correção geral, mas apenas para preparação efetivamente mais lenta.
Notification Mode
Com SophosSetup.exe --goldimage --notificationmode, o Master regista-se inicialmente no Central e comunica até ao reinício seguinte. Depois, a comunicação permanece desativada até executar GoldImageCli.exe activate ou Activate and Update no Master sem alteração de nome. Um Clone disponibilizado é ativado com GoldImageCli.exe clone.
GoldImageCli impede clone enquanto o nome do computador não mudar e impede activate depois da alteração. Para Instant Clones do VMware Horizon, configurar C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe com o parâmetro clone como Post-Synchronization Script.
O processo exato é automatizado e registado na Image Pipeline. Um Snapshot só é autorizado quando Sophos Status mostra inequivocamente o estado previsto.
Clones apenas a partir do Master
Novos Desktops são sempre criados diretamente a partir da Gold Image preparada. Um Clone iniciado não é usado como novo Template, porque duplicaria Runtime State e Identity Data.
Após o primeiro arranque verificam-se nova Device Identity, Group, Agent Mode, Policies e Update. Um login bem-sucedido não prova que a Sophos registou corretamente o Clone como dispositivo próprio.
Para pools non-persistent use um conjunto limitado e reutilizável de nomes, do tamanho máximo simultâneo. Sem limite, o Central acumula objetos apesar da limpeza VDI.
Lifecycle no Central
Non-persistent Clones criam muitos objetos de curta duração. Em Global Settings > Products and Services > Endpoint and Server > Removal of Inactive Devices, cria-se uma Targeted Rule para o VDI Group. Permanently remove VDI desktops elimina Clones sem recuperação.
A opção só é usada para grupos non-persistent inequívocos. Uma regra demasiado ampla pode eliminar Offline Notebooks normais. Update Caches e Message Relays não regressam com Restore Deleted Devices.
Atualizar a Gold Image
Agent ou System Updates são primeiro testados numa cópia do Master e depois é publicada uma nova imagem. Um Fixed Term ou LTS Package expirado não pode permanecer no Master, pois os Clones arrancariam sem Protection Updates atuais.
Após cada Image Release, testa-se integralmente pelo menos um Persistent Clone e, se usado, um Non-persistent Clone. Duplicate Device Detections, grupos errados e re-registos frequentes são Stop Criteria.
Software Packages controla funções, não conteúdos Threat Protection que continuam automáticos. Sem pacote fixo, cada nova instância pode iniciar upgrade. Defina o canal do Master antes da aprovação.
Validação segura e rollback
Verificar o modo e os requisitos
O Timeout Mode verifica o nome do computador após 120 segundos por predefinição; --goldimagetimeout=<segundos> aceita de 0 a 900. O Notification Mode destina-se a VMware Horizon Instant Clone e evita registar máquinas intermédias. Os requisitos CLI atuais da Sophos indicam para este modo Thin Installer 1.20.627 ou posterior, Core Agent 2024.2.0.527 ou posterior, ou Server Core Agent 2024.2.0.534 ou posterior. O Timeout Mode requer Thin Installer 1.14 e Core Agent ou Server Core Agent 2022.1.0.78 ou posterior.
Antes da instalação, criar um snapshot de rollback testado, verificar a conectividade ao Central e o VDI Group exato e desativar Tamper Protection. Não usar um dispositivo com Server Lockdown, Update Cache, BitLocker ou componentes Sophos Encryption. Exemplo completo para um pool Horizon non-persistent:
.\SophosSetup.exe --quiet --goldimage --notificationmode --nonpersistent --products=endpoint --devicegroup="VDI\NonPersistent"
Selar a imagem
Aguardar o fim da instalação, confirmar que o Master aparece no grupo previsto sem erros Health locais e voltar a ativar Tamper Protection. Em Notification Mode, o Master comunica até ao primeiro reinício e depois permanece offline propositadamente. Executar C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe activate apenas no Master inalterado e C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe clone apenas num Clone concluído cujo nome mudou. O Horizon pode usar o executável com o parâmetro clone como Post-Synchronization Script. Encerrar o Master validado, selar o snapshot desligado e manter a imagem anteriormente aprovada até ao teste bem-sucedido dos Clones.
Validar identidade e lifecycle
Iniciar pelo menos dois Clones diretamente do Master. Confirmar para cada um nome único e objeto Central separado, licença Endpoint ou Server, grupo e Policies esperados, valor Last active atual, Health correto e Updates concluídos. A Sophos só limpa a configuração herdada depois de detetar a mudança de nome. Não substituir o processo eliminando ficheiros, registo, serviços Sophos ou o objeto Central. Se a plataforma não o conseguir cumprir, usar apenas o procedimento de identidade manual ou com script da Sophos.
Em pools non-persistent, --nonpersistent e Permanently remove VDI desktops devem ser usados em conjunto. A documentação de dispositivos inativos confirma que a remoção VDI permanente não pode ser restaurada, que clientes MSP e Marketplace devem usar pelo menos 31 dias e que o Central verifica a cada 24 horas à meia-noite da região de dados. Testar primeiro uma Targeted Rule limitada ao VDI Group; o Master --goldimage não é abrangido por regras de eliminação.
Reverter em caso de falha
Perante identidades duplicadas, falha de registo ou Policies erradas, parar o rollout do pool, eliminar os Clones afetados e regressar ao último Template desligado aprovado. Eliminar um objeto Central não repara a identidade local. Atualizar o Master apenas num ciclo controlado e publicar um novo snapshot só depois de repetir com sucesso o teste dos Clones. A Sophos mantém a sequência oficial e as versões mínimas em Create gold images and clone new devices.
Troubleshooting
Perante Duplicate Device Alerts verificam-se --goldimage e clonagem direta a partir do Master. Uma imagem normal não é reparada de forma fiável eliminando posteriormente objetos Central.
Perante Clones ausentes ou desprotegidos verificam-se Network, Proxy/Relay e Installer Logs. Para Lifecycle incorreto, verificam-se --nonpersistent e Target Group da Removal Rule.
Em Citrix App Layering prepare Sophos numa App Layer própria, não OS Layer. A pipeline requer exceções UniRSD documentadas; sem elas serviços podem falhar apesar de Tamper Protection. Documente layers, contas e momento e ligue o procedimento Registry ao KBA atual.
Sophos suporta muitas plataformas quando o guest OS é suportado, mas não substitui a matriz do hypervisor. Microsoft não suporta antivírus de terceiros em hosts Azure Stack HCI v1; Sophos aí sai do suporte Microsoft.
Artigos relacionados
As opções CLI estão em Automatizar o rollout do Sophos Endpoint no Windows. A limpeza está em Gerir dispositivos e grupos Sophos Central Endpoint.