Skip to main content

Server maintenance and recovery

Routine maintenance tasks for an on-premises Erde server: recovering a lost administrator password, checking that the server is healthy, collecting diagnostics for support, and retiring or relocating an installation. Each runs on the Erde host.

Before you start
  • Role required: server administrator access to the Erde host (physical or remote sign-in to the machine).

Reset the administrator password​

If the administrator password is lost — or the account is locked out or was removed — recover it from the command line on the host. Run the server executable with --reset-admin; it resets (or recreates) the admin account, ensures the Administrator role is assigned, clears any lockout and failed-sign-in count, and revokes the account's refresh tokens, then exits without starting the web server.

& "C:\Program Files\Erde\api\Erde.Server.exe" --reset-admin --password-file C:\temp\pw.txt

The tool reads the new password from the file, then deletes the file. It runs only after the server has been configured (it needs the database connection from appsettings.Production.json). For the full flag and argument reference, see Command-line reference.

Check server health​

Erde exposes three unauthenticated health endpoints, useful for a load balancer, an uptime monitor, or confirming the server is up after an install, upgrade, or restore:

EndpointReports
/healthOverall health, including dependencies
/health/liveThe process is running (liveness)
/health/readyThe server is ready to serve requests (readiness)

Collect a support bundle​

When you contact support, run the support-bundle command on the host and attach the zip it produces. It gathers everything a support engineer usually asks for in one step — and it works even when the server won't start or was never configured, because it runs without booting the application:

& "C:\Program Files\Erde\api\Erde.Server.exe" --support-bundle --out C:\temp

The bundle contains:

  • Recent server logs — the last 7 days by default (--days 1–90 to change), capped at 50 MB with the newest files kept. Setup-wizard logs in the same directory are included too.
  • A redacted copy of the configuration — appsettings.Production.json and appsettings.json with every secret (encryption keys, JWT key, token secret, connection-string passwords) replaced by [REDACTED]. Host names and database names are kept because support needs them.
  • bundle-info.json — product version, OS, license status (customer, edition, SMA expiry — never the license key), whether each database is reachable and has pending migrations, file-storage location and free disk space, and any warnings about what could not be collected.

The command never includes your environmental data, uploaded files, or database contents. Secrets are redacted automatically, but logs can still mention server names and user email addresses — review the zip before sending if that matters for your organization.

If part of the collection fails (for example, the database is down — often the very reason you are contacting support), the command still succeeds and records what it could not gather inside bundle-info.json. For the full flag reference, see Command-line reference.

Notification retention​

Erde prunes its own notification history so the table does not grow without bound. A background sweep runs periodically and deletes notifications that have been read and are older than the retention window; unread notifications are kept indefinitely so a recipient never loses a count they have not yet seen.

The window defaults to 90 days. To change it, set Notifications:RetentionDays in appsettings.Production.json on the host and restart the server:

"Notifications": {
  "RetentionDays": 90
}

The value is the number of days a read notification is kept; it must be 1 or greater. A value below 1 fails server startup with Notifications:RetentionDays must be >= 1. No action is needed for normal operation — the default is suitable for most deployments.

Audit trail retention​

Unlike notifications, the audit trail is retained forever by design — there is no pruning sweep and no retention setting for it. The audit_log table in the application database records every change to audited records, so it grows with edit volume; on a busy deployment expect it to become one of the larger tables over time. That growth is normal and needs no maintenance: the table lives in the erde_app database, so it is included in normal database backups automatically. Do not truncate it — it is the change history your data stewards rely on (see Audit logs).

Decommission or move a server​

When you retire a server or move Erde to new hardware, release the license activation first so the slot is freed for the new installation:

  1. Release the activation: Erde.Server.exe --deactivate-license (see Activate and manage your license).
  2. Uninstall Erde from Apps & features.
warning

Uninstalling leaves appsettings.Production.json and license.bin behind, and does not delete C:\Program Files\Erde or C:\ProgramData\Erde. Remove those folders manually if you want a clean machine — but first back up appsettings.Production.json (it holds the encryption key) and your database. See Backup and restore.