RAMSS, eHR and OGF services will not be available on Sunday, March 10, 2013 between 1 AM and 3:30 AM due to the DST switch.
We apologize for any inconvenience this may cause.
-Computing and Communications Services
RU-VPN became inaccessible around 4:20 PM this afternoon. Staff have confirmed the system is not reachable and are investigating the cause.
Update 10 PM: A log rotation failure caused the RU-VPN server to stop responding to new connection requests. Existing VPN connections were not affected. The problem started at around 16:20 and was fixed at 19:50.
Please accept our apologies for the problems this outage has caused.
-Computing and Communications Services
Slow network connectivity was reported by various users on the east side of the campus around 1 PM this afternoon. The performance degradation affected Academic and Administrative subnets. The cause of the problem was traced to a faulty fiber cable between two network switches, resulting in very slow download speeds. The link was disabled and all traffic failed to a redundant link. The faulty fiber will be replaced.
We apologize for any inconvenience this problem may have caused.
– Computing and Communications Service
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
