ja-sig summer conference, 2006 experiences upgrading uportal panelists: katya sadovsky (uc irvine)...

JA-SIG Summer Conference, 2006

Experiences upgrading uPortalPanelists:

Katya Sadovsky (UC Irvine)

Adam Rybicki (Unicon)

Susan Bramhall (Yale)

Steve Barrett (Cornell)

Darren Kraker (CalPoly)

Drew Wills (Unicon)

Faizan Ahmed (Rutgers)

With contributions from:

Sarah Arnott (Memorial University of Newfoundland)


Panel objective

To give the audience an opportunity to compare uPortal upgrade approaches and experiences at several institutions.


Questions for the panelistsWhich versions of uPortal did you upgrade from and to?

Which Layout Management approach did you select?

How did you migrate existing user accounts layouts?

How did you migrate group definitions?

How did you migrate custom channels?

How did you migrate framework code customizations?

Is it desired to convert PersonDirs.xml to personDirectory.xml?

2.5.2 now includes CAS client. Is this the time to implement CAS?

Many institutions want to go to DLM. However, its personalization UI represents a step backward from integrated modes/ALM. How do we:

"sell" this to the users?

skin this "old style" personalization UI?

What was your marketing strategy in general when to came to the upgrade?

Finally, how did you manage the upgrade project


UC Irvine

Upgraded from v. 2.1.5 to v.2.5.2

Converted from SLM to DLMManually converted layouts for frequent/power users

Template layouts were discarded in favor of DLM

Preserved: bookmarks, skin preferences

Group management:Used local and JitLDAP group stores before upgrading

Continued to use the same group implementations and definitions


UC Irvine

Custom channel migrationChannel db data: created a channel id map table and used SQL scripts to move data to the new databaseChannel sources: included with source code migration

Framework code customizations:Reviewed the list of customizations and determined that some have been implemented as part of the frameworkManually re-applied customizations since most of them needed to be re-factored

Person directory implementation:Kept the “old” PersonDirs.xml-based implementation (will switch to personDirectory.xml in the future)


UC IrvineAuthentication: using a homegrown campus authentication systemPersonalization UI

Since we moved from SLM to DLM, our users didn’t see much of a change in the Personalization UI

Marketing the upgrade:Sent out 3 emails to registered users:

• 1st – to all the registered users• 2nd and 3rd – to those users who have logged in the past 2 months

Created an info page (using one of our page templates) that explained the changesAdvertised in the ‘Portal News’ channel and uci.brief (electronic news mailer)


UC Irvine

Managing the upgrade project: task list


MUN

Upgrading from 2-3-patches to 2-5-patches (planned for late August)We will be converting from ALM to DLM

We're not migrating our existing user's layouts. Not enough users are using the personalization features. In fact, we're eliminating many personalization options and modifying our UI with a new custom theme. Our new UI will have navigation more similar to a traditional web site with only one channel rendered at a time. The menus will be personalisable.We will be maintaining personalized data from channels where applicable.


MUN

Group management:We currently use PAGs and will continue to do so. No upgrade procedure necessary.

Custom channel migrationFor DB data: we created a table to maintain a mapping of old portal (2.3.x) user ids and unique identifiers (our CAS login username).

Framework code customizations:Manually. And some customizations were no longer necessary.


MUN

Person directory implementation:Will keep the “old” PersonDirs.xml-based implementation

Authentication: We've used CAS since our initial launch in April 2003.

Personalization UISince we've created a new theme for DLM and removed some of the personalization stuff, it's not an issue for us.


MUN

Marketing the upgrade:Since we will be drastically enhancing our UI, there will be a huge marketing campaign around the new, improved my.mun.ca.

Memorial is also going through an institution-wide branding inititiative (new institutional logo, colour scheme, etc.) launched next month - very timely for our upgrade in August.


Lawrence Berkeley National LaboratoriesUpgraded from v. 2.1.5 to v.2.5.2

Created an inventory of channels for portingUsed a tool to export channel definitions in pubchan XML formatThe only framework modifications had to do with authentication, but those were discarded and replaced with CASPort the custom stats recorder to 2.5.2

Converted from SLM to DLMAll layouts were discarded, but few users personalized them

Group management:Switched from LDAP to PAGSContinued to use the same group implementations and definitions


Lawrence Berkeley National Laboratories

Custom channel migrationNo custom channels to migrate

Custom content was presented using GenericXSLT and CWebProxy, and the upgrade only required re-testing

Bookmarks

