Starting with Horizon 8 2606, administrators can monitor Unified Access Gateway (UAG) health and utilization at the pod level directly from the Horizon Console. The UAG monitoring view displays availability status, service health, error details, session utilization, and certificate status for each UAG appliance in a pod. This enables administrators to identify and investigate errors and to act on warnings before issues affect end users.
Prerequisites
- The Horizon 8 2606 or later release must be deployed.
- UAG must be deployed and configured to communicate health data to the Connection Server. This feature relies on UAG sending health information via the X-EUC-Health header mechanism to the Connection Server.
- To view historical availability data, an Event Database must be deployed. If no Event Database is configured, historical data may not be available.
Note: If a load balancer is deployed between UAG and the Connection Server, health notifications from UAG may not always be received by the Connection Server. In this configuration, the data displayed in the console may not reflect the current state of the UAG appliance.
Accessing the UAG Monitoring View
- In Horizon Console, select Monitor > Infrastructure.
- Click the UAG tab to display the Server name, Status and Details for each server. The UAG summary page displays information for the UAG cluster as a whole and for each individual UAG appliance.
- Click View in the details column to see the Summary page for the Connection Server.
Information Displayed on the UAG Summary Page
The UAG monitoring view displays the following information for each UAG appliance:
Health Status
The health status reflects the most recent known status of the UAG appliance.
Note: Because UAG controls when health data is sent to the Connection Server, the status shown reflects the most recently received data and may not represent the current live state of the appliance.
Certificate
The certificate status for each UAG appliance is displayed, including whether the certificate is valid and any applicable warning information about upcoming expiration. Administrators are advised to review and renew certificates before expiration.
Session Details
The number of active connections is displayed based on the active_connection_count value received from the UAG. This value represents total active connections to the UAG appliance.
Refreshing UAG Monitoring Data
The UAG monitoring view includes a Refresh button that allows administrators to manually request the most recent monitoring data from the Connection Server. Click Refresh to update the displayed information.
UAG Service Error Codes and Recovery Procedures
When a UAG-hosted service reports an error, the service status grid on the UAG summary page displays the corresponding error code. The following table lists the error codes that may appear, their meaning, and the recommended recovery procedures.
| Service | Error Code | Meaning | Recovery Procedure |
|---|---|---|---|
| Blast Secure Gateway (BSG) | blast:UAGE00359 | BSG is unreachable. | If the BSG process is not running, UAG restarts it within the same health check cycle before rechecking status. If the BSG process is running but the admin HTTP port is unreachable, no automatic restart is triggered. Review the BSG logs (bsg.log, bsg-std-out.log) for errors. |
| Blast Secure Gateway (BSG) | blast:UAGE00860 | BSG responded, but the status response body is unparsable or null. | No automatic recovery. BSG is reachable but returning an unexpected response. Investigate BSG logs (bsg.log, bsg-std-out.log) for startup or runtime errors. |
| PCoIP Secure Gateway (PSG) | pcoip:UAGE00349 | PSG health status query failed. | If the PSG process is not running, UAG restarts it at the start of the same health check cycle. If the process is running but unresponsive to health status queries, no automatic restart is triggered. Review PSG logs (SecurityGateway*.log) for errors. |
| PCoIP Secure Gateway (PSG) | pcoip:UAGE00350 | PSG client socket is not connected. | If the PSG process is not running, UAG restarts it at the start of the same health check cycle. UAG continuously attempts to re-establish the connection to PSG in the background; the error clears automatically once the connection is restored. Review PSG logs (SecurityGateway*.log) for errors. |
| Tunnel Server | Tunnel:UAGE00861 | Tunnel server statistics request failed. | If the Tunnel process is not running, UAG restarts it at the start of the same health check cycle. If the process is running but the admin port is unreachable, no automatic restart is triggered. Review Tunnel server logs (tunnel.log, tunnel-std-out.log) for errors. |
| Tunnel Server (RDP) | RDP:UAGE00861 | RDP sub-path of the Tunnel server statistics request failed. | Same as Tunnel:UAGE00861. Review Tunnel server logs (tunnel.log, tunnel-std-out.log) for errors. |
| Edge Auth Service (EAS) | eas:UAGE00697 | EAS health check failed. | UAG automatically restarts EAS on the first health check failure. Subsequent restart attempts occur with a minimum interval of 5 minutes between attempts, up to a maximum of 5 restart attempts total. Investigate EAS process logs (eas-service.log, eas-std-out.log) for misconfiguration or service errors. |
| Certificate Authentication Service (CAS) | cas:UAGE00125 | CAS health check failed. | UAG automatically restarts CAS on each consecutive health check failure, up to 4 restart attempts. There is no time-based cooldown between restart attempts. The attempt counter resets after a successful health check. Investigate CAS process logs (certauth-service.log, cas-std-out.log) for misconfiguration or service errors. |
| UDP Tunnel Server | utserver:UAGE00522 | The response from the UDP Tunnel server for the health check could not be parsed. | The UDP Tunnel server process is running but not responding to health checks as expected. Review the utserver.log for details. |
| UDP Tunnel Server | utserver:UAGE00523 | The UDP Tunnel server process is unresponsive to health check requests. | The UDP Tunnel server process may not be running or may not be responding. UAG attempts to restart the process in the current or next health monitor cycle. Review the utserver.log for details. |
Was this page helpful?