Skip to content

Enterprise installation guide for administrators

This guide covers FLEET Mira Enterprise 1.1.0-beta6 in two supported topologies. Enterprise uses PostgreSQL and can run on Windows Server and in RDP, Citrix, or comparable multi-user environments. Use only the Enterprise setup on servers and terminal servers; the Basic/Pro setup blocks these environments.

Installation files

Beta status and worker operation

The setups are not yet code-signed. Verify their SHA-256 checksums before installation. Central background work runs only in the FleetMiraWorker Windows service; Enterprise clients do not start an integrated worker. An all-in-one server co-locates client and worker without introducing a separate combined runtime mode.

Common planning

Before installation, define:

  1. a stable DNS name for the PostgreSQL server;
  2. passwords of at least twelve characters for mira_app, mira_backup, mira_restore, and the PostgreSQL administrator;
  3. permissions for the virtual NT SERVICE\FleetMiraWorker account or a designated gMSA;
  4. local NTFS storage for PostgreSQL data and central locations for tachograph and document archives;
  5. a PostgreSQL backup and a separate backup for file archives;
  6. a maintenance window, firewall rules and, for network connections, a trusted TLS server certificate.

PostgreSQL data must reside on a fixed local disk of the database server. Tachograph files and original documents are not stored entirely in PostgreSQL. In a client/server installation, every client and the worker must therefore use the same canonical UNC paths and have the required share and NTFS permissions.

Scenario 1: client/server with a server-side worker

Target topology

flowchart LR
    C1["Enterprise client 1"] -->|TLS / TCP 5432| DB[("PostgreSQL: mira")]
    C2["Enterprise client n"] -->|TLS / TCP 5432| DB
    W["FleetMiraWorker service"] -->|TLS / TCP 5432| DB
    W --> A["Shared file archive (UNC)"]
    C1 --> A
    C2 --> A

The Windows Server hosts PostgreSQL and the standalone worker service. Users work with Enterprise clients on Windows 10/11 workstations or approved server sessions.

Install the server

  1. Sign in to Windows Server with local administrator privileges.
  2. Copy both setups to a local server folder and compare their SHA-256 values with SHA256SUMS-Enterprise.txt.
  3. Run FLEET-Mira-PostgreSQL-Server-1.1.0-beta6-Setup-x64.exe as administrator.
  4. Enter the port and the passwords for the PostgreSQL administrator, mira_app, mira_backup, and mira_restore. The setup installs PostgreSQL, creates the service, database and roles, and then imports the complete but business-empty Mira application schema.
  5. Configure listen_addresses, pg_hba.conf, DNS and TLS according to your security policy. Open Windows Firewall TCP port 5432 only to the intended client and worker networks.
  6. Run the Enterprise setup as administrator and select Fleet Mira Worker. /COMPONENTS=worker is the unattended equivalent.
  7. In an administrative Enterprise client, enter the DNS name, port, database mira, user mira_app, password and SSL mode. verify-full is recommended for production networks.
  8. Test the connection. No subsequent schema initialisation is required; before reporting success, the Server setup verifies the application, worker, and Enterprise backup schemas. mira_app neither needs nor receives DDL or CREATE privileges on the public schema.
  9. Verify FleetMiraWorker, its heartbeat and %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\logs\app.log.
  10. Configure shared archive, import and document paths and grant the service identity the required UNC and NTFS permissions.

Install the clients

  1. Run only the Enterprise application setup as administrator on every client.
  2. Open FLEET Mira and use the wizard to connect to the same mira database.
  3. Verify access to every shared archive under the respective user account.
  4. The client automatically queues central manual jobs in PostgreSQL and never starts a local scheduler.

Operate the worker

  • Use NT SERVICE\FleetMiraWorker by default; grant the machine account UNC access or switch to a gMSA/domain account when required.
  • Monitor service state, PostgreSQL heartbeat, queue, leases and failed jobs.
  • Multiple workers are supported; advisory locks and leases prevent duplicate processing.
  • Monitor %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\logs\app.log plus PostgreSQL and Windows event logs.
  • The service starts delayed after a reboot and has configured recovery actions.

Scenario 2: terminal server with all components

Target topology

flowchart TB
    U1["RDP/Citrix user session 1"] --> DB[("Local PostgreSQL: mira")]
    U2["RDP/Citrix user session n"] --> DB
    W["FleetMiraWorker service"] --> DB
    U1 --> A["Central file archive on a local NTFS disk"]
    U2 --> A
    W --> A

PostgreSQL, the Enterprise application, user sessions and the worker service all reside on the same Windows Server.