Person directory implementation:Kept the “legacy” personDirs.xml-based implementation

User InterfaceImplemented the VT theme by porting it from 2.4.2 to 2.5.2

This theme could have forced ALM over DLM


Lawrence Berkeley National LaboratoriesAuthentication

Implemented CAS 3.0.4 by using the same LDAP to keep the same credentialsExtended CAS 3.0.4 to allow passing service tickets via HTTP POST

MiscellaneousCVS / build system to assure that any instance (dev, QA, Prod) could be rebuilt from CVS


Rutgers University

Upgraded from v. 2.4.2 to v.2.5.2

Stayed with SLMThis was for historical reasons

Looking into migrating to DLM

Investigating tools to help in such a migration


Rutgers University

Managing the upgradeJAXP 1.2 to JAXP 1.3

JDK 1.4.x to JDK 1.5

uP 2.4.4+ to uP 2.5.2+

SLM to DLM (future)


Yale University

Upgraded from v. 2.3.1 to v.2.5.1Converted from SLM to DLM

Template layouts were discarded in favor of DLMSpecial effects for users with customized layouts

• Limited success

Preserved: all channels

Group management:Used local and PAGS group stores before upgradingContinued to use the same group implementations and definitions plus


Yale University

Custom channel migrationNo changes – modified database in place

Framework code customizations:Reviewed the list of customizations (some have been implemented as part of the framework = motivation to QA mods and contribute back!)Manually re-applied customizations: most of them needed to be re-factored and/or applied to different classes

Person directory implementation:Switched to new PersonDirectory.xml to enable cached attributes for speedier logon processing.


Yale University

Authentication: CAS was used for both versions

Personalization UISince we moved from SLM to DLM, our users didn’t see much of a change in the Personalization UI

We modified Preferences channel to show user customized content in a different color

Marketing the upgrade:Marketing?

Put announcement in Portal.


Yale University

Managing the upgrade project: I was the only person on the project

My notes:• http://tp.its.yale.edu/confluence/display/YIP/

Converting+to+DLM


Cornell University

Upgraded from 2.3.x to 2.4.x

Converted from SLM to ALM (MUN Enhanced)

Group management We have a central group mechanism

Custom channel migrationDefined them in the new instance*


Cornell UniversityFramework code customizations

Many of our customizations were incorporated into the 2.4.x releaseThere are only a few Cornell specific modifications

Person directory implementationWe use PersonDirs.xml w/both Directory and JDBC Directory definitions

Authentication/CAS:We have had central authentication for much more than a decade nowI recommend that some type of central authentication mechanism be employed soon


Cornell University

Marketing strategy: We made an instance of the new version available in parallelRan in parallel during the Spring semesterCurrent (2.3.x) version contained a link in the header to the new versionProvided a “migration” channel in the new version to allow address and bookmark information to be populated on demand from the 2.3 instance into the 2.4 instance.


Cornell University

Managing the upgrade project:Our upgrade project was handled like the installation of a new product offering

The only visible presence of a previous version came from the migration channel

Removed the migration channel during Winter break of the following year


Cal Poly (San Luis Obispo)

Upgraded from v. 2.1.5 to v.2.5.1 (+patches)Converted from SLM to DLM

All layouts were reset back to ‘default’Content driven by DLM based on roles in LDAPPreserved: bookmarks, force university skin

Group management:Previously used uPortal local Group Store exclusivelyMigrated any groups that were not in LDAPUtilized LDAP group structure with PAGS for most group relationships


Cal Poly (San Luis Obispo)

Custom channel migrationExported then republished using new channel publishing tools that utilize channel fname

Framework code customizations:Reviewed the list of customizations (some have been implemented as part of the framework)Minimized customizations, re-factoring where possible

Person directory implementation:Used new personDirectory.xml implementation for greater flexibility


Cal Poly (San Luis Obispo)Authentication: We’ve been using CAS since 1.X version of the portalPersonalization UI

Previously used SLM Used the upgrade as an opportunity to update the look and feel

Marketing the upgrade:PeopleSoft SA implementation, content management, ease users through PeopleSoft SA migrationLeverage the power of DLM i.e. delivering new content to a customized layoutEmailed users that had logged in within the last 3 months informing them any layout customizations would be lost after upgrade


15 15

ja-sig summer conference, 2006 experiences upgrading uportal panelists: katya sadovsky (uc irvine)...

Documents

jasig summer conference

upgrade project slide

definitions slide

registered users

existing users layouts

future slide

users didnt

personalization ui marketing