[Update 3/6/09 10:41 AM] This error has been resolved; however,
The right navigation on academic departments and programs pages linked from http://www.ups.edu/academicdepartments.xml is not displaying at this time. The missing navigation on these pages includes links to departmental and program Web sites. The problem has been referred to the vendor of our content management system, Ingeniux, and they promise a solution today.
We will add temporary links to the department and program Web sites until this issue is resolved.
I am shutting down the CMS server in order to perform needed maintenance on the system. This is required because some pages are missing their navigation. Folks who use the CMS will only be affected for a few minutes; however, publishing will be slow for the next 90 minutes.
The next scheduled CMS will be the afternoon of March 26.
The Content Management System stopped publishing content to the main web server at about 9:10am this morning. I believe that this problem has been resolved; however, new content will be unlikely to appear on the main web server until after 3:30pm.
If your changes haven’t shown up on the main web server by 4:00 pm, please publish the pages again. Thank you.
Update: publishing has resumed.
The CMS is experiencing some publishing difficulty. This should be cleared up soon.
The main university web server (www.ups.edu) experienced errors caused by the Ingeniux (CMS) application this afternoon. Content was restored from backup, although this version of the content is a few days old. When the publishing operation finishes in about 30 minutes, all current content will be restored. If you are a content provider who published pages between 3:00 to 3:30 PM, we recommend publishing them again after 5:40 PM. Thank you.
Today the pages on the main university web server began to fail due to problems with the Ingeniux CMS system. The CMS system itself could not be started to correct this issue. As a result, the contents on the CMS had be restored from backup. Unfortunately, changes made to the website from within the CMS may have been lost. If you have lost content, it may be possible to restore it. Please contact Jean Huskamp at x3773 for more information.
Thursday, May 10
I Installed version 5.250 on webserver2. Barbara and I subsequently tested the current Macintosh client against this version and found that a significant number of our issues were resolved.
The design-time server was serving the admin client to all users. Recycling the app pools in IIS restored the serving of the author client.
Thursday, May 17
I performed the stop IIS – delete dependency graphs – start IIS – full site publish sequence. The entiresitepub folder contains 8218 objects.
Friday May 18
The CMS was sluggish in responding to page check out and in. There was an error on the server, which I restarted.
Week of May 21
System continues to be unresponsive at times. Simply restarting IIS seems to resolve the issue.
Some pages were returning a 500 error on the live site. Restoring from the backup on webserver2 was ineffective as the same errors were replicated there. The error-clearing sequence mentioned above resolved the issue, although it took somewhat more than an hour to fully resolve.
At 8:41 this morning, in response to some errors in the igxcsapi log, I deleted the dependency graphs and performed a full publish.
I executed a full publish after deleting the dependency graphs. News items on the main page had not been publishing correctly. This generally will be a weekly task.
In anticipation of testing the Mac 5.2 prototype client, I upgraded the server to 5.2.39. This is the DST-fixed version. I had no reason to put it up before now.
The CMS server responded to client connections with the following error:
An error occurred while retrieving the root node of the tree.
Error starting session:
Not enough storage is available to complete the operation.
After clicking okay the this error appeared:
Microsoft JScript runtime error “800a136f”
‘name’ is null or not an object
/upsweb/assignment_list.asp, line 69
At 0945, I:
- stopped IIS
- stopped PeerSync service
- deleted depgraph files
- restarted IIS
- performed a full publish
- restarted PeerSync service
System running okay, publishing is in process. I think the errors were symptomatic and not necessarily accurate; however, I’m logging them here in case they recur.
Updated the server on CMS to Ingeniux42SR1-4.2.85.
I upgraded webserver2 to Ingeniux 5.2.36, the version needed to support the improvements to the Mac client. Barbara and I will test the client tomorrow morning.
Change to security settings:
Due to changes in how the Mac OS handles Windows authentication, the editlivejava directory security no longer is set to Integrated Windows Authentication; instead, it allows access by the Internet Guest Account, IUSR_WEBSERVER2. (The Ingeniux folks are having a hard time working out these settings; nevertheless, Sean feels that some of the problems we’ve had in recent testing of the Mac client may be related to authentication.)
redistributableseditlivejava is the location.
HTML Tidy option included in upgrade
This release comes with a version of HTMLTidy, the use of which is an option during the upgrade. Sean recommends using the report-only mode as well as the option that shows the original cdata block with the proposed changes. The resulting report is located in the upgrade directory (found at the same level as the xml directory in the site folder).
Monday morning at 7:30 AM, a publish on the CMS system failed, corrupting the University’s web site. The system was restored after about one hour.
Dependency graphs were rebuilt, and the publish target was copied directly to the live web site to expedite recovery
It appears that the Ingeniux application build that we installed in early December (the version with support for IE 7) is much less tolerant of multiple attributes with the same name. The system error is very specific:
REASON: No attribute name may appear more than once in the same start tag or empty element tag.
In this instance, as in another case in late December, the offending attribute name is “NewWindow.” Since this attribute is used in a global export, I have, on the advice of Jason at Ingeniux, commented out lines 1178 and 1434 of CustomUtilities.inc, which should resolve this problem.
If this error recurs we’ll have to look for a different export and fix that one as well.