---
title: "When Will a Certero Agent Self-Update?"
canonical: "https://ai-docs.certero.com/space/CUP/335937537/When%20Will%20a%20Certero%20Agent%20Self-Update%3F"
format: markdown
---
---
**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](https://docs.certero.com/space/CUP/118918337/Windows+Agent+Updates+%26+Versioning+%7C+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
| <span style="color: #ffffff">**Scenario**</span> | <span style="color: #ffffff">**Result**</span> |
| --- | --- |
| 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.
---
## Related
- [Windows Agent Updates & Versioning | 8.1 onwards](https://docs.certero.com/space/CUP/118918337/Windows+Agent+Updates+%26+Versioning+%7C+8.1+onwards) - how to configure and control agent auto-update via global settings and Configuration Groups.