Installation

  1. Create local NTFS directories for PostgreSQL data and file archives. Do not use user profiles, UNC paths or mapped drives for the PostgreSQL data directory.
  2. First install the PostgreSQL Server setup as administrator. It provisions mira, the complete application schema, and the mira_owner, mira_app, mira_backup, and mira_restore roles.
  3. Then install the Enterprise application setup once, system-wide, as administrator.
  4. Start FLEET Mira in an administrative setup session and connect it to localhost, the selected port and database mira.
  5. Test the already initialised database. The connection configuration is stored machine-wide below %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise; Windows DPAPI protects the password.
  6. Configure the file archives on a local NTFS path accessible to all intended sessions, for example D:\FLEET-Mira-Data.
  7. Sign in to a normal user session and test login, read/write permissions, report output and archive access.
  8. Install client and service together with /COMPONENTS=client,worker and verify that only the service executes background work.

The co-located installation does not create another runtime mode. Every terminal-server session remains a client; schedules, notifications and central imports run only in the service.

Diagnosing sign-in

  • Check %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\logs\app.log first.
  • POSTGRESQL_SCHEMA verified confirms the connection and complete startup verification, but not the user login itself.
  • Locate the first CRITICAL entry immediately after selecting Sign in. Its traceback identifies the repository, SQL statement, and PostgreSQL error class.
  • The client also displays unexpected database failures directly in the login dialog. Passwords are written neither there nor to the log.
  • permission denied for schema public must not occur with a current setup: mira_app writes application data but executes no DDL statements.

Migrating an existing SQLite database

  1. Create and verify an unchanged backup of the SQLite file and the associated file archives.
  2. Stop all other FLEET Mira instances and stop the FleetMiraWorker service on every worker host.
  3. In Enterprise, open Enterprise → Migrate SQLite database.
  4. Select the SQLite source. The wizard opens it read-only, runs PRAGMA quick_check, and displays table and row counts.
  5. The mandatory option Copy DDD, record-document and financial archives to the FLEET Mira ProgramData directory atomically copies the related files to %PROGRAMDATA%\eh-systemhaus\FLEET Mira Enterprise\state. The wizard checks existing targets against the stored SHA-256 values and stops when a reference is missing or changed. Only then are all DDD, document, manifest and financial-archive paths normalized to portable state/... references inside the same PostgreSQL transaction. No new business hashes or signatures are generated.
  6. Enter user mira_restore and the restore password selected during PostgreSQL setup. These credentials are used only for the current migration and are not stored.
  7. Confirm replacement of the empty or designated Mira schema. Transfer assumes mira_owner and runs in a PostgreSQL transaction that rolls back on error. The Enterprise worker/backup objects and privileges for mira_app and mira_backup are restored afterwards.
  8. Restart Enterprise and compare users, vehicles, tachograph records, documents and sample reports with the legacy system.
  9. Enable the worker only after migration acceptance has been recorded.

Backup, update and rollback

  • Under Administration → Backups → Quick Backup, an authorised administrator can export a PostgreSQL custom dump as a ZIP file to a selected local directory without configuring a backup target. The ZIP contains mira.dump and a checksum manifest. The dialog requests the mira_backup user and password and does not store the password. This diagnostic export contains only the database and does not replace a complete Enterprise backup of the file archives.
  • The target configuration displays only fields required by the selected provider. It provides a directory picker for file system/UNC targets and a JSON file picker for the Google OAuth configuration.
  • Back up PostgreSQL regularly with pg_dump or a centrally monitored PostgreSQL backup system, and test pg_restore.
  • Back up tachograph, finance-document and other file archives separately and consistently.
  • Before every update, create a PostgreSQL dump and archive backup while all clients and the worker are stopped.
  • The Basic/Pro SQLite snapshot and restore feature is disabled in Enterprise.
  • Keep the original SQLite database unchanged and offline until the agreed rollback period ends.

Acceptance checklist

  • [ ] Setup files match the published checksums.
  • [ ] PostgreSQL data resides on a fixed local NTFS disk.
  • [ ] mira_app can connect only from approved networks or locally.
  • [ ] TLS, firewall, pg_hba.conf and DNS are documented and tested.
  • [ ] Every client uses the same PostgreSQL database and canonical archive paths.
  • [ ] FleetMiraWorker is running and Enterprise clients do not start an integrated worker.
  • [ ] Multiple users can read and write concurrently.
  • [ ] PostgreSQL and file-archive backup and restore have been tested.
  • [ ] Migration and business-level samples have been recorded.
  • [ ] Emergency access, password storage, monitoring and restart procedures are documented.

Known limitations and remaining production work are listed in Enterprise open items.