Investigators traced the outages to instability in the corporate network and the Azure tenant that impacted the AppProxy used by OTRS. IT resolved the underlying network/Azure/AppProxy condition; after stabilization the AppProxy and Azure services returned to normal, OTRS pages became reachable again, and email polling resumed.

Cloudflare diagnostics and server-side checks showed the origin webserver was not responding due to an outage/unreachability in the third‑party datacenter hosting the service. Once the datacenter provider restored connectivity, the origin became reachable and the site returned to service.

EBSCO support identified required domains that were being blocked by network/firewall/proxy appliances. IT validated the symptoms against the vendor case and restored access by allowing the EBSCO-listed domains per EBSCO guidance; the EBSCO interface then loaded normally for users.

IT confirmed LIBF servers were reachable and LIBF firewall logs showed traffic from the Centre's IP (no blocking on the LIBF side). Network isolation testing (for example via a tethered phone) demonstrated the fault was in the client/local network path (proxy/PAC or Government of Jersey firewall) rather than at LIBF. The investigation localized the issue to the local/proxy/Government firewall boundary and indicated that remediation belonged on that path.

Log analysis showed that remote RADIUS server instances were not responding to requests, so the failure was attributed to the remote endpoint being unresponsive rather than a local secret mismatch. The issue required the remote RADIUS host to restore service for normal authentication to resume.

Troubleshooting determined the failure was isolated to the user's home network (Vodafone/Fritzbox/docking station environment). No corporate-network action corrected the condition and no remediation was implemented; the ticket was closed as Won't Do.