Archive and Cleanup parameters
Archive and Cleanup operations move older session data out of the primary Syteca database. The Cleanup operation removes it entirely; the Archive and Cleanup operation moves it to a separate archived database first, then removes it from the primary database. Both operations share a set of parameters configured on the Configuration page.Where to configure
- Click the Configuration button at the top of the Management Tool interface.
- On the Configuration page, select the Database Management tab.
- Scroll to the Archive Parameters section.
Archive Parameters section. Configures both Cleanup and Archive & Cleanup operations from a single place.
Parameters applied to Archive & Cleanup for both PostgreSQL and MS SQL Server
These parameters are needed when the Archive & Cleanup operation is used. They point Syteca at the archive destination.Parameters applied only to Archive & Cleanup on MS SQL Server
Parameters applied to both Cleanup and Archive & Cleanup
If binary storage uses Amazon S3-like storage, see Configure Syteca to Store Binary Data in Amazon S3 for the specific bucket, access key ID, and secret access key configuration.
Clean up sessions of deleted Endpoints
When a Endpoint is deleted from the Management Tool, most of its data leaves with it. In certain edge cases the Endpoint’s sessions can remain in the database as orphaned records. Use the Server Tray application on the Application Server computer to clean up these leftovers.1
Open Database Parameters from the Server Tray
On the Application Server computer, right-click the Syteca Server tray icon in the Notification area and select Database Parameters.The Database Parameters application (
DbSetupToolUI) opens.2
Open the Advanced tab
In the Database Parameters application, select the Advanced tab.
3
Start the cleanup
Click Clean up lost sessions. The cleanup runs against the Syteca database and removes orphaned session records from deleted Endpoints.
The cleanup can take a long time for large databases. Progress is visible in the Management Tool, on the Tasks List tab of the System Health page. Verify completion there before assuming the operation is done.
PostgreSQL autovacuuming
PostgreSQL requires periodic maintenance called vacuuming. Vacuuming reclaims storage used by rows that are no longer visible to any transaction, and updates statistics the query planner relies on. Without vacuuming, PostgreSQL databases slowly bloat and query performance degrades. The Autovacuum Daemon is a set of PostgreSQL processes that vacuum the database automatically based on activity thresholds. It is enabled in the default PostgreSQL configuration and, in most Syteca deployments, requires no intervention.When to change autovacuum settings
Adjust autovacuum settings when the Application Server writes are heavy and default autovacuum tuning is not keeping up with the churn. Symptoms include:- Growing database size that outpaces retention-based expectations.
- Slowing query performance as tables accumulate dead rows.
- Autovacuum log entries indicating the daemon is running frequently and taking a long time to complete.
How to change autovacuum settings
Autovacuum settings live in the PostgreSQL configuration filepostgresql.conf. The location of postgresql.conf varies by operating system and PostgreSQL install method. Common locations:
1
Locate postgresql.conf on the database host
Find the
postgresql.conf file on the database server. Use the platform-specific paths above as a starting point.2
Edit the autovacuum settings
Open
postgresql.conf in a text editor with administrator or root permissions. Search for the settings beginning with autovacuum_ and adjust them according to the PostgreSQL documentation on the autovacuum daemon.3
Restart the PostgreSQL database
Restart the PostgreSQL database service for the changes to take effect. Configuration changes to
postgresql.conf are read at PostgreSQL start.Recreate the ActivityDB database and attach it as an archived database
1
Log in to the Application Server computer
Log in to the machine where Syteca Application Server is installed.
2
Stop the Application Server
Stop the EkranServer service.
3
Restart the database service
Restart your database service to close all existing connections to it.
4
Rename the existing ActivityDB database
- MS SQL Server
- PostgreSQL
In SQL Server Management Studio, expand Databases, right-click
EkranActivityDB, select Rename, and enter a new name.5
Restart the database service again
Restart the database service now that the rename is complete.
6
Start the Application Server
Start the EkranServer service. Since the original
EkranActivityDB was renamed, Syteca creates a new, empty EkranActivityDB under the original name.7
Connect the renamed database as an archived database
Log in to the Management Tool, open Configuration > Database Management, and connect the renamed database as an archived investigated database. See Archived Sessions for how archived databases are viewed afterward.
Vacuum the PostgreSQL database manually
1
Log in to pgAdmin
Open pgAdmin and connect to the PostgreSQL server.
2
Stop the Application Server
Stop the EkranServer service in Windows Services.
3
Run a full vacuum
Right-click
EkranActivityDB, select Maintenance > Vacuum > Full, and click OK.4
Restart the Application Server
Once the vacuum completes, restart the EkranServer service.
How long do cleanup operations take?
Cleanup and Archive & Cleanup duration depends on how many sessions are in the database, their size, and where the archive instance is located. As a rough estimate: archiving a session whose screen captures are stored in the database takes 3 to 6 minutes; a session whose screen captures are stored in a shared folder takes under a minute.IN SAAS ONLY: only the Cleanup operation is available — Archive & Cleanup isn’t offered in SaaS.
Upgrade from an older MS SQL Server version
To move a Syteca database from an older MS SQL Server version (for example 2008 R2) to a newer one, back it up on the old server and restore it on the new one using SQL Server Management Studio (SSMS). This procedure applies to any older-to-newer MS SQL Server version transfer.1
Connect to the source server
In SSMS, click Connect > Database Engine, and enter the credentials for the source MS SQL Server.
2
Back up the database
In Object Explorer, right-click the required database (for example
SERVER.EkranManagementDatabase), select Tasks > Back Up.3
Set the backup location
Click Add, then the … button, choose a location and file name, and click OK.
Note the backup location — you’ll need it in a later step.
4
Connect to the destination server
Connect to the destination MS SQL Server the same way as in step 1.
5
Create a new database with the same name
Right-click Databases, select New Database, and enter the exact same database name as the one backed up.
6
Restore from the backup
Right-click the new database, select Tasks > Restore > Database. Under Source, select Device, click the … button, Add, and select the backup file.
7
Relocate the database files
On the Files page of the restore dialog, select Relocate all files to folder.
8
Allow overwriting
On the Options page, select Overwrite the existing database (WITH REPLACE).
9
Complete the restore
Click OK. A confirmation message appears once the restore succeeds.
Relocating database files during restore in SQL Server Management Studio.
Shrink the MS SQL database transaction log
1
Open Database Management
Log in to the Management Tool as a user with the administrative Database Management permission, click Configuration, then select the Database Management tab.
2
Shrink the log
Click Shrink Transaction Log at the bottom of the page.
No progress indicator is shown, and there’s no notification when shrinking completes.
Set up hash-code calculation for monitoring data validation
This enables the hash-code option described in Validate monitoring data integrity above — a lighter-weight alternative to certificate signing.- Version 6.53.1 and later
- Versions before 6.53.1
1
Stop the Application Server
Right-click the Syteca Server tray icon and select Stop, or stop the EkranServer service via Task Manager.
2
Add the key to the config file
Open
EkranServer.Settings.config (by default in C:\Program Files\Ekran System\Ekran System\Server) and add:3
Start the Application Server
Start the EkranServer service again.
Set up certificate signing for monitoring data validation
This completes the certificate-signing option described in Validate monitoring data integrity above. Do the following on the Application Server computer.1. Import a trusted certificate
1
Open the Certificates snap-in
Press Windows+R, enter
mmc, press Enter, and click Yes on the User Account Control prompt. Select File > Add/Remove Snap-in, choose Certificates, and click Add.2
Target the local computer account
Select Computer account, click Next, select Local computer: (the computer this console is running on), and click Finish, then OK.
3
Import the certificate
Under Certificates (Local Computer), right-click Personal, select All Tasks > Import, and step through the Certificate Import Wizard: browse to the certificate file, enter its private key password if prompted, and finish the wizard.
4
Copy the certificate's thumbprint
Under Certificates (Local Computer) > Personal > Certificates, double-click the imported certificate, select Details > Thumbprint, and copy the value shown.
2. Enable signing with the certificate
- Version 6.53.1 and later
- Versions before 6.53.1
1
Stop the Application Server
Right-click the Syteca Server tray icon and select Stop, or stop the EkranServer service via Task Manager.
2
Add the key to the config file
Open
EkranServer.Settings.config (by default in C:\Program Files\Ekran System\Ekran System\Server) and add:3
Start the Application Server
Start the EkranServer service again.
Delete the PostgreSQL database manually
If the PostgreSQL database wasn’t removed automatically when the Application Server was uninstalled, delete it manually. Only the database owner or a superuser can do this.1
Restart the PostgreSQL server
Restart the PostgreSQL server before deleting the database.
2
Open pgAdmin
Start pgAdmin and connect to the server.
3
Select the databases to delete
In the Browser pane, select the database to delete. By default, Syteca uses two databases:
ekranactivitydbekranmanagementdatabase
4
Delete each database
Right-click each database and select Delete/Drop, then click OK to confirm.
Validate monitoring data integrity
Monitoring data validation confirms that screen captures and metadata received from Windows Endpoint haven’t been altered in the database. It’s available for both PostgreSQL and MS SQL Server. Two validation types are available:- Calculate hash codes — a hash is calculated for each screen capture and metadata record received.
- Sign with a certificate — each screen capture and metadata record is signed with a trusted certificate.
If both are enabled, only certificate signing is actually used.
Enabling validation increases CPU usage while viewing sessions in the Session Player. Screen captures won’t display for existing sessions that hadn’t been viewed before validation was enabled.
Isolate the database from Endpoints
Isolation mode temporarily disconnects every Endpoints from the database, useful when fixing database issues, running cleanup, or performing maintenance. While isolated, Endpoints keep monitoring and write data to their local cache until reconnected.Only available to users of the built-in default tenant with the administrative Tenant Management and System Configuration permission — for example, members of the Administrators user group.
1
Open System Health
Click System Health, then the drop-down next to the System State tab.
2
Enable isolation
Select Isolate Database from Endpoints.
1
Open System Health
Click System Health, then the drop-down next to the System State tab.
2
Disable isolation
Select Stop Isolating Database from Endpoints (or click the here link in the notification banner shown at the top of every page while isolation is active).
Related
Application Server troubleshooting
Diagnose Application Server issues, including database connection loss and Management Tool availability errors.
Application Server resource monitoring
Watch the database write queue and storage usage in real time from the System State page.
System requirements
Database sizing, supported PostgreSQL and MS SQL versions, and network port requirements.
Shared storage HA
Move screen captures out of the database to shared storage, reducing database growth substantially.