Navigated to page Certero - AI Docs

When Will a Certero Agent Self-Update?

CerteroX_Logo_Black.png


Applies to: Certero Unified Platform v8.6 and later - Windows and macOS agents.

Summary

A newly released platform version does not cause every deployed agent to update. The Certero agent is intelligent about updates: it checks each of its own installed modules against what the Endpoint Server (EPS) advertises, and downloads only the module files where its own version is different. If nothing has changed for the modules that agent runs, the agent stays exactly where it is.

The companion article (Windows Agent Updates & Versioning | 8.1 onwards) explains how you control auto-update at global and Configuration Group level. This article explains when an update will actually occur once you have auto-update enabled.


The Core Principle: Per-Module, Version-Based

A Certero Windows agent is not a single binary, it is a small set of installed modules (inventory, AppsMonitor, software metering, and so on). Each module has its own version.

When an agent checks in with its Endpoint Server, it reports the version of every module it currently has installed. The Endpoint Server compares those versions, one by one, against the versions advertised in its own client manifest.

Only modules where the agent's version differs from the server's expected version are flagged for update. The agent then downloads only those specific module files, nothing else.

This means:

  • A new agent build that only changes the inventory module will not cause AppsMonitor-only agents to do anything.

  • An agent that already has the current version of a module will not re-download it, even if other modules are being updated.

  • Modules the agent does not have installed are ignored entirely, they are not silently added.


What Triggers a Check?

The agent polls its Endpoint Server on a regular schedule (10 minutes by default, configurable). At each poll, the EPS returns instructions that may include an update bitmask. There is no separate updater process and no scheduled task, the same service that reports inventory handles updates over the same HTTP(S) connection.

For an update to happen at that poll, three things must all be true:

  1. The agent's AutoUpdate flag is set to true. This is resolved from either the global ClientAutoUpdate setting or the agent's assigned Configuration Group. If auto-update is off, no version check runs.

  2. At least one of the agent's installed modules has a different version than the EPS expects. If everything already matches, the EPS returns no update instruction and the agent does nothing.

  3. The EPS hosts the new module files. Endpoint Servers pull their client files as part of their own upgrade from the Application Server, so an EPS on an older build will not push newer client modules than it has itself received.

If any of these three conditions is not met, the agent stays on its current version until the next poll.


What Happens to Existing Agents

Existing agents remain on the version they have unless an update applies to a module they run.

Practical implications for a customer estate:

  • Agents at different versions across the estate is normal and expected, not a fault. Each agent's version reflects what it has needed to download, not what the latest release contains.

  • If a release only touches modules an agent doesn't run, that agent will show no version change at all.

  • An agent held on an older version via a Configuration Group (with AutoUpdate = false) will stay there indefinitely until the group setting is changed or the agent is moved out of the group. No self-update will ever occur while that flag is false.

  • Removing an agent from an auto-update-suppressing Configuration Group does not push a fresh check immediately, the update happens on the agent's next scheduled poll after its effective AutoUpdate value has been recalculated.


What Happens to Newly Deployed Endpoints

Newly built systems that receive an agent get the latest module versions the current EPS can offer regardless of most Configuration Group settings.

There are two reasons:

  1. The installer itself is always the current build. Installers downloaded from the EPS (ClientSetup_x64.exe / ClientSetup_Win32.exe) are the version that EPS currently hosts. A new deployment starts on that version.

  2. There is a brief window at first check-in where the global ClientAutoUpdate setting applies. When an agent registers for the first time, its AutoUpdate flag is populated from the global setting. Configuration Group assignment is a batch operation that runs approximately every 10 minutes. If the agent's first check-in happens before that batch has run, the agent will act on the global setting, usually enabling any pending module updates, before the group override can take effect.

For customers who use Configuration Groups specifically to pin a set of endpoints to a particular agent version, this means the pinning applies to existing members of the group. New deployments should be expected to arrive at the current version and then be held there on subsequent polls once the group assignment lands.


How the Comparison Actually Works

To pre-empt one common question: the check is a version comparison, not a file hash or checksum comparison. The agent reports a per-module revision string; the EPS compares that string against its manifest. If they differ, the module is queued for download. There is no per-file integrity check happening on every poll.

Module packages ({moduleId}.install.zip and {moduleId}.uninstall.zip) are downloaded over the same HTTP(S) channel the agent uses for everything else — no separate ports, no additional firewall requirements beyond what the agent already uses to reach the EPS.


Common Scenarios

Scenario

Result

Platform released, no modules on this agent changed

No update, agent stays on current version

Platform released, only inventory changed, agent has inventory

Inventory module updated; other modules untouched

Platform released, only inventory changed, agent has AppsMonitor only

No update, inventory is not installed on this agent

Global ClientAutoUpdate = false, no Configuration Group

Agent never self-updates

Configuration Group AutoUpdate = false

Agent never self-updates, regardless of global setting

Configuration Group changed from false to true, updates pending

Agent updates on its next poll after the group setting is re-evaluated

New endpoint deployed today

Installs at the current EPS version and receives any further module changes on first poll

Endpoint Server itself has not been upgraded yet

Agents pointing at it will not receive updates newer than what that EPS hosts


Checking an Agent's Current Versions

An agent's currently installed module versions are visible in the platform UI on the computer system's record, and are also logged locally on the endpoint. If you need to confirm whether a specific agent is expected to update on its next poll, comparing its reported module versions against the EPS's manifest is the definitive answer.