> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Install the Application Server
> Step-by-step installation of the Syteca Application Server on Windows — Setup wizard walkthrough, database selection (PostgreSQL / MS SQL Server), Master Certificate generation, Windows Firewall configuration, cloud deployment notes, and external/cloud-based AS setup.
The Syteca Application Server is the central service every Client connects to and every Management Tool reads from. This page walks the on-premises installation end-to-end — Setup wizard, database selection, Master Certificate generation, administrator credentials, and post-installation network configuration including Windows Firewall, cloud deployments, and external-network deployments.
**NOT AVAILABLE IN SAAS.** Syteca SaaS deployments have the Application Server pre-installed and managed by your vendor — customers don't perform these steps. This procedure applies to **on-premises** deployments only.
**Before starting:** Confirm the host meets the [system requirements](/docs/get-started/system-requirements) and has **.NET 8.0 Runtime + ASP.NET Core 8.0 Runtime** installed (for Syteca v.7.23 and higher) or **.NET Framework 4.8** (for older versions). The Setup wizard's Requirements page detects missing components and provides download links — but installing them ahead of time avoids back-and-forth restarts.
## Run the Setup wizard
Run **`Syteca_Server.exe`** to open the **Syteca Setup** wizard. Click **Next** on the **Welcome to Syteca Setup** page.
On the **License Agreement** page, read the End User License Agreement carefully, then click **I agree**.
On the **Requirements** page, the wizard checks for **.NET Runtime 8.0** and **ASP.NET Core 8.0 Runtime** (for Syteca v.7.23 and higher).
* **Yellow triangle icons** indicate missing components — click the links on the page to install each, then click **Refresh**.
* **Green checkmark icons** indicate satisfied prerequisites.
Click **Next** when all icons are green.
On the **Choose the Installation Mode** page, select:
* **New Syteca Application Server** — for the first Application Server in the deployment.
* **Add Application Server to existing deployment** - for adding additional Application Server instances in [High Availability](/docs/administration/deployment/high-availability) or large-deployment configurations.
Click **Next**.
On the **Choose Install Location** page, enter the installation path or click **Browse** to navigate to it. The default path is `C:\Program Files\Ekran System\Ekran System\`. Click **Next**.
If more than one Master Certificate (named `EkranMasterCertificate`) is detected in the Windows Certificate Store — e.g. from a previous installation that wasn't cleanly removed — the wizard displays a warning, and installation cannot proceed until the unnecessary Master Certificates are [deleted](/docs/administration/security/master-certificate#delete-the-master-certificate).
On the **Syteca Master Certificate** page:
* **Generate a new certificate** — for the first Application Server in a deployment.
* **Use an existing certificate** — for subsequent Application Server instances in High Availability or multi-instance deployments. Use the Master Certificate from the first instance.
The **Syteca Master Certificate** (`EkranMasterCertificate`) is the root of Syteca's encryption hierarchy. It must be generated during the first installation and **backed up immediately afterwards** — see [Back up the Master Certificate](/docs/administration/security/master-certificate#back-up-the-master-certificate). Loss of the Master Certificate means the database becomes unreadable; there is no recovery mechanism.
Click **Next**.
On the **Database Type** page, select **PostgreSQL** or **MS SQL Server**. See [Comparison of database types](/docs/administration/database/compare-databases) for the differences.
If you already have a Syteca database from a previous installation, select its type and define the connection parameters to reuse it.
Click **Next**.
On the database configuration page:
* **Server instance** — hostname or IP address (use `localhost` for the default PostgreSQL instance). Append a custom port with a colon: `:`.
* **User name** / **Password** — credentials for the database user. By default, the `postgres` user with the password defined during PostgreSQL installation.
* **Use encrypted connection** *(optional)* — select to enable SSL between Application Server and database. **A certificate for the database server must be configured and imported as trusted on this computer before selecting.**
* **Server instance** — hostname or IP address. Use just the machine name for the default instance. Append a custom port with a comma: `,`.
* **Authentication** type:
* **SQL Server Authentication** — use either `sa` (system administrator) credentials or a user with the `dbcreator` permission.
* **Windows Authentication** — enter `\` and the password. The user must already exist in MS SQL Server with **system administrator** permissions.
* **Use encrypted connection** *(optional)* — same caveat as PostgreSQL.
Click **Next**.
On the **Binary Data Location** page, choose where screen captures and other binary monitoring data are stored:
* **SQL Database** — stores binaries inside the database. **Not recommended** except for small deployments because of accumulation over time.
* **File system** — stores binaries in a folder on the Application Server or a network share.
* **Amazon S3-like storage** — stores binaries in an S3-compatible bucket. See [Configure Amazon S3 binary storage](/docs/administration/database/binary-storage-s3) for the additional configuration.
If the wizard displays an **SMBv2 update warning** for a File System share (when installing Syteca 7.23 or higher), see [Application Server issues and error messages](/docs/resources/troubleshooting/application-server-troubleshooting) for the resolution.
On the **Syteca Database Names** page, define unique names for the Syteca databases.
Internally, Syteca creates three separate databases. The names you set here apply as a prefix.
If a database with the same name already exists (from a previous installation), the wizard offers to reuse it:
* **Yes** — keeps the existing database and data.
* **No** — deletes the existing database and creates a new one. **Data is lost.**
On the **Administrator credentials** page, define the credentials for Syteca's built-in **admin** user (the administrator of the built-in default tenant):
* **Login** — defaults to `admin`. Can be **5–50 characters**, letters and numbers only, or an email address.
* **Password** / **Confirm password** — **at least 8 characters**, with **at least one lowercase letter, one uppercase letter, one numeric character, and one special character**. Cannot contain more than 3 consecutive identical characters.
These credentials can be changed later on the [Users](/docs/administration/users/users) page.
Click **Next**.
On the **Syteca Client Uninstallation Key** page, enter the key used for [local Client uninstallation](/docs/administration/clients/uninstall#the-client-uninstallation-key). Click **Next**.
Click **Install** to start installation. When the **Installing** page completes, click **Finish** to exit the wizard.
## Post-installation tasks
Three things to do **immediately** after installation completes:
[Back up the Syteca Master Certificate](/docs/administration/security/master-certificate#back-up-the-master-certificate) — required for Application Server recovery, system updates, computer migration, and High Availability cluster creation. **The database is unreadable without this certificate.**
If you reused an existing database from a previous installation, **delete the newly-generated Master Certificate** and **import the backup of the original Master Certificate** — otherwise the new certificate can't decrypt the existing data. See [Delete the Master Certificate](/docs/administration/security/master-certificate#delete-the-master-certificate) and [Import the Master Certificate](/docs/administration/security/master-certificate#import-the-master-certificate).
Windows Firewall is **automatically configured** if it was enabled during the Application Server installation. Required inbound TCP ports:
| Port | Purpose |
| --------- | --------------------------------------------------------- |
| **9447** | Connection between Application Server and Clients |
| **22712** | Connection between Application Server and Management Tool |
| **22713** | Connection between Application Server and Management Tool |
| **22714** | Connection between Application Server and Management Tool |
The source documentation has a discrepancy here — the Windows Firewall configuration page lists ports `9447, 22713, 22714` only (missing `22712`), but the install page and cloud install page list all four. The list above follows the install page.
For non-Windows-Firewall installations, see [Configure Windows Firewall manually](#configure-windows-firewall-manually).
## Cloud installation
To install the Application Server on a cloud VM (AWS EC2, Azure VM, Google Compute Engine, etc.):
Install the Application Server in the cloud VM using the same Setup wizard steps as above.
In your cloud provider's **management console** or **security group** configuration, allow inbound TCP connections via ports **9447** (AS↔Clients) and **22712**, **22713**, **22714** (AS↔Management Tool). This is on top of any Windows Firewall configuration on the VM itself.
**Install the Application Server and the Management Tool on the same cloud VM** to minimize cross-VM network traffic and reduce egress costs. This is the recommended pattern for cloud deployments.
## External or cloud-based Application Server (different network)
When the Application Server is **not on the same network** as the Clients or Management Tool — typical for a cloud AS reached by on-premises Clients:
Ensure the Application Server has a unique external (publicly reachable) IP address.
When [installing the Management Tool](/docs/administration/deployment/install-management-tool) and [installing Clients](/docs/administration/clients/windows), specify the **external IP address** of the Application Server — not its internal/private IP.
## Configure Windows Firewall manually
If Windows Firewall was disabled during installation (or you're using a different firewall product), configure inbound rules manually:
In **Control Panel**, select **System and Security → Windows Firewall**. Click **Advanced settings** in the Windows Firewall window.
In the **Windows Firewall with Advanced Security** window, right-click **Inbound Rules** and select **New rule…** from the context menu. The **New Inbound Rule Wizard** opens.
On the **Rule Type** page, select **Program**, then click **Next**.
On the **Program** page, select **This program path**, click **Browse**, and navigate to the Application Server executable. The default path is:
```text theme={"system"}
C:\Program Files\Ekran System\Ekran System\Server\EkranServer.exe
```
Click **Next**.
On the **Action** page, select **Allow the connection**, then **Next**. On the **Profile** page, select the network profile(s) used to connect remote computers, then **Next**.
On the **Name** page, enter a descriptive **Name** (e.g. `Syteca Application Server`), then click **Finish**.
The rule is created and by default allows any connection via any port.
Double-click the rule to open its **Properties** window. On the **Protocols and Ports** tab:
* **Protocol type:** TCP
* **Local port:** Specific Ports, then enter:
* `9447` (Application Server ↔ Clients)
* `22712`, `22713`, `22714` (Application Server ↔ Management Tool)
Click **Apply**, then **OK**. Close the **Windows Firewall** window.
## Related
Back up, delete, import, reissue, and migrate the Master Certificate.
Upgrade the Application Server to a newer Syteca version.
Remove the Application Server from a Windows host.
Custom port, non-admin service start, SWIFT username monitoring, Warning and Consent banner.