Update the server agent | Docs

Updating the Kabeen server agent means reinstalling the latest package over the existing version. The operation is done in place: the binary is replaced, the service restarts automatically with the new version, and the configuration and host identity are preserved.

No reconfiguration needed. The config.toml file (under C:\ProgramData\Kabeen\Server Agent\ on Windows, /etc/kabeen-server-agent/ on Linux) is never overwritten by an update. The API key and the agent identity (agent_id) remain unchanged: the machine keeps reporting under the same identifier in the Kabeen console and does not reappear as a new host.

Check the installed version

Before and after updating, check the version in place.

Windows (administrator PowerShell):

Get-Package -Name "*Kabeen*" | Select-Object Name, Version

The version is also visible under Control Panel > Programs and Features.

Linux (Debian / Ubuntu):

dpkg -l kabeen-server-agent

Linux (Red Hat and derivatives):

rpm -q kabeen-server-agent

The Kabeen console also displays the agent version reported by each host (Infrastructure > select the server).

Download the latest package

The download links always serve the latest published version. Get the package for your operating system:

Platform	Download link
Windows (MSI)	Link
Linux (DEB)	Link
Linux (RPM)	Link

Update on Windows

The 3.0 MSI installer handles a major upgrade: simply run the new MSI — it cleanly removes the old version, then installs the new one while keeping config.toml.

In interactive mode, double-click the new MSI and follow the wizard. The Kabeen API key screen can be left blank: the key already present in config.toml is preserved.

In silent mode (administrator PowerShell):

msiexec /i "kabeen-server-agent-x86_64.msi" /qn /norestart

Do not pass the APIKEY parameter during an update: the existing key is enough. It is only useful to (re)set the key when config.toml does not yet contain one.

The KabeenServerAgent service is stopped and restarted automatically by the installer.

Updating at scale via GPO

For a domain-joined Windows fleet, the update propagates through the same software-installation GPO used for the initial deployment, by declaring the new MSI as an upgrade of the old package.

Copy the new MSI to the network share used by the GPO (keep the old package until the upgrade is complete):
```
\\server\share\kabeen\kabeen-server-agent-x86_64.msi
```
Open the Group Policy Management console, edit the deployment GPO, and go to Computer Configuration > Policies > Software Settings > Software installation.
Right-click > New > Package, select the new MSI via its UNC path, then choose the Assigned method.
Open the new package's Properties > Upgrades tab > Add, and select the old package. Choose Uninstall the existing package, then install the upgrade package, and tick Required upgrade for existing packages.
On a test server, force the update then reboot (GPO software installation applies at startup):
```
gpupdate /force
```

The config.toml file (API key and agent identity) lives under C:\ProgramData\ and survives the upgrade: no additional configuration GPO is needed. Unlike the first deployment, there is no need to re-set the API key.

For the initial GPO deployment, see Installing the server agent via GPO.

Updating via Microsoft Intune

For servers managed by Microsoft Intune, the update means publishing the new version of the package; Intune then deploys it automatically to the target machines at their next check-in.

Sign in to the Intune admin center.
Apps > All apps, then select the existing Kabeen Server Agent application (Line-of-business MSI app).
Properties > App information section > Edit, then upload the new MSI (whose product version is higher than the one in place).
Save. Intune relies on the MSI product version for detection: it installs the new version over the old one on devices whose assignment is Required.

If the agent was packaged as a Win32 app (.intunewin) rather than a line-of-business app, publish the new version as a separate app and declare it as a supersedence of the old one.

No configuration profile to change. The server agent does not rely on ADMX templates (unlike the user agent): its API key and identity are preserved in config.toml. Only the application package needs to be updated. As with any Intune deployment, allow a propagation delay of 24 to 48 hours.

Update on Linux (Debian / Ubuntu)

Installing the new .deb package over the old one performs the upgrade; files under /etc/kabeen-server-agent/ are preserved:

sudo apt-get install ./kabeen-server-agent_amd64.deb

The package restarts the kabeen-server-agent.service unit with the new binary.

Update on Linux (Red Hat and derivatives)

sudo dnf upgrade ./kabeen-server-agent.x86_64.rpm
# or, on distributions without dnf:
sudo rpm -U kabeen-server-agent.x86_64.rpm

As on Debian, the configuration is preserved and the service is restarted automatically.

Updating from a legacy agent (2.x / Kapsul)

Moving from a legacy agent (Kapsul 2.x, application.conf configuration, .exe service) to the 3.0 server agent is not a simple package update — it is a migration. Install the 3.0 server agent alongside it: it automatically imports the API key and the agentUUID of the legacy agent on first start, preserving the host identity, after which you uninstall the legacy agent.

The detailed procedure is described in Manual installation of the server agent.

Verify after updating

Check that the service is running and that the new version is in place.

Linux:

sudo systemctl status kabeen-server-agent.service
sudo journalctl -u kabeen-server-agent.service -f

Windows (administrator PowerShell):

Get-Service -Name KabeenServerAgent

The logs should show All tasks running. Agent is operational., and the machine should keep reporting in the Kabeen console with a recent heartbeat (less than 2 minutes) — under the same identifier as before the update.

For the first installation, see Manual installation of the server agent. To remove the agent, see Uninstall the server agent.