Replication limitations

Solution Installation > TSS Installation

Only database and a few other settings are synchronized between primary and replicated TSS.

What is synchronized

•Database content: Users and devices profiles, settings (including boot settings), lines ...

•Devices to zone association

•Devices to TSS "affinity"

•Devices logs (since devices syslog at the same time on both TSS)

What is not

•Firmware, bootstraps and OS upgrades packages

•Firmware, bootstraps and OS upgrades configured default versions

•Firmware, bootstraps and OS upgrades configured versions by zone

•Pictures: Turret background and screensaver images

•Debug information dumps

•TSS Reports

•Exports generated by job policies


		Although job policies are replicated, only primary TSS will execute them. That means that generated files are always available on the primary TSS only and if primary TSS is down, scheduled tasks are not executed at all.

Broken replication

Network issues that prevent communication between both SQL Servers, disk full or other external issues may break the SQL replication. Most of the times replication recovers by itself once the root problem is solved but under certain conditions (e.g. amount of "missed" data is too large or the failure occurred at the wrong time) it may need the intervention of an administrator.

The consequence of a broken replication is that either the full database or a few tables are not being synchronized anymore which may lead to real issues later on.

The recommended way to repair replication is to deactivate then re-activate it (see Database Replication for standard server or Replicate/Unreplicate for virtual appliance).

SQL Experts may also try to figure out the issue(s) reading logs and fix them manually at their own risks.