[EN] Agent Upgrade Best Practices: Deployment Rule...

jorgeluiznim

Article 5 of the Harmony Endpoint Deep Dives series · A note on management: Harmony Endpoint is cloud-managed (Infinity Portal / Web Management) in most deployments today. The content below follows the cloud model; where an on-premises Management Server behaves differently, that is called out.

Purpose

Every client release forces the same question: how do I upgrade hundreds of Harmony Endpoint clients without breaking FDE, flooding the WAN, or rebooting the CFO's laptop at 2 PM? In the cloud model, Check Point runs the management service, so the job is no longer about repositories and server versions — it is about choosing an upgrade mechanism and scoping it. This article consolidates the cloud upgrade mechanics into a practical playbook: Automatic Client Update, Deployment Rules, gradual rollouts, exported packages, Local Deployment, and the Installation and Upgrade Settings that decide the user experience.

Audience

[x] Endpoint Administrators
[x] Security Engineers
[ ] SOC Analysts
[x] Beginners
[x] Experts

Prerequisites

Access to the Harmony Endpoint Web Management console (Infinity Portal) with rights to edit the Software Deployment policy
Familiarity with the Deployment Rules concept (Default Policy rule plus custom rules by OU, computer, or Virtual Group)

The Golden Rules (before anything else)

The Full Disk Encryption component cannot be removed during an upgrade — all other components and settings can change, but FDE stays.
FDE discipline: do not upgrade while the disk is not fully encrypted, do not start a second upgrade before the first completes protection, and do not uninstall an upgrade before the machine is fully protected by the new version.
The user experience is a policy setting, not luck. Whether the client reboots silently or lets the user postpone comes from Installation and Upgrade Settings — configure it before you touch a version.
Prefer the managed path. In the cloud, Automatic Client Update keeps clients on the latest approved version silently; reach for manual version bumps only when you need tight control over timing.

Automatic Client Update (the cloud default)

This is the feature that changes the upgrade conversation in cloud environments. Automatic Client Update automatically upgrades Endpoint Security clients to the latest version, straight from the Software Deployment policy.

ℹ️ Note: Automatic Client Update is available only for cloud-managed Endpoint Security environments — it is not supported for clients managed by an on-premises Management Server. It is supported on Windows only.

How to enable it:

Go to Policy > Deployment Policy > Software Deployment.
Select the policy (rule).
In the Capabilities & Exclusions pane, turn on the Automatic Client Update toggle for the appropriate operating system.
Click Install Policy.

All clients associated with that policy are then upgraded to the latest version. Upgrades run silently — no end-user interaction is required, unless the upgrade impacts user experience. Blade selection and activation logic stay exactly the same whether the toggle is on or off.

Defaults you must know (they bite people):

Context	Automatic Client Update default
New tenants	Enabled
Newly cloned rules (including clones in existing tenants)	Enabled — this is the recommended configuration
Existing rules in existing tenants	Disabled
A rule exported from one tenant and imported into another	Enabled in the imported rule

✅ Best Practice: on an established tenant, existing rules ship with the toggle off. If you want hands-off upgrades there, turn it on deliberately — don't assume it is already working.

The behavior is identical for MSP accounts, which makes this the natural way for a provider to keep many tenants current from one workflow.

Why the Dynamic Package Still Matters

Even with Automatic Client Update doing the heavy lifting, the Dynamic Package is the packaging that makes cloud upgrades cheap on the wire.

Property	Dynamic Package (.EXE)
CPU	Any CPU — one file for 32/64-bit
Contents	Combined with the Tiny Agent, it installs only what is necessary for each machine
Network	Reduces traffic for installing selected blades
EPMaaS	In Endpoint Management as a Service, admins can upload/download only the Dynamic Package (*.EXE)

ℹ️ Note: the Dynamic Package is not supported for macOS, Linux, or Browse Security — those use their own package types.

When you build an export package, the Minimize package size (takes longer) option trades build time for a smaller download — useful when bandwidth to the endpoint is the constraint.

Path 1 — Manual Version Bump with a Deployment Rule

When you want explicit control over when a group upgrades (instead of always-latest), drive it from the rule:

Notes that matter in production:

Changing the client version in a rule upgrades every computer assigned to that rule — scope the rule (OU, specific computers, Virtual Group) before you touch the version.
The user experience (silent forced restart vs. postpone prompt) comes from Installation and Upgrade Settings, not from the rule. See the next section.
Deployment Rules work on Windows and macOS; Linux is not supported for deployment rules yet.

Installation and Upgrade Settings — where the "2 PM reboot" is prevented

By default, users can postpone the installation or upgrade. You tune that under the Installation and Upgrade Settings:

Default reminder interval — minutes after which the user is reminded to install.
Force Installation and automatically restart after — hours after which the install starts automatically.
Maximum delay in download of packages — the maximum hours an end user can postpone.

✅ Best Practice: set the force timer so the automatic restart lands outside business hours. That single setting is what keeps the upgrade off the CFO's screen at 2 PM.

Path 2 — Gradual Rollout (pilot first)

The gradual model is simple and effective:

