The XMedius FAX server became unresponsive at 8:13 AM this morning and services were unavailable until 8:50 AM. A server restart was done to clear the problem.
We apologize for any inconvenience this problem may have caused.
– Computing and Communications Service
The outbound e-mail server that scans messages for spam and viruses became unresponsive at approximately 10:23 PM on Wednesday. Services were restored around 11:52 PM. During the outage, all messages sent by users were queued on the RMail system and delivered after services were restored.
The problem seems to be hardware related and further investigation is taking place.
We apologize for the inconvenience.
-Computing and Communications Services
The Alfresco database server crashed and rebooted this afternoon at approximately 1:24 PM. The outage affected the Admissions and Campus Facilities and Sustainability document management systems. Services were restored around 3:10 PM.
We are investigating the reason for the unexpected server reboot.
We apologize for any inconvenience this problem may have caused.
– Computing and Communications Service
A network device failed at 5:04 AM this morning making Ryerson’s Central Authentication System unavailable as well as RAMSS and eHR. The system was restored by 8:31 AM this morning.
Please accept our apologies for the outage.
For those interested in a more detailed technical explanation of this outage, here is a little more information:
The Virtual Router Redundancy Protocol (VRRP) instance on the Alteon load balancer that services the subnet that the SSL accelerators are on, stopped working this morning at 5:04am. The result was that the SSL accelerators were not able to comunicate with hosts outside their subnet. As a result, the applications that are ssl offloaded by this load balancer, eHR, RAMMS and CAS were not working. All the health checks were good on the load balancer and there were no log entries regarding the problem. This time the SSL accelerators were not the problem, it was the alteon load balancer.
The VRRP instance was disabled to make the load blancer work. This is the first time we have encountered this type of problem.
-Computing and Communications Services
CCS became aware on Monday morning that users who only have an applicant role at Ryerson were unable to login to the my.ryerson portal since Friday, Feb. 8, when the 2-factor authentication service was released.
We apologize for the inconvenience.
-Computing and Communications Services
A back end RMS application failed at approximately 11:10 AM this morning. It was restarted at 11:15 AM. During the ~ 5 minute outage, the following services were not available: RMS Administration, Activation and Self Service.
The cause of the problem is still being investigated.
We apologize for the inconvenience.
-Computing and Communications Services
The virtual applications (VAPPS) service was not available between 10:18 AM – 10:47 AM. Technical staff are investigating the root cause of the problem and working with the vendor to resolve the issue.
We apologize for the inconvenience.
– Computing and Communications Services
The virtual applications (VAPPS) service has not been available since approximately 8:38 AM. The problem seems to be related to a network load balancer. Network staff are investigating the root cause of the problem and working with the vendor to resolve the issue.
Update 2:10 PM: Service was restored at approximately 1:10 PM.
We apologize for the inconvenience.
– Computing and Communications Services
Virtual applications (VAPPS) experienced intermittent service disruptions this morning, starting at approximately 2:45 AM and ending around 9:50 AM. The problem seems to be related to a network load balancer issue. Technical staff are investigating the root cause of the problem.
We apologize for the inconvenience.
– Computing and Communications Services
