NTS and OIT System Status Page

Aug 10, 2026 · resolved Aug 17

The OIT EAS team has resolved the issue with the Banner, and confirmed the fix to be stable. Issue was resolved on Aug 10th. 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!

Aug 16, 2026 · resolved Aug 16

# **Root Cause Analysis – Argus Server Incident** ## **Executive Summary** The Argus server experienced a rapid loss of available space on the Windows C: drive. During investigation, PAWS identified significant disk activity occurring within the Lenel application log directory. Available disk space continued to decrease and eventually reached approximately 37 MB. PAWS cleanly shut down the server to prevent the operating system from reaching 0 available disk space and potentially causing additional system issues. PAWS expanded the C: drive and successfully returned the server to service. Following recovery, disk utilization stabilized and approximately 20 GB of free space remained available. PAWS is responsible for the underlying Windows server infrastructure but does not administer or support the Lenel application. The cause of the increased application-generated disk activity has not been determined and requires investigation by the application owner/vendor. ‌ ‌ ## **Incident Impact** The Argus server became unavailable during the incident and infrastructure recovery activities, resulting in an interruption to services dependent on the server. Reported impacts included on-campus door card reader functionality. ‌ ‌ ## **Timeline** **All times are Alaska Time.** **Approximately 11:04 AM** – PAWS was notified of an issue involving the Argus server and reported impacts to on-campus door card readers. The associated incident was TDX 991008. **Approximately 11:23 AM** – PAWS identified rapidly decreasing available space on the Windows C: drive. Resource Monitor showed significant write activity occurring within: `C:\ProgramData\Ln\logs` PAWS attempted to recover available disk capacity; however, C: utilization continued to increase. The C: drive eventually reached approximately **37 MB of available space**. PAWS cleanly shut down the VM to prevent the Windows system drive from reaching 0 available space and potentially causing additional operating system issues. PAWS performed the infrastructure work necessary to increase the capacity of the system drive. **Approximately 3:34 PM** – Infrastructure work was completed and the C: drive was expanded. The server was brought back online and PAWS verified normal server and disk operation. **Approximately 3:49 PM** – The server was reported operational. The following day, C: remained stable at approximately **19.9 GB free**, with no recurrence of the rapid disk consumption. ‌ ‌ ## **Root Cause** The immediate cause of the server outage was exhaustion of available capacity on the Windows C: drive. During the incident, PAWS observed significant disk write activity within the Lenel application log directory: `C:\ProgramData\Ln\logs` This activity rapidly consumed the remaining available capacity on the system drive. The underlying reason for the increased application-generated disk activity has **not been determined**. PAWS is responsible for administration of the underlying server infrastructure but does not administer, configure, or support the Lenel application. Determining why the application generated the increased disk activity requires investigation by the application owner/vendor and is outside the scope of this infrastructure RCA. ‌ ‌ ## **Contributing Factor** ### **Limited Available System Disk Capacity** The server did not have sufficient remaining C: drive capacity to absorb the unexpected increase in application-generated disk utilization. Available capacity eventually decreased to approximately **37 MB**, requiring PAWS to shut down the server to prevent Windows from reaching 0 available disk space. ‌ ‌ ## **Resolution** PAWS completed the following infrastructure recovery actions: * Investigated the rapidly decreasing C: drive capacity. * Identified the source directory associated with the increased disk activity. * Cleanly shut down the server before the system drive reached 0 available space. * Increased the capacity available to the Windows C: drive. * Returned the server to service. * Verified normal server and disk operation. * Continued monitoring disk utilization following recovery. Following recovery, the C: drive remained stable at approximately **19.9 GB free**. ‌ ‌ ## **Corrective and Preventative Actions** ### **Disk Capacity Monitoring** PAWS will review disk capacity monitoring and alert thresholds for the Argus server to provide sufficient notification when system drive capacity approaches critical levels. ### **Server Capacity** PAWS will continue monitoring C: drive utilization to verify that the additional capacity provides sufficient operating headroom under normal server conditions. ### **Application Investigation** The application owner/vendor will need to determine the cause of the unexpected increase in Lenel-generated disk activity and identify any application-level corrective actions that may be required. Application configuration, logging, retention, and application-level remediation are outside the scope of PAWS server administration. ‌ ‌ ## **Current Status** The Argus server is online and operational. The C: drive remained stable at approximately **19.9 GB free** during follow-up monitoring, with no recurrence of the rapid disk consumption observed during the incident. PAWS considers the **server infrastructure portion of the incident resolved**. The underlying cause of the Lenel application behavior remains undetermined and requires follow-up by the application owner/vendor.

Aug 3, 2026

We have resolved a recent issue caused by an unexpected change with Duo authentication that impacted managed macOS computer logins across campus. If you use a university-managed Mac, your login experience is now restored to normal operations. However, the first time you log back into your computer following this fix, you may see one or two additional Duo authentication prompts. When signing into your managed Mac for the first time today: 1. Enter your usual account credentials at the primary macOS login screen. 2. Complete the Duo prompt(s): You may be prompted to authenticate through Duo an extra time as system permissions refresh and re-sync with your account. 3. Approve the request on your Duo mobile app, hardware token, or via your preferred MFA method as normal. 4. Select Next at the Let’s keep your account secure prompt. 5. Select Next at the Set up a sign-in method prompt. If you continue to encounter login errors, repeated prompts to sync passwords on login, or any other issues logging into your Mac, please reach out to your campus IT Helpdesk.

Jul 24, 2026 · resolved Jul 25

[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

May 16, 2026 · resolved Jun 1

Our teams have resolved the issue with the Authentication service, 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!

Is NTS and OIT System down right now?

Yes — NTS and OIT System is reporting a minor incident as of Aug 19, 9:41 PM UTC.

What is NTS and OIT System's current status?

NTS and OIT System: Partially Degraded Service. Alert24 checks NTS and OIT System's status page continuously and can notify you the moment it changes.

How do I get alerted when NTS and OIT System goes down?

Alert24 monitors NTS and OIT System and 3,700+ other cloud and SaaS providers. When an outage is detected it updates your status page automatically and pages your on-call team — no manual checks. Start free at alert24.net.