Agent Client Collector upgrade overview

  • Release version: Yokohama
  • Updated May 28, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Agent Client Collector upgrade overview

    The Agent Client Collector (ACC) Framework enables seamless upgrades of ACC agents directly from the ServiceNow instance, eliminating the need for manual updates on individual hosts. Agents can be upgraded individually or in bulk, with each upgrade involving downloading, installing, restarting, and reporting the status back to the instance.

    Show full answer Show less

    Upgrade Methods

    • Single agent upgrade: Upgrade individual agents via the UI, suitable for validating the upgrade process before wider deployment. Multiple agents (up to 50) can also be upgraded simultaneously from the list view.
    • Mass upgrade: Automatically upgrade all eligible agents using a scheduled job or a background script. Both options apply rate limiting to control rollout speed, with the background script triggering immediate upgrades.

    Upgrade Stages

    Each upgrade attempt progresses through three key stages, with records created in the Agent Upgrade Histories table:

    • InstanceVerification: Validates agent eligibility based on OS support, current version, status, and connectivity.
    • AgentVerification: Confirms the agent can upgrade by checking permissions, disk space, and dependencies.
    • Upgrade: The agent downloads the new package, installs it, restarts, and updates its version.

    Agent Eligibility

    Agents qualify for auto-upgrade if they meet all the following criteria:

    • Status is Up.
    • Current version is between 2.7.0 and the target upgrade version.
    • Not marked as duplicate.
    • Has a valid MID Server or Pod reference.
    • Has not exceeded retry limits for failed upgrades.
    • Runs on a supported operating system.

    Package Download Sources

    Agents obtain upgrade packages based on their connection type:

    • Cloud Services (ICS) connected agents: Download from ServiceNow CDN.
    • MID Server connected agents: Download directly over the local network from the MID Server. If unavailable, fallback to the Install Server is used.
    • Custom download servers: Can be configured via the agent-upgrade-url-path key in the agent’s acc.yml file, which takes precedence over default sources.

    Rollout Strategy

    To minimize risks when upgrading large fleets, follow a phased approach:

    • Upgrade a single agent from the UI to validate the process end-to-end.
    • Upgrade 5–10 agents from the list view, selecting diverse operating systems.
    • Proceed with a full rollout using the scheduled job or background script for mass upgrades.

    The Agent Client Collector Framework manages agent upgrades directly from the instance, with no manual action required on individual agent hosts.

    You can upgrade Agent Client Collector agents one at a time through the UI, or upgrade all eligible agents at once using the auto-upgrade feature. After an upgrade starts, each agent downloads the new version, installs it, restarts, and reports the result back to the instance.

    Upgrade methods

    Two upgrade methods are available:

    Single agent upgrade
    Upgrade one agent at a time from the agent record in the UI. Use this method to validate the upgrade process before a broader rollout. You can also select multiple agents from the list view to upgrade up to 50 agents at a time.
    Mass upgrade
    Upgrade all eligible agents automatically using the built-in scheduled job or a background script. The scheduled job applies rate limiting to control the rollout pace. The background script also uses rate limiting, and triggers an immediate upgrade without waiting for the next scheduled run.

    Upgrade stages

    Both single and mass upgrade attempts, progress through the following stages. Each stage creates a record in the Agent Upgrade Histories table.

    InstanceVerification
    The instance confirms the agent is eligible for upgrade. Checks include operating system support, agent version, agent status, and MID Server connectivity.
    AgentVerification
    The agent confirms it can perform the upgrade. Checks include permissions, available disk space, and dependencies.
    Upgrade
    The agent downloads the package, installs it, and restarts with the new version.

    For details on the required properties for agent overview, see Agent Client Collector upgrade properties.

    Agent eligibility

    An agent is eligible for auto-upgrade when it meets all of the following conditions:

    • Status is Up.
    • Version is 2.7.0 or higher and lower than the target upgrade version.
    • Agent is not flagged as a duplicate.
    • Has a valid MID Server or Pod reference.
    • Has not exceeded the retry limit for failed upgrades.
    • Runs on a supported operating system.

    Package download sources

    During upgrade, each agent downloads the new package from one of the following sources, depending on its connection type:

    • Agents connected via Cloud Services (ICS) download from the ServiceNow CDN at https://cdn-install.sncapps.service-now.com.
    • Agents connected via MID Server download from the MID Server directly over the local network.
    • If the MID Server is unavailable, agents fall back to the Install Server at https://install.service-now.com. To enable agent fallback, ensure that the install server is specified on the ServiceNow instance.

    If your agents use a custom download server, configure the agent-upgrade-url-path key in the agent's acc.yml file. This setting takes priority over the default sources.

    Rollout strategy

    Use a phased approach to reduce risk when upgrading a large agent fleet:

    1. Upgrade one agent from the UI to confirm the process works end-to-end.
    2. Upgrade 5–10 agents from the list view, selecting agents across different operating systems.
    3. Perform a full rollout by enabling the scheduled job or running the background script.