Skip to content
Thirdlane

System Update

The System Update Manager lets administrators check for and apply Thirdlane platform updates directly from Configuration Manager, without logging into the server shell. Keeping the platform current delivers security fixes, bug fixes, and new features; doing it from the UI means you can see the installed and available versions at a glance and apply updates in a controlled, logged way.

Checking for Updates

The Update Manager connects to the Thirdlane update repository to determine whether a newer version of the platform is available. The current installed version and the latest available version are displayed for comparison.

Applying Updates

When an update is available, you can initiate the update process from this page. The system will download and apply the update packages, then report the result.

It is recommended to perform a Backup before applying updates. Schedule updates during a maintenance window to minimize impact on active calls.

Updating a redundant pair

If this server is one of a redundant pair, update the active server first and the standby second.

An update applies any changes the new version needs to the structure of the databases, and on a pair those changes travel from the active server to the standby through the continuous copy between them. The standby therefore does not apply them itself - when you update it, it recognises that it is following the other server and leaves both databases alone, and its telephony services stay stopped rather than restarting. Updating the active server first is what puts the changes in the place they can spread from.

This screen keeps working on the standby even though the rest of its Manager refuses configuration changes, because installing packages affects only the machine you are on. Each server is updated from its own Manager; there is no way to update one server from the other.

After updating both, open System Settings > Redundancy on each server and confirm the check named Both servers run the same release passes. The standby also states which release the active server reported, so it is the better of the two screens to check.

Operating-system updates are the opposite: do the standby first, because it is not carrying calls. Full details, including what happens in the window where the two servers differ, are on the Standby Server page.

Update History

Previously applied updates and their status are recorded for reference, allowing you to track the update timeline for your installation.

Best practices

  • Back up first, every time. Take a Backup (or a virtual-machine snapshot) before applying an update so you can roll back if something goes wrong.
  • Update during a maintenance window. Some updates restart services and can briefly interrupt active calls; schedule them for off-peak hours.
  • Update a staging/test system first where possible, then production, to catch surprises before they affect users.
  • Read the release notes for the target version so you know what is changing and whether any follow-up configuration is needed.
  • In a cluster, confirm sync afterward. After updating, check Data Sync to verify all servers are on the expected version.
  • On a redundant pair, update the active server first. Then the standby, and check the release match on the Standby Server screen when both are done.