Part 2 · Appliance & Site Configuration
Email Configuration & Admin Alerts
An appliance that's silently failing to sync with its failover peer, running out of disk, or serving an expired certificate is only useful information if someone gets told. This module covers how PRA sends mail, and the two distinct sets of events — appliance-level and site-level — that trigger an alert.
Two Email Configuration pages, not one
Confusingly, there are two separate "Email Configuration" screens in PRA, and which one you're on determines which alerts you're configuring. The /appliance > Security > Email Configuration page governs appliance-level notifications — hardware and firmware-adjacent events like RAID degradation or a syslog parameter change. The /login > Management > Email Configuration page governs site-level notifications — mostly clustered around failover health. Both pages configure their own SMTP relay settings and admin contact addresses; they are not automatically the same mail configuration, though in practice most deployments point both at the same relay server.
Configuring the SMTP relay
Whichever page you're on, the pattern is the same: set a From Address the appliance sends as, then point at an SMTP Relay Server by hostname/IP, port, and encryption type (None, TLS, or STARTTLS if your mail server supports it), and finally choose an SMTP Authentication Type. Three authentication types are supported:
| Authentication type | When to use it |
|---|---|
| None | Relay accepts anonymous/unauthenticated submissions (uncommon outside internal relays) |
| Username and Password | Classic SMTP AUTH — direct username/password against the relay |
| OAuth2 | Required for modern cloud mail providers now that basic auth is being retired; PRA documents dedicated walkthroughs for Microsoft Entra ID (Microsoft 365 / Exchange Online) and Google Workspace |
The OAuth2 path is materially more involved than legacy SMTP AUTH: for Entra ID, an Azure admin must first enable Authenticated SMTP on the mailbox, then register an application in Entra ID, capture its Application (client) ID, OAuth authorization/token endpoints, and a client secret, and enter all of that plus a redirect URI (https://<appliance URL>/login/smtp-verification) back on the PRA side before clicking Verify OAuth2 Provider to complete the handshake. The Google Workspace path is structurally identical but runs through the Google Cloud Console: create a project, enable the Gmail API, configure an OAuth consent screen, and generate OAuth client credentials to plug into PRA.
The documentation flags that Microsoft is deprecating username/password basic authentication for Exchange Online SMTP — if your appliance is still configured with a plain username and password against smtp.office365.com, that configuration is on a deprecation timeline and needs to be migrated to OAuth2 before Microsoft's cutover, or admin alert email will simply stop being deliverable with no other symptom.
Once the relay is configured, both pages let you send a test message immediately — checking Send a test email before clicking Save — which is the fastest way to confirm the whole chain (relay reachability, auth, from-address acceptance) actually works end to end, rather than waiting for a real alert-worthy event to prove it one way or the other.
An admin configures the SMTP relay, sends one successful test email, and considers the job done — without enabling the Send daily communication notice option available on the site-level Email Configuration page. Months later the relay's credentials rotate or expire, mail delivery silently breaks, and nobody notices until a real incident (a failed failover sync, an expiring certificate) goes unreported. The daily notice exists specifically to give you a canary: if you stop getting the daily "everything's fine" email, you know alerting itself is broken before you actually need it.
What triggers an alert
The two Email Configuration pages don't just differ in where they live — they watch for genuinely different categories of events.
Appliance-level alerts (/appliance > Security > Email Configuration)
| Event | What it means |
|---|---|
| Syslog Server has been Changed | A user on /appliance modified the syslog server parameter — a change-control signal, since altering where audit events go is itself security-relevant |
| RAID Event | One or more RAID logical drives is not in an Optimum state (Degraded or Partially Degraded) — an early warning of impending disk/hardware failure |
| SSL Certificate Expiration Notice | An in-use SSL certificate — an end-entity certificate or any CA certificate in its chain — is 90 days or fewer from expiring |
Site-level alerts (/login > Management > Email Configuration)
These cluster almost entirely around failover health, which makes sense given the site-level page sits logically next to the Failover page from Module 6 — most of these events are exactly the failure modes that page's synchronization and role logic can hit:
| Event | What it means |
|---|---|
| Product version mismatch during failover | The primary and backup nodes are running different software builds — a state that must be fixed before failover can be trusted |
| Primary node's shared IP interface not enabled | Local site thinks it's primary with a shared IP configured, but the network interface for that IP isn't actually up |
| Shared IP configured in /login but missing in /appliance | Configuration drift between the two layers — the IP is expected but was never actually added on the appliance side |
| Backup node can't reach primary or any test IP | Backup can't tell whether the primary is really down or whether the backup itself has lost network connectivity |
| Backup node's backup operations are disabled | The Enable Backup Operations toggle (Module 6) is off, so this node isn't actually protecting anything right now |
| Backup node failed a self-probe | Indicates the backup node itself may be malfunctioning |
| Backup failed to contact primary by hostname | Possible DNS resolution failure specifically (as distinct from a general network outage) |
| Automatic failover disabled and probe failed | The backup detected the primary is unreachable, but won't act because automatic failover is off — a manual failover decision is needed |
| Automatic failover enabled and primary unresponsive | The backup is about to auto-promote itself to primary — final warning before a role swap happens without human input |
| Automatic failover triggered | The backup has already become primary because the original primary was down too long |
| No successful data sync in the past 24 hours | The primary failed to sync with the backup recently — the backup's data is going stale, weakening the safety net even if nothing has failed over yet |
Notice how many of these site-level alerts fire before anything actually breaks for end users — a stale data sync, a disabled backup-operations toggle, a mismatched software version. That's the point: failover is only as good as its weakest silent failure, and these alerts exist to surface exactly the kind of configuration drift that would otherwise sit unnoticed until the day you actually need the backup appliance and discover it's been out of sync for three weeks.
Outbound event alerts: a third, narrower category
A related but distinct mechanism lives on the Outbound Events page (/login > Management), which lets you register HTTP recipients that get notified of session-lifecycle events — session start/end, someone joining or leaving a session, a Gateway going online or offline. Each outbound event destination has its own email-alerting sub-configuration: a Send Email Alert After field sets how long a destination must be failing before an error email goes out, and a Resend Email Alerts field throttles how often repeat failure notices are sent while the problem persists. This is narrower in scope than the two Email Configuration pages — it's specifically about the health of your outbound integration endpoints, not the appliance or failover pair itself — but it reuses the same underlying SMTP relay configured on the site-level Email Configuration page, so that page must be set up first for these alerts to have anywhere to go.