Artigo 5 da serie Harmony Endpoint Deep Dives · Nota sobre a gestão: o Harmony Endpoint é gerenciado pela nuvem (Infinity Portal / Web Management) na maioria das implantações de hoje. O conteúdo abaixo segue o modelo em nuvem; quando um Management Server on-premises se comporta de forma diferente, isso é sinalizado.
Objetivo
Todo release de client traz a mesma pergunta: como fazer upgrade de centenas de clients Harmony Endpoint sem quebrar o FDE, inundar a WAN ou reiniciar o notebook do CFO às 14h? No modelo em nuvem, a Check Point opera o serviço de gestão, então o trabalho deixou de ser sobre repositórios e versões de servidor. Passou a ser sobre escolher um mecanismo de upgrade e delimitar seu escopo. Este artigo consolida a mecânica de upgrade em nuvem num playbook prático: Automatic Client Update, Deployment Rules, rollout gradual, pacotes exportados, Local Deployment e as Installation and Upgrade Settings que definem a experiência do usuário.
Público
- [x] Administradores de Endpoint
- [x] Engenheiros de Segurança
- [ ] Analistas SOC
- [x] Iniciantes
- [x] Especialistas
Pré-requisitos
- Acesso ao console Web Management do Harmony Endpoint (Infinity Portal) com permissão para editar a política de Software Deployment
- Familiaridade com o conceito de Deployment Rules (a regra Default Policy mais regras customizadas por OU, computador ou Virtual Group)
As Regras de Ouro (antes de qualquer coisa)
- O componente Full Disk Encryption não pode ser removido durante um upgrade. Todos os demais componentes e configurações podem mudar, mas o FDE permanece.
- Disciplina de FDE: não faça upgrade com o disco não totalmente criptografado, não inicie um segundo upgrade antes de o primeiro concluir a proteção, e não desinstale um upgrade antes de a máquina estar totalmente protegida pela nova versão.
- A experiência do usuário é uma configuração de política, não sorte. Reiniciar em silêncio ou deixar o usuário adiar vem das Installation and Upgrade Settings. Configure isso antes de tocar numa versão.
- Prefira o caminho gerenciado. Na nuvem, o Automatic Client Update mantém os clients na versão mais recente aprovada de forma silenciosa. Recorra ao bump manual de versão só quando precisar de controle fino sobre o momento.
Automatic Client Update (o padrão em nuvem)
Este é o recurso que muda a conversa sobre upgrade em ambientes de nuvem. O Automatic Client Update faz upgrade automático dos clients Endpoint Security para a versão mais recente, direto da política de Software Deployment.
ℹ️ Nota: o Automatic Client Update está disponível somente para ambientes gerenciados na nuvem. Não é suportado para clients gerenciados por um Management Server on-premises. É suportado apenas no Windows.
Como habilitar:
- Vá em Policy > Deployment Policy > Software Deployment.
- Selecione a política (regra).
- No painel Capabilities & Exclusions, ligue o toggle Automatic Client Update para o sistema operacional apropriado.
- Clique em Install Policy.
Todos os clients associados àquela política passam a ser atualizados para a versão mais recente. Os upgrades rodam em silêncio, sem exigir interação do usuário, a não ser que o upgrade impacte a experiência dele. A lógica de seleção e ativação de blades continua exatamente igual, com o toggle ligado ou desligado.
Defaults que você precisa conhecer (eles pegam muita gente):
| Contexto |
Default do Automatic Client Update |
| Tenants novos |
Ligado |
| Regras recém-clonadas (inclusive clones em tenants existentes) |
Ligado, que é a configuração recomendada |
| Regras existentes em tenants existentes |
Desligado |
| Regra exportada de um tenant e importada em outro |
Ligado na regra importada |
✅ Boa prática: num tenant já estabelecido, as regras existentes vêm com o toggle desligado. Se você quer upgrade sem intervenção ali, ligue de propósito, não presuma que já está funcionando.
O comportamento é idêntico para contas MSP, o que faz disso o jeito natural de um provedor manter vários tenants em dia a partir de um só fluxo.
Por Que o Dynamic Package Ainda Importa
Mesmo com o Automatic Client Update fazendo o trabalho pesado, o Dynamic Package é o empacotamento que deixa o upgrade em nuvem barato na rede.
| Propriedade |
Dynamic Package (.EXE) |
| CPU |
Any CPU, um arquivo para 32/64-bit |
| Conteúdo |
Combinado com o Tiny Agent, instala só o necessário para cada máquina |
| Rede |
Reduz o tráfego para instalar os blades selecionados |
| EPMaaS |
No Endpoint Management as a Service, o admin pode fazer upload/download apenas do Dynamic Package (*.EXE) |
ℹ️ Nota: o Dynamic Package não é suportado para macOS, Linux ou Browse Security. Esses usam seus próprios tipos de pacote.
Ao montar um pacote de export, a opção Minimize package size (takes longer) troca tempo de build por um download menor, útil quando a banda até o endpoint é o gargalo.
Caminho 1 — Bump Manual de Versão com uma Deployment Rule
Quando você quer controle explícito sobre quando um grupo faz upgrade (em vez de sempre-a-mais-recente), conduza pela regra:

Notas que importam em produção:
- Mudar a versão do client numa regra faz upgrade de todos os computadores atribuídos àquela regra. Delimite o escopo da regra (OU, computadores específicos, Virtual Group) antes de tocar na versão.
- A experiência do usuário (restart silencioso forçado vs. prompt de adiamento) vem das Installation and Upgrade Settings, não da regra. Veja a próxima seção.
- Deployment Rules funcionam no Windows e no macOS. Linux ainda não é suportado para deployment rules.
Installation and Upgrade Settings, onde se evita o "reboot das 14h"
Por padrão, os usuários podem adiar a instalação ou o upgrade. Você ajusta isso nas Installation and Upgrade Settings:
- Default reminder interval: minutos após os quais o usuário é lembrado de instalar.
- Force Installation and automatically restart after: horas após as quais a instalação começa automaticamente.
- Maximum delay in download of packages: o máximo de horas que o usuário final pode adiar.
✅ Boa prática: ajuste o timer de força para que o restart automático caia fora do horário comercial. Essa única configuração é o que mantém o upgrade longe da tela do CFO às 14h.
Caminho 2 — Rollout Gradual (piloto primeiro)
O modelo gradual é simples e eficaz:

💡 Dica: combine com os Virtual Groups predefinidos (All Laptops, All Desktops) para fatiar os anéis de piloto sem mexer no AD.
ℹ️ Nota: uma regra clonada já vem com Automatic Client Update ligado por padrão, o que faz sentido para um anel de piloto. Ainda assim, confirme se o toggle bate com sua intenção antes de dar Install Policy.
Caminho 3 — Upgrade com Pacote Exportado (manual)
Para clients gerenciados fora das Deployment Rules (distribuição por software de terceiros, compartilhamento de rede, e-mail):
- Vá em Policy > Export Package e selecione ou crie o pacote (escolha OS, versão, capabilities).
- Faça o build e baixe o pacote para o OS alvo (
EPS_<Ano>_<Versão>.exe no Windows).
- Distribua aos usuários. No Windows 8.1 e superior, instale com Run as administrator (duplo clique não funciona).
Caminho 4 — Local Deployment (upgrade sem puxar do serviço)
Para sites com banda limitada, os clients podem fazer upgrade a partir de um caminho ou URL local em vez de baixar o pacote do serviço de gestão:
- Coloque a mesma versão do pacote num local nas máquinas client (por exemplo
C:\TEMP\EPS\...\EPS.msi).
- Vá em Policy > Client Settings > Installation > Deployment from Local Paths and URLs.
- Selecione Allow to install software deployment packages from local folders and URLs e adicione os Deployment Paths.
- Opcionalmente selecione Enable Deployment from Server when no MSI was found in local paths como fallback.
- Crie ou edite a deployment rule com aquela versão de pacote e então Install Policy.
⚠️ Atenção: a versão na deployment rule e a versão colocada no caminho local precisam ser iguais. Uma divergência significa que o client não é deployado, e o console mostra erro.
FDE e o Upgrade
O Full Disk Encryption é o único componente que restringe um upgrade, e as regras em nuvem são rígidas, porém simples:
- Você não pode remover o componente FDE durante um upgrade. Planeje qualquer remoção de FDE como uma mudança separada, pós-upgrade.
- Garanta que a criptografia não esteja em andamento antes do upgrade, e nunca empilhe um segundo upgrade sobre um que ainda está protegendo o disco.
Boas Práticas
✅ Boa prática: em tenants de nuvem, faça do Automatic Client Update seu padrão para upgrades de regime; deixe o bump manual de versão para janelas com controle de mudança.
✅ Boa prática: anel de piloto primeiro (clone uma regra restrita a um Virtual Group), anéis de produção após a validação.
✅ Boa prática: alinhe as Installation and Upgrade Settings (timer de restart forçado) com o horário do negócio antes de instalar qualquer upgrade.
✅ Boa prática: troque a Agent Uninstall Password padrão (secret), para que upgrades e clients não possam ser adulterados. Ela só protege se não for a padrão.
Erros Comuns
| Erro |
Impacto |
Solução |
| Presumir que o Automatic Client Update já está ligado num tenant existente |
Os clients ficam parados em versões antigas |
Regras existentes vêm com o toggle desligado; ligue de propósito |
| Mudar a versão numa regra ampla "só para testar" |
A OU inteira faz upgrade de uma vez |
Clone a regra e restrinja a um Virtual Group piloto primeiro |
| Ignorar o timer de restart forçado |
O reboot das 14h |
Ajuste as Installation and Upgrade Settings para reiniciar fora do horário comercial |
| Remover o FDE no upgrade |
Impossível durante um upgrade |
Planeje a remoção do FDE como mudança separada, pós-upgrade |
| Upgrade de FDE no meio da criptografia |
Risco ao estado do disco |
Espere criptografar totalmente; nunca empilhe upgrades |
| Divergência de versão no Local Deployment |
O client não é deployado; erro no console |
Mantenha a versão da regra e a do caminho local idênticas |
Troubleshooting
Sintoma: Após ligar o Automatic Client Update (ou subir a versão de uma regra) e instalar a política, alguns clients nunca fazem upgrade Ambiente: Clients Windows, gerenciados na nuvem Causas-raiz e verificações (mais comuns):
- O toggle Automatic Client Update da regra está desligado (comum em regras existentes de tenants existentes). Ligue e dê Install Policy
- O computador não está no escopo da regra. Confira a atribuição (OU / Virtual Group / Computer)
- O usuário fica adiando. Lembre que a instalação inicia automaticamente após o timer de Force Installation; confira as Installation and Upgrade Settings
- Client sem comunicação com o serviço. Verifique a conectividade (veja o Artigo 3)
- Uso de Local Deployment com divergência de versão entre a regra e o caminho local
FAQ
P: Qual o jeito mais rápido de manter todos os meus clients em nuvem na versão mais recente? R: Ligue o Automatic Client Update na política de Software Deployment (painel Capabilities & Exclusions) e dê Install Policy. Os upgrades passam a rodar em silêncio. É Windows-only e cloud-only.
P: O Automatic Client Update vem ligado por padrão? R: Para tenants novos e regras recém-clonadas, sim. Para regras existentes em tenants existentes, não. Você precisa habilitar.
P: Posso escolher quais componentes mudam durante um upgrade? R: Sim, todos exceto o Full Disk Encryption, que não pode ser removido durante um upgrade.
P: Como evito que os upgrades reiniciem as máquinas no meio do expediente? R: Ajuste o timer Force Installation and automatically restart after (e as configurações de lembrete e de atraso de download) para que o restart automático caia fora do horário comercial.
P: Como faço upgrade dos clients sem que cada um baixe do serviço em nuvem? R: Use o Local Deployment. Coloque o pacote localmente e aponte as Client Settings para os caminhos locais, mantendo a versão local idêntica à da regra.
Artigos Relacionados
Referências
- Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal) — Deploying Endpoint Clients (Tiny Agent, Dynamic Package, Deployment Rules, Export Package)
- Check Point Harmony Endpoint Administration Guide (cloud / Infinity Portal) — Installation and Upgrade Settings, Local Deployment Options, Automatic Client Update
Histórico de Revisões
| Data |
Versão |
Autor |
Mudanças |
| 2026-07-16 |
1.0 |
Jorge Luiz |
Versão inicial |
| 2026-07-30 |
2.0 |
Jorge Luiz |
Revalidação cloud-first contra o Administration Guide cloud: Automatic Client Update como padrão em nuvem, Installation and Upgrade Settings, Local Deployment; removidos repository on-prem/PreUpgrade.exe/R73 legado e afirmações sem fonte sobre assinaturas no pacote e tamanho do delta |
Versões Suportadas: Harmony Endpoint gerenciado na nuvem (Infinity Portal / Web Management); o Automatic Client Update é Windows-only Última Atualização: 2026-07-30