💡 Tip: combine with the predefined Virtual Groups (All Laptops, All Desktops) to slice pilot rings without touching AD.

ℹ️ Note: a cloned rule has Automatic Client Update enabled by default — expected for a pilot ring, but confirm the toggle matches your intent before you Install Policy.

Path 3 — Upgrading with an Exported Package (manual)

For clients managed outside Deployment Rules (third-party software distribution, shared path, email):

Go to Policy > Export Package and select or create the package (choose OS, version, capabilities).
Build it, then download the package for the target OS (EPS_<Year>_<Version>.exe for Windows).
Distribute to users — on Windows 8.1 and higher, install with Run as administrator (double-click does not work).

Path 4 — Local Deployment (upgrade without pulling from the service)

For bandwidth-constrained sites, clients can upgrade from a local path or URL instead of downloading the package from the management service:

Stage the same package version in a local location on the client computers (for example C:\TEMP\EPS\...\EPS.msi).
Go to Policy > Client Settings > Installation > Deployment from Local Paths and URLs.
Select Allow to install software deployment packages from local folders and URLs, and add the Deployment Paths.
Optionally select Enable Deployment from Server when no MSI was found in local paths as a fallback.
Create or edit the deployment rule with that package version, then Install Policy.

⚠️ Warning: the version in the deployment rule and the version staged in the local path must match — a mismatch means the client is not deployed, and the console shows an error.

FDE and the Upgrade

Full Disk Encryption is the one component that constrains an upgrade, and the cloud rules are strict but simple:

You cannot remove the FDE component during an upgrade. Plan any FDE removal as a separate, post-upgrade change.
Make sure encryption is not mid-run before upgrading, and never stack a second upgrade on top of one still protecting the disk.

Best Practices

✅ Best Practice: on cloud tenants, make Automatic Client Update your default for steady-state upgrades; keep manual version bumps for change-controlled windows.

✅ Best Practice: pilot ring first (clone a rule scoped to a Virtual Group), production rings after validation.

✅ Best Practice: align Installation and Upgrade Settings (force-restart timer) with your business hours before installing any upgrade.

✅ Best Practice: change the default Agent Uninstall Password (secret) so upgrades and clients can't be tampered with — it only protects you if it isn't the default.

Common Mistakes

Mistake	Impact	Solution
Assuming Automatic Client Update is already on in an existing tenant	Clients quietly stay on old versions	Existing rules ship with the toggle off — enable it deliberately
Changing the version on a broad rule "just to test"	Entire OU upgrades at once	Clone the rule, scope it to a pilot Virtual Group first
Ignoring the force-restart timer	The 2 PM reboot	Set Installation and Upgrade Settings to restart outside business hours
Removing FDE in the upgrade	Not possible during upgrade	Plan FDE removal as a separate, post-upgrade change
Upgrading FDE mid-encryption	Risk to the disk state	Wait until fully encrypted; never stack upgrades
Local Deployment version mismatch	Client is not deployed; console error	Keep the rule version and the local path version identical

Troubleshooting

Symptom: After enabling Automatic Client Update (or bumping a rule's version) and installing policy, some clients never upgrade Environment: Windows clients, cloud-managed Root Causes & checks (most common):

The rule's Automatic Client Update toggle is off (common on existing rules in existing tenants) — turn it on and Install Policy
The computer is not in the rule's scope — verify entity assignment (OU / Virtual Group / Computer)
The user keeps postponing — remember the install starts automatically after the Force Installation timer; check Installation and Upgrade Settings
Client not communicating with the service — check connectivity (see Article 3)
Using Local Deployment with a version mismatch between the rule and the local path

FAQ

Q: What is the fastest way to keep all my cloud clients on the latest version? A: Turn on Automatic Client Update in the Software Deployment policy (Capabilities & Exclusions pane) and Install Policy. Upgrades then run silently. It is Windows-only and cloud-only.

Q: Is Automatic Client Update on by default? A: For new tenants and newly cloned rules, yes. For existing rules in existing tenants, no — you must enable it.

Q: Can I choose which components change during an upgrade? A: Yes, all except Full Disk Encryption, which cannot be removed during an upgrade.

Q: How do I stop upgrades from rebooting machines during the workday? A: Set the Force Installation and automatically restart after timer (and the reminder/download-delay settings) so the automatic restart lands outside business hours.

Q: How do I upgrade clients without every one of them downloading from the cloud service? A: Use Local Deployment — stage the package locally and point Client Settings at the local paths, keeping the local version identical to the rule's version.

References

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

Revision History

Date	Version	Author	Changes
2026-07-16	1.0	Jorge Luiz	Initial version
2026-07-30	2.0	Jorge Luiz	Cloud-first revalidation against the cloud Administration Guide: Automatic Client Update as the cloud default, Installation and Upgrade Settings, Local Deployment; removed on-prem repository/PreUpgrade.exe/legacy R73 and unsourced package-signature and delta-size claims

Supported Versions: Harmony Endpoint cloud management (Infinity Portal / Web Management); Automatic Client Update is Windows-only Last Updated: 2026-07-30