Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
jorgeluiznim
Advisor

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

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)

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. Vá em Policy > Deployment Policy > Software Deployment.
  2. Selecione a política (regra).
  3. No painel Capabilities & Exclusions, ligue o toggle Automatic Client Update para o sistema operacional apropriado.
  4. 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:

diag1-upgrade-deployment-rules.png

 

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:

diag2-gradual-rollout.png

 

💡 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):

  1. Vá em Policy > Export Package e selecione ou crie o pacote (escolha OS, versão, capabilities).
  2. Faça o build e baixe o pacote para o OS alvo (EPS_<Ano>_<Versão>.exe no Windows).
  3. 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:

  1. Coloque a mesma versão do pacote num local nas máquinas client (por exemplo C:\TEMP\EPS\...\EPS.msi).
  2. Vá em Policy > Client Settings > Installation > Deployment from Local Paths and URLs.
  3. Selecione Allow to install software deployment packages from local folders and URLs e adicione os Deployment Paths.
  4. Opcionalmente selecione Enable Deployment from Server when no MSI was found in local paths como fallback.
  5. 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):

  1. O toggle Automatic Client Update da regra está desligado (comum em regras existentes de tenants existentes). Ligue e dê Install Policy
  2. O computador não está no escopo da regra. Confira a atribuição (OU / Virtual Group / Computer)
  3. 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
  4. Client sem comunicação com o serviço. Verifique a conectividade (veja o Artigo 3)
  5. 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

0 Replies

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events