Learning Strategy and Management > Management and Implementation > Dartmouth Digital Communications > Rice, Dartmouth, and Hurricane Rita

Rice, Dartmouth, and Hurricane Rita

Rice University and Dartmouth College Collaborated on an Emergency Web Site in Anticipation of Hurricane Rita

Dartmouth College has been an active member of the University Web Roundtable since 2001. Dartmouth hosted the annual meeting in 2004, and continues to manage the group’s discussion list.

On Wednesday, September 20, 2005, Rice University’s Roundtable representative contacted Dartmouth to see if the College would be willing to host an emergency Web site if Rice’s data center was closed because of Hurricane Rita, which was then approaching in the Gulf of Mexico. This site was intended to be a temporary public communication vehicle; in the case of extreme devastation, Rice would activate an alternative data center, where Web operations would recommence.

Dartmouth’s Network Services agreed to host a temporary Web account through the duration of the emergency, and did so starting on September 22. Rice staff was given access to that account and they published public information in it. The intention was for that Web site to become Rice’s home page in the event of an emergency.

In addition, Dartmouth’s Office of Public Affairs agreed to provide 24-hour on-call editorial backup over the weekend. If Rice editors became unable to access the account via the Internet, they would call Dartmouth staff with instructions for emergency content updates. The triage contact list included Rice’s Vice President of Public Affairs.

Fortunately, the hurricane spared Houston and, by September 26, the threat was over. Dartmouth’s Network Services deactivated the Rice Web account on September 28.

At the suggestion of Stanford’s Roundtable representative, the group held a conference call on September 29, hosted by Apple, to discuss lessons learned by Dartmouth and Rice. The general conclusions were:

  • A university’s emergency Web site should be maintained permanently at one or more off-campus hosting services. That service should allow designated administrators with no technical knowledge to make content updates, so they can develop mastery before an emergency demands full attention on the situation at hand. (Sample: A subdomain such as emergency.university.edu could be managed through a popular, easy-to-use, and robust collaboration system such as Moveable Type or WordPress on a selected host or as a service.) [1]
  • The emergency Web site should be configured to catch all page requests and to automatically redirect them to the home page. [2]
  • Off-campus editorial partners should be enlisted, in advance, to participate in the emergency information triage process, so they can post vital information if administrators do not have access to the Internet during the emergency.
  • In advance of an expected threat, technical administrators should reduce the amount of time that network domain servers look for a new Web site address, so there will be little or no down-time during the transition to a new “home page” (i.e., the emergency Web site). Otherwise, default settings might result in a gap of up to 24 hours between the old and new addresses. [3]
  • Each institution should have a clearly-defined off-campus, trusted backup to authorize the re-direction of its home page to the external emergency site should it be necessary. Then, during the emergency, all requests to the university — including the home page — would be redirected to the off-campus emergency.university.edu address. [4]

Members of the Web Roundtable were interested in exploring publishing and hosting options, and wished to further discuss the exchange of editorial partnerships as part of a collaborative effort.

Recommendations for Operations Staff

  1. Verify server redundancy for any services being considered. Use IP-address-based virtual hosting, rather than name-based hosting.
  2. All emergency pages should be placed within a single subdirectory (non-duplicative with the main Web site), and all other html requests should be rewritten to the index page.
  3. Reduce the DNS “time-to-live” value to one hour.
  4. Authorize an alternative administrative DNS contact.