Server Sensor Update Behavior through an Aggregator

In environments where a Modular Sensor is configured as an aggregator, Server Sensors can be deployed to communicate through this intermediary device rather than directly with the Data Processor (DP). The aggregator retrieves update files from the DP and, depending on sensor type, relays them to the requesting sensor. Aggregators can be deployed as standalone devices or in a high availability (HA) pair. The presence of an HA configuration does not change the update behavior described in this section.

Windows Server Sensors connect directly to the DP to retrieve both update and upgrade files, even when an aggregator is present in the deployment. They do not rely on the aggregator for any part of the update process. In contrast, Linux Server Sensors are designed to retrieve update and upgrade files exclusively through a configured aggregator. They never establish direct communication with the DP for update purposes.

Each Server Sensor operates an internal scheduler that runs independently on the sensor itself. This scheduler periodically checks for available updates—typically every 30 minutes—and initiates the retrieval of necessary files such as software packages, configuration files, or rule updates.

In this section, you can learn how update requests are initiated, which paths are used to retrieve update files based on sensor type, and the retry behaviors that occur when communication issues are detected.

Scheduled Updates through an Aggregator

When a Windows Server Sensor or Linux Server Sensor is deployed with an aggregator, the update process follows four main steps:

  1. A Server Sensor initiates a request to check for updates.

    Every 30 minutes (by default), the scheduler runs on the Server Sensor and checks the DP for available updates.

    • Download Operations: The Server Sensor connects directly to the DP without attempting aggregator access.

    • Upgrade Operations – Windows Server Sensor: Connects directly to the DP.

    • Upgrade Operations – Linux Server Sensor: Uses the configured aggregator only. No fallback to direct DP connection.

      Operation Type

      Sensor Type

      Behavior
      Download Windows or Linux Connects directly to the DP
      Upgrade Windows Connects directly to the DP
      Upgrade Linux Uses aggregator only

  2. The DP responds to the sensor with update tasks.

    The DP delivers update tasks directly to Windows Server Sensors and routes them through the aggregator for Linux Server Sensors. In both cases, the DP provides information on available updates, including new software versions, configuration files, and security rule updates.

  3. The Server Sensor downloads update files.

    Windows Server Sensors download update files directly from the DP. Linux Server Sensors, in contrast, retrieve files through the aggregator. The downloaded files are stored in the C:\ProgramData\StellarCyber\Windows Agent Sensor\config and C:\ProgramData\StellarCyber\Windows Agent Sensor\aella_update\tmp directories on Windows and the /etc/stellarcyber/ directory on Linux.

  4. The update process is logged in aella_update.log.

    This log captures each update cycle initiated by the scheduler, including download attempts, successes, retries, and failures. The behavior and log content differ by sensor type:

    • Windows Server Sensors log direct communication with the DP. Log entries include the outcome of connection attempts and any retries following transient failures. Because these sensors do not use the aggregator for downloads or upgrades, there are no aggregator-related entries in the log.

    • Linux Server Sensors log update activity through the configured aggregator. These sensors never attempt direct communication with the DP. If the aggregator is unavailable, the sensor logs retry attempts—either to the same aggregator or, if configured for HA, to the other member in the HA pair. No fallback to the DP is attempted or logged.

Downloaded Update Files

During an update, a Server Sensor might download the following files:

Files

Purpose
ds_tasks.json Checks for pending update tasks on the DP.
.msi/.msp files Update packages for upgrading to a new software version (Windows only). Also included is the download_image.exe file, which is extracted after download and used to retrieve updates from the DP.
Custom parsers Files that update the ability of the sensor to process and normalize logs.

Threat intelligence updates

Updated detection rules and heuristics for security analysis.

Update Retry Behavior

Retry behavior varies by sensor type.

Windows Server Sensor Retry Logic

Windows Server Sensors retrieve updates and upgrades by connecting directly to the DP. If the initial connection fails or specific file requests encounter errors, the sensor automatically retries the request. Common scenarios that trigger retries include the following:

  • A network interruption prevents connection to the DP.

    If the Windows Server Sensor cannot establish a connection with the DP—due to temporary network latency, packet loss, or DNS resolution issues—it retries the connection based on its internal schedule. These retries are logged in aella_update.log.

  • TCP port 8443 is blocked or experiencing packet loss.

    Update communication with the DP requires TCP port 8443 to be open and stable. If the port is intermittently blocked by firewall policy or the connection is degraded, the sensor might fail the initial attempt and retry until successful.

  • The DP is temporarily unreachable.

    If the DP is undergoing maintenance, restarting, or experiencing high load, the sensor might be unable to retrieve the update manifest or files. It logs the failure and continues retrying on the next scheduler cycle.

  • The sensor encounters a partial or corrupt download.

    If the Windows Server Sensor downloads a file such as ds_tasks.json or a software package and detects that the file is incomplete or malformed, it automatically retries the request in the next cycle.

Linux Server Sensor Retry Logic

Linux Server Sensors are configured to retrieve updates exclusively through a Modular Sensor acting as an aggregator. These sensors do not initiate direct connections to the DP under any condition. When communication with the aggregator fails—whether due to network issues, aggregator downtime, or other disruptions—the sensor automatically retries the request based on its internal logic.

Retries are performed using the assigned aggregator configuration, and in HA deployments, the sensor alternates between the primary and secondary aggregator nodes. The retry process continues until a successful connection is established or the retry cycle completes.

Linux Server Sensors never bypass the aggregator to communicate directly with the DP, even if both HA nodes are unreachable.

  • A communication failure occurs.

    If the Linux Server Sensor cannot retrieve update files from the configured aggregator, it retries the request. When a single standalone Modular Sensor is configured as the aggregator, the sensor retries communication with that device. If an HA pair is configured, the sensor attempts the primary member first and, upon failure, retries with the secondary member.

  • TCP port 8443 is blocked between the aggregator and the Data Processor.

    The aggregator must have TCP port 8443 open to access update files on the Data Processor. If this port is blocked, the sensor cannot complete the update operation.

  • The aggregator is temporarily unavailable.

    If a standalone aggregator is offline or if both nodes of an HA pair are unreachable, the sensor cannot retrieve updates and will retry until successful. Linux Server Sensors do not use direct communication with the Data Processor as a fallback source.

  • Initial download attempt fails.

    If the sensor encounters an error while downloading ds_tasks.json or another update file, it automatically retries the request through the configured aggregator. Failover within an HA pair, if present, is handled automatically.

Summary

Windows Server Sensors configured in environments with an aggregator still connect directly to the DP to download updates and upgrades; they do not rely on the aggregator. Linux Server Sensors, by contrast, retrieve update and upgrade files exclusively through a configured aggregator. If communication issues occur, Windows Server Sensors retry direct DP communication, while Linux Server Sensors retry communication with the aggregator and, if configured for HA, the other node in its HA pair. Linux Server Sensors do not fall back to direct DP communication under any condition. All update attempts, retries, and failures are recorded in the aella_update.log file on the sensor host.

Maintaining open connectivity with the DP on TCP port 8443, monitoring update logs for retry patterns, and ensuring stable network access are essential to support consistent update operations. For troubleshooting, refer to System | Logs in the Stellar Cyber UI or examine aella_update.log on the Server Sensor host.