Access to vdi.alaska.edu is unavailable

Update timeline

1. identified Jul 24, 2026, 05:46 PM UTC

   Access to vdi.alaska.edu is unavailable, but the cause of the outage has been identified. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able to access or use Virtual Machines from that address until the issue has been resolved.

2. identified Jul 24, 2026, 06:55 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 11:50 AM and hourly updates after.

3. identified Jul 24, 2026, 08:12 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 12:50 AM and hourly updates after.

4. identified Jul 24, 2026, 08:55 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 1:50 PM and hourly updates after.

5. identified Jul 24, 2026, 10:35 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 5:00 PM.

6. monitoring Jul 25, 2026, 12:03 AM UTC

   UA has resolved the issue with the vdi.alaska.edu and confirmed the fix to be stable. This will be placed in monitoring until end of business at 5:00 PM. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

7. resolved Jul 25, 2026, 01:06 AM UTC

   UA has resolved the issue with the vdi.alaska.edu and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk and thank you again for your patience during the resolution of this issue!

8. postmortem Aug 19, 2026, 09:26 PM UTC

   [vdi.alaska.edu](http://vdi.alaska.edu) access disruption. ‌ Expired Unified Access Gateway Certificates. Date Time:07/23/2026 4:00 PM. # Background [vdi.alaska.edu](http://vdi.alaska.edu) provides user access to the VMware/Omnissa Horizon VDI environment. ‌ Both Unified Access Gateway appliances \(exist on the VXrail platform\) provide the external access layer for users who want to access their VDI both on campus or remotely. ‌ # Break Down of the Problem Both certificates on each UAG expired on July 23, 3:59 PM, 2026. ‌ The problem was noticed Friday morning July 24th around 8:30 am, when users reported they could not access their “My Desktop” VDI environments when resolving to [vdi.alaska.edu](http://vdi.alaska.edu) ‌ ‌ When a user tried to resolve to [vdi.alaska.edu](http://vdi.alaska.edu) through their browser, they received a “Your connection is not private” notice and then would be blocked from reaching the [vdi.alaska.edu](http://vdi.alaska.edu) Horizon page at all. ‌ Actions taken to restore service: Requested renewal certificate from PAWS. This cert contained the primary domain name, [vdi.alaska.edu](http://vdi.alaska.edu) but also included the alternate names \(both UAG names\) [fbk-uag1.apps.ad.alaska.edu](http://fbk-uag1.apps.ad.alaska.edu) [fbk-uag2.apps.ad.alaska.edu](http://fbk-uag2.apps.ad.alaska.edu) [fbk-uag1.io.apps.ad.alaska.edu](http://fbk-uaf1.io.alaska.edu) [fbk-uag2.io.alaska.edu](http://fbk-uag2.io.alaska.edu) ‌ ‌ Duration of outage and time that service was restored: Thursday July 23rd 4:00 pm - Friday the 24th 2:00 pm. ‌ ‌ ‌ # Target State / Goal ‌ Both UAG’s should continuously present valid, trusted certificates and external and internal VDI access ‌ # Root Cause Analysis # Both UAG appliances were presenting expired TLS certificates. TSS received a list of VXrail server appliances that had estimated times of when their certificates were expiring. Both UAG appliances were not in this list so we were unable to dictate when their certificates were going to expire. # Develop Countermeasures I created a master certificate spreadsheet that now contains both UAG’s certificate information to include expiration dates. I’m sharing it with our TSS team leads so we can continue to monitor expected certificate expirations in the future. Requested access to Certinext service for future certificate renewals. ‌ Schedule for the implementation: The above should allow us to request and implement the certs before they expire on both UAG’s before they expire. # Follow Up / Review Verify certificate expiration dates on both UAG’s by monitoring the master certificate spreadsheet. Put in a request to PAWS to renew the certificate, plan a brief CAB outage, apply the certificate to both UAG’s and then confirm renewal was successful and access occurs