Status

The service consists of several modules, each one publishing its own status. When all modules are healthy, the Status of the service is Healthy and that is shown with a green smiley. The smiley is also shown across the other pages in the upper right corner of the main menu.

The status may vary between; Initializing, Waiting, Healthy, and Unhealthy. If the service is not healthy, the status report will show a summary that explains where problems may be.

The current version of the BaseAgent Service running on the client is shown with the first date that the BaseAgent was installed and the time of the last update.

The uptime field shows how long the service has been running.

The Product version shows the version of the installed CapaInstaller (from the SQL server).

The Management Point shows where the client belongs in the installation along with the CMPID of the point.

The Operating system is shown with the version.

The Base Agent configuration can have 1 or 2 Front-ends configured, The Internal URL for use internally on the local network (primary) and the Public URL for use when there is no connection to the Internal URL, which is a typical situation for client computers that have been taken out of the office (Home, on the train, in a coffee shop, etc.)

Connected To shows which (if any) Front-end URL that the BaseAgent is currently connected to and the duration of the connection.

The Agent ID is the unique identifier that the BaseAgent uses to communicate with a Front-end Server and it is derived from the UUID of the Motherboard of the computer.

The Client describes the last connected client that has communicated with the BaseAgent.

The component that actually executes the agent is the script agent and while it doesn't communicate it's status directly to the BaseAgent service, the service polls the registry keys that the script agent is using in order to display changes and let the onlooker (you) get a sense of what is going on. In short, it shows the product version and build, the state that it is in. Lastly, it shows the latest (or active) job and the status of the last completed job. 

The communication between the Front-end Server and the is bidirectional, but because the Front-end is not guaranteed to be in proximity of the Client, it is not able to initiate a connection to the Base Agent and can therefore not directly tell the Base Agent to restart the agent (CallHome) or to get Distribution Server Configuration or do a preload of files (also DS). For that purpose, the Base Agent initiates Select call (HTTP request) to the Front-end which will leave the request hanging for somewhere between 1 and 1½ minutes or until there is a UnitCommand waiting for the client. If there is a UnitCommand waiting, it will be returned in the response to the (hanging) request. If there is not unit command for the client, the request will time out. When the Base Agent gets a response, with or without content, it will initiate a new request to the Front-end Server. The Front-end Server also uses the frequency of the Select call to maintain the Online status of each Base Agent.

The 'Select calls' section shows wether a select call is active or not and when the last request was sent. It also shows the last command received and the timestamp for that along with the average timeout for Select call requests. When the Base Agent receives a CallHome UnitCommand, it keeps the command until the CapaInstaller Stub service (CiStub) collects it and that is shown as 'Last command delivered'.

The settings section shows the Base Agent general settings.

The HttpClient module is responsible for holding a connection with a Front-end Server, and if the module is faulty (for any reason), the Module manager will replace the module when the module has been faulty for the 'HttpClient recovery' period. The Service recovery is the maximum time that the service can be unhealthy before the service will restart itself.

The 'Max history events' is the event horizon used when cleaning up the history files shown in the History tab. When the Base Agent is requested to upload a file and that file fits the lits of file extensions of the BomDetection files, the Base Agent will determine the 'Content-type' via Byte-Order-Marks.

The Max file jobs is the limit of fileJobs to be held in memory (shown on the Jobs tab). 

The level of messages written to the log file can be either Info (brief), Debug (detailed), or Trace (explicit).

Lastly, the time format to be used in the log file is shown.

File share enabled, determines if the Base Agent is Peering with other nearby Base Agents and File Store enabled tells if the Base Agent should advertise itself to other Base Agents as a dynamic file-hub.

This is useful for smaller locations because it gathers file requests to the Front-end Server in the same way as the Distribution Server does but is only available for Base Agents that can be reached by UDP messages. This means that Base Agents will select a File Store as the third choice when searching for files after the internal File cache and other Base Agents (peering). This role is typically given to a computer that is always on/connected.

File share max requesters are the number of maximum files that a file-sharing Base Agent will advertise to other Base Agents as it's limit. At the same time, Base Agent announces it's a current number of requesters in real-time (UDP). Requesting Base Agents are then able to avoid requesting a file for download for a peering BaseAgent that has already reached its (File share max requesters) limit and instead of requesting the file from an idle or less utilized Base Agent. 

Filestore max requesters act in the same way as the File share max requesters, though it is only advertised by Base Agents with the Filestore enabled.

The File share cloud size shows how many other Base Agents to keep track of.

When/if the Base Agent is looking for a file, at it ends up requesting the file from a File Store, it can be the first client to request that file but if the file is of substantial size or the file transfer from the Front-end Server to the FileStore is slow, it may not be the first Base Agent in line for the file. The FileStore retry delay is the time from which the requesting Base Agent will have to pause after the FileStore has downloaded the file before re-asking nearby peers for the file and ultimately requesting the file once again from the File Store.

The File share files is a list of file extensions of which the Base Agent is publishing when entering/updating it's 'cloud-membership'. When a Base Agent has downloaded a file with an extension included in the list, it will re-announce itself along with an updated file list that includes the newly-downloaded file.

The Peer request timeout is the 'ping' timeout when querying other Base Agents for files.

Having File share enabled means both consuming files from other Base Agents and publishing own files to other Base Agents for consumption. For computers connected to a Front-end Server on a Wi-Fi connection, however, you may not want it to actively share it files because it can draw a lot of bandwidth. In an environment where some of the Base Agents are wired and some are on Wi-Fi, you may prefer only the wired Base Agents to share its files.

Peer naming indicates how a requesting Base Agent creates HTTP requests to other Base Agents. It can be (Auto, FQDN, IPv6, or IPv4).

UDP ports show which ports the Base Agent will announce itself in the File share/store cloud.

Upon startup, the Base Agent will always check with the Front-end Server for a newer version of itself and auto-update if necessary. In addition to that, the Base Agent will periodically check the Front-end Server and before each check, it will first query the File module for activity. The min silence is the time that the file module must have been without activity before checking for new versions. This is done to avoid the Base Agent updating itself in the middle of an agent run. If the update routine has been put off by the min silence setting for a long time (longer than max silence) an update check is performed regardless.

The Service runs from the Service Folder (See Files & Folders section below), in which the version number is a part. When updating the service, the new instance is placed next to the running instance and then the service record is manipulated to point to the new instance in the new folder. After that, the service is restarted and will start the new version, leaving the old version abandoned. Versions to keep is used to clean up old versions, preserving a number of old versions in the unlikely case of the need to roll back.

The Files & Folders section is a simple list, telling where the Base Agent is configured to store, access and write files. 

Other sections

The rest of the sections in the Status tab shows a summary of files and data being uploaded, downloaded and shared among peering Base Agents, File Stores, Distribution Servers and Front-end Servers.