Upgrade 7.6

Before starting upgrade:

1. Patch portal to 7.3.5 on dev, qa and live (11/9 - 11/10)
2. Test with the patch before starting upgrade (11/11 - 11/12)
3. Change oracle driver class name in vcm config and tomcat conf to oracle.jdbc.driver.OracleDriver

Timeline for upgrade:

1. Dev: 5 days
2. QA: 5 days
3. QA: migration to 64bit - 5 days (on VM and use QA hardware for Prod 64bit?)
4. Load testing: 5 days
5. Prod: 10 days
6. Prod migration to 64bit - 5 days

Follow the Upgrade guide

Order of servers upgrade QA/Prod:

1. VCM
2. Autonomy
3. QA1 & QA2, should be upgrade together, so requires downtime, writedown each step before continuing (Estimate downtime: 8 hrs)

Rough roadmap for VCM upgrade:

1. Uninstall CCE
2. Backup Autonomy
3. Uninstall Autonomy
4. Stop endpoints
5. Stop services
6. install 7.6
7. run vgnupgrade
8. Rename old Contnent/7_3_1 directory
9. Upgrade Autonomy
10. Post upgrade stuff from ch7
11. Custom CMA and other apps deployments
12. DPM deployments, config changes
13. FURL config
14. Fixes on Presentation templates and Query Components
15. Thorough Testing
16. Patch VCM to 7.6 SP1
17. Another round of testing

Load Testing QA

1. Use earlier scripts with webload
2. Ask for the load tester desktop from Mark, that has all the scripts
3. Will need to do it off hours

Post Upgrade:

1. Upgrade to Portal 8.0?

Notes:

------

FURL

1. Configure FURL
2. Remove FURL listener in config (Events>Pre create and update)
3. set furl.exclude.sitename=false
4. set linkprinter.impl

DPM Menu classes customization in vgn-ext-templating generic resource, rollback component and item region menu to use pre 7.4 classes

PIOCDA

1. Include Michael's fixes to JSPs (Product detail etc.)
2. Checkin changes in VSS

V7.6 Upgrade Migration to 64bit

Backup

1. Database schemas (DEVVCMMGMT, DEVVCMLIVE, DEVVAPPREV, DEVVAPLIVE)
2. Take 32bit snapshot

On Mgmt stage:

Copy the following folders/files:

1. /opt/Vignette
2. /opt/SAP-JCo
3. ~/Vignette
4. ~/vpd.properties
5. /usr/local/apache/tomcat - upgrade to 6 after testing
6. /etc/profile.d/tomcat.sh
7. Create symbolic links for doctoor, /srv/www/vhosts/non-secured + secured
8. Copy apache config files
   
9. Update loaded modules
10. Java 1.5 32bit

Install:

1. 64bit JDK 1.6 (1.5?)
2. Recompile delivery apps with JDK 6?
3. Tomcat 6

Set environment variables for

1. JAVA_HOME
2. PATH
3. LD_LIBRARY_PATH
   

Deploy Apps:

1. piocda
2. portal
3. vgn-ext-templating
4. furl
5. vgn-tas

On delivery stage:

copy the following folders:

1. /opt/Vignette
2. /opt/SAP-JCo
3. ~/Vignette
4. ~/vpd.properties
5. /usr/local/apache/tomcat - upgrade to 6 after testing
6. /etc/profile.d/tomcat.sh
7. /srv/www/vhosts/non-secured + secured
8. Copy apache config files (ssl cert etc.)
   
9. Update loaded modules
10. Java 1.5 32bit

Install:

1. 64bit JDK 1.6 (1.5?)
2. Recompile delivery apps with JDK 6?

Set environment variables for:

1. JAVA_HOME
2. PATH
3. LD_LIBRARY_PATH
   

Deploy Apps:

1. piocda - use war file
2. portal - copy folder
3. vgn-ext-templating - use war file
4. furl - copy folder

Site does not publish, yet no errors

If a site in VCM shows status "Unpublished" even though there were no errors during publish, check if its associated with a Stage.

VgnVCMServer does not start

If VgnVCMServer does not start and keeps looping, try KB Item 9655. In logs the problem may show up as an IOException saying "too many open files" (error message may not be exactly same as what is mentioned in the KB Item).
Text of the KB item is below:
-----------------------------
Title
VCM in STANDBY mode due to "java.io.IOException: More than 2048 open files" exception.

Text

The issue started after modifying Active Directory settings in Runtime services
console.
VCM was in STANDBY state and the startup logs showed "java.io.IOException: More than 2048 open files"


