As part of implementing Banner Password Synchronization, the Cascade middle tier http server was restarted so that the following change in the httpd.conf file would take effect:
#Redirect /banner https://psforms.ups.edu/forms/frmservlet?config=banner
Redirect /banner https://psforms.ups.edu/banner_sso/gokssso.p_login
This directs cascade.ups.edu/banner to the new Banner login page that authenticates against OID.
See also Banner Password Synchronization works for Macintosh users
Our service provider performed some maintenance to our off-campus telephone connection. We lost connectivity Thursday evening, May 13th from approximately 8:00 to 8:30 pm.
The recently released Mac OS X 10.5.7 and Safari 3.2.3 fix the problem where users received “Too many redirects” error when logging in to Cascade Web.
The Technical Help page has been updated to show which versions of Mac OS X and Safari are compatible with Cascade. Browser/OS combinations that are not compatible still receive a message that includes a link to this Technical Help page.
Password synchronization and network/domain password resetting are currently disabled. Technology Services is currently working on restoring this service and we expect it to be restored shortly. We will update you as soon as possible.
UPDATE: Password Synchronization has been re-enabled as of 4:10pm on 5/12.
A person using a Web Browser that is not compatible with Cascade Web now sees a warning message before entering their username and password and encountering an error. At present, a person attempting to log into Cascade Web from Mac OSX 10.5.6 using Safari 3.1.2, 3.2.1, or 4.0 beta will see the following log-in page:
The OID schema on summit was inadvertently overwritten with Cascade’s OID schema during a refresh of Summit. This required re-registering the partner application for “/summit”. This did not work until we dropped oid.wwsec_enabler_config_info$ then executed @loadsdk from albert’s oracle account.
The listener_token value is: cascadetest.ups.edu:4445
Spam messages quarantined prior to 9:00 AM on April 27, 2009, are no longer available on the PureMessage Web site due to the domain name change which took effect at that time. Messages arriving after 9:00 AM will be available as usual.
If you need messages quarantined before this time, please contact the HelpDesk at helpdesk@ups.edu or x8585.
The reports server experienced the same problem as last Monday. Bounced the server to see if it resolves the issue. Paul will continue to research the cause of this problem.
As part of the domain change project, e-mail addresses and URLs stored in the Cascade database have been updated from “ups.edu” to “pugetsound.edu”. New account provisioning has also been updated accordingly.
The directory and most web applications display the new addresses and URLs. A few remaining Web applications will be changed in the coming week.
This morning between 8 and 9 AM, primary e-mail addresses were changed. E-mail messages from University of Puget Sound community members will now come from @pugetsound.edu. Messages sent to @ups.edu AND @pugetsound.edu will be delivered normally.
I have the valid certificate ready but not installed for the following reasons.
[Update 04/21/2009 03:17 PM] E-mail service has been restored. All mail will be delivered shortly.
Mail inbound to pugetsound.edu has been disrupted. We are working to restore service. No mail has been lost, and all mail will be delivered. We will update you as soon as possible.
Cascade and FAMIS users reported issues receiving their reports that are run through the reports server. Users received an error message saying that job ###### wouldn’t run. When we looked in the reports server (past jobs), that particular job_id did not show up (it was a future job_id!).
Resolution: bounced reports server
Kristen Spiese requested that the Shasta server be shutdown.
It will be available to be brought back online if needed.
We will wait to repurpose the machine temporarily.
A database error occurred in CRM about 11:30 am on 4/15/2009. DST was alerted to the problem, a table that was unable to extend, and fixed it about noon. A couple of email campaigns were in-progress and were adversely affected:
1. A message from the President’s office going to faculty, staff and students was sent out twice, but the records indicated it only went out once.
2. A message that was being created by Admission was in the middle of generating the target group and got stuck there. Every attempt to resolve it failed so the solution was to copy the schedule without the target group, re-create the target group and then the email was sent out successfully.