[PT-BR] Boas Práticas de Upgrade do Agent: Deployment Rules e Rollout Gradual

jorgeluiznim — Tue, 11 Aug 2026 11:35:30 GMT

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.

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

topic [PT-BR] Boas Práticas de Upgrade do Agent: Deployment Rules e Rollout Gradual in Endpoint