SOLUTION
1. In the RTS Console, click on the "Security" node under vgndomain.
2. Click the "Embedded LDAP" tab.
3. Make sure that the check box next to "Refresh Replica At Startup" is
checked. (Click Apply if necessary.)
4. Stop the VCM Server, Admin Server, Node Manager and Config Agent.
5. Make sure that all processes are stopped.
6. Delete the following files:

Vignette\Content\7_3_1\rtsvcs\domains\vgndomain\VgnAdminServer\ldap\ldapfiles\changelog.data
Vignette\Content\7_3_1\rtsvcs\domains\vgndomain\VgnAdminServer\ldap\ldapfiles\changelog.index

7. Start the Admin Server, Node Manager and Config Agent.
8. In the RTS Console, start the VCM Server.

This will clear the change log so that the admin server no longer thinks there
are any embedded LDAP changes that need to be replicated. It will also cause
the VCM Server to automatically refresh its embedded LDAP replica.

If the VCM Server restarts successfully, monitor it for a few days to make sure
that the file handles on those files don't creep back up. Once it looks good,
change the "Refresh Replica At Startup" flag back to false and restart the VCM
Server.


STACK TRACE
weblogic.management.ManagementRuntimeException: java.io.IOException: More than
2048 open files
at weblogic.management.configuration.RepositoryMBean_Stub.saveDomain(RepositoryMBean_Stub.java:606)
at weblogic.management.console.utils.MBeans.saveDomain(MBeans.java:1015)
...
...
Caused by: java.io.IOException: More than 2048 open files
at java.io.FileOutputStream.open(Ljava.lang.String;)V(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:179)
at java.io.FileOutputStream.(FileOutputStream.java:131)

V7: Manually removing orphaned content instances

PROBLEM
-------
You can't delete a content type although the VCM doesn't show any associated
content instances. This error message appears in a JavaScript pop-up box:

The following validation error(s) occurred:
Cannot remove a type that currently has instances

This problem can occur when content instances are still associated with the
content type, even though they are not visible in the VCM.

SOLUTION
--------
You must remove the orphaned content instances from the database manually:

1. To find the ID of the content type in the VgnAsObjectType table, perform
this SQL query:

Select ID,name,displayname from VgnAsObjectType

Find the ID that corresponds to the content type you are trying to delete.
The ID should end in ____ and look something like this:

ac798d60f58b5010VgnVCM100000af3410ac____

2. Perform this SQL query:

select contentmgmtid from vgnasmometadata
where objecttypeid='()';

The query will return the orphaned content instance or instances that are
causing the problem. Each ID should end in RCRD and look something like
this:

e8ed0bd758db5010VgnVCM100000af3410acRCRD

3. Back up the system database.

4. For each item returned in step 2, perform the following SQL:

delete from vgnAsMoMap where recordId='';
delete from vgnAsMoMetaData where contentMgmtId='';
delete from vgnAsExtObjAttribs where recordId='';
delete from vgnAsChannelFileAssociation where vcmObjectId='';
delete from vgnRecord where id ='';
delete from vgnCMSObject where id = '';
delete from vgnObjectBlob where obj = '' AND indexField = 0;
delete from vgnRecordKeyMap where recordId ='';
delete from vgnObjectNote where object = '';
delete from vgnDeploymentData where object = '';
delete from vgnObjectHistory where object = '';
delete from vgnObjectSnapshotSet where obj = '';
delete from vgnCMSObjectGroupObjectSet where obj ='';
delete from vgnAssociation where cmsObjectId ='';
delete from vgnReferenceMap where referrerId = '' or referentId = '';

5. If everything went well, commit.

6. Now you should be able to delete the content type from the VCM.

Important KB Items

Content Schema Modeling Considerations in V7 Releases - KB 6058
Omniture Integration Guide for Vignette Content, Portal, Collaboration, and other products is now available at no charge on the Vignette Development Community - KB 9207
V7: My servlet works great on management stage but doesn't work on delivery stage: what's wrong? - KB 5872
SearchQuery.trackAndExecute() methods fail in stages running in EJB mode [01/23/03] - KB 5069
V7 7.3+: Checklist for setting up Java application that accesses management stage - KB 6900
JSP application to test V7 delivery stage application server or servlet engine - KB 6030
V7 7.3.1: Where the Log Files of V7 7.3.1 Components Are Located - KB 7897

If pages don't display on piocda and come back on refresh

If there is a situation that pages do not display on the site, but on refresh they come back (minus navigation sometimes), most likely piocda.war has been copied over to tomcat when it was running and piocda.xml from conf/Catalina/localhost has been wiped out. Make sure to stop tomcat before deploying and research a way so this does not happen. (piocda.xml should be made part of the webapp).

Update: Added new build file for each environment on VSS, so context.xml is part of the webapp and gets copied automatically to conf/Catalina/localhost on (re)deploy.