Skip Headers
Oracle® Collaboration Suite Migration and Coexistence Guide
10g Release 1 (10.1.1)
Part Number B14486-02
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
View PDF

7 Migrating Calendar Data from Netscape

To migrate calendar data from Netscape to Oracle Calendar, you must follow a specific migration path. This involves migrating calendar data from Netscape Calendar to CorporateTime and then upgrading from CorporateTime to Oracle Calendar. This chapter describes how to migrate calendar data from Netscape Calendar to Oracle Calendar.

The chapter contains the following migration scenarios:

Upgrading Netscape Calendar to CorporateTime 5.4

Before migrating from Netscape Calendar to CorporateTime 5.4, you need to shut down the Netscape Directory server and the Netscape Calendar server, and then back up the Netscape Calendar server database and configuration files.

The following are the tasks required when migrating from Netscape Calendar to CorporateTime 5.4:

Task 1: Back Up the Netscape Calendar Server

To back up the Netscape Calendar server:

  1. Stop the Netscape Directory server and Netscape Calendar server.

  2. Back up the Netscape Calendar database and configuration files:

    • On Windows:

      • Copy the entire C:\unison directory (and its subdirectories) to another drive or another computer.

      • Uninstall the Netscape Calendar server to remove all associated registry entries.

    • On UNIX:

      • Copy all the /users/unison/db/nodes/Nx (where x is an integer from 0 to the number of nodes in the server) directories (and their subdirectories) to a safe location.

      • Copy the /users/unison/misc directory to a safe location.

Task 2: Extending the Netscape Directory Server Schema

To extend the Netscape Directory server schema:

  1. Extract the following files from the CorporateTime 5.4 installation package and copy them to the /Netscape_Directory_Server_path/slapd-server_name/config directory:

    • oracle-calendar-schema.conf

    • oracle-calendar-globopt.conf

  2. Add the line in bold to the /Netscape_Directory_Server_path/slapd-server_name/config/slapd.conf file:

    include /Netscape_Directory_Server_path/slapd-server_name/config/ns-schema.conf
include /Netscape_Directory_Server_path/slapd-server_name/config/oracle-calendar-schema.conf

  3. Edit the /Netscape_Directory_Server_path/slapd-server/config/slapd-ldbm.conf file to include the following line at the bottom of the file:

    include /Netscape_Directory_Server_server_path/slapd-server_name/config/oracle-calendar-globout.conf

  4. Restart the Netscape Directory server to apply the configuration changes.

Task 3: Reconfiguring Directory Server Database

  1. Stop the Netscape Directory server and extract the LDAP server data for editing:

    $ ./stop-slapd
$ cd /Netscape_LDAP_server_path/bin/slapd/server
$ ./ns-slapd/db2ldif
    –f /Netscape_LDAP_server_path/slapd-server_name/config/slapd.conf
    –i /Netscape_LDAP_server_path/slapd-server_name/ldif/FILENAME

  2. Edit FILENAME as follows:

    • Replace all occurrences of nscal with ctcal.

    • Replace all occurrences of nsCal with ctCal.

  3. Load FILENAME into the Netscape LDAP server:

    $ ./ns-slapd/ldif2db
    –f /Netscape_LDAP_server_path/slapd-Server_name/config/slapd.conf
    –C
    –i /Netscape_LDAP_server_path/slapd-Server_name/ldif/FILENAME
$ ./start-slapd

Task 4: Installing CorporateTime 5.4

To install CorporateTime 5.4:

  1. Perform the installation process outlined in the CorporateTime Server 5.4 Readme, which is located at

    http://www.steltor.com/notes/corptime-server/5_4/readme.htm#1001884

    In the Readme file, follow the section "Installing CorporateTime Server with Internal Directory."

  2. Modify the unison.ini file so that it contains the appropriate node entries at the end of the file.

Upgrading CorporateTime to Oracle Calendar

You can automatically upgrade CorporateTime or Oracle Calendar 3.x data to the new version of the Oracle Calendar application system.

Refer to Oracle Collaboration Suite Installation guides for directions on how to upgrade from CorporateTime to Oracle Calendar standalone.

Upgrading Oracle Calendar to Oracle Collaboration Suite with Coexistence

This section outlines the upgrade process from Oracle Calendar standalone with a Lightweight Directory Access Protocol (LDAP) directory server, to Oracle Collaboration Suite 10g Release 1 (10.1.1) , which uses Oracle Internet Directory. In this scenario, the following LDAP directory servers are supported:

This scenario assumes that you have other applications that use a Netscape, iPlanet, or Sun ONE directory server and, therefore, you need to keep and manage this directory server along with the Oracle Internet Directory server. The Oracle Directory Integration Platform (DIP), a feature of Oracle Internet Directory, is used to keep the user data in both directory servers synchronized.

The section contains the following:

Some General Notes and Assumptions

Before you begin the procedure of upgrading to Oracle Collaboration Suite, take note of the following assumptions and limitations regarding this procedure.

Installing Oracle Collaboration Suite

You need to install Oracle Collaboration Suite and ensure that all the tiers of Oracle Collaboration Suite are running.

Refer to Oracle Collaboration Suite Installation Guide for Microsoft Windows for the installation details.

Migrating the Directory Entries

This section outlines how to migrate the directory data from the iPlanet, Netscape, or Sun ONE directory server to Oracle Internet Directory. This procedure involves exporting the directory entries from the iPlanet, Netscape, or Sun ONE directory server to an LDAP Data Interchange Format (LDIF) file, and then importing it into Oracle Internet Directory.

The following are the tasks that you require to perform to migrate directory entries:

Task 1: Exporting the Directory Entries from Netscape Directory Server

Use the ldapsearch command with the following syntax to export directory entries for resources:

$ORACLE_HOME/bin/ldapsearch -h Netscape_directory_server_hostname -p Netscape_directory_server_port -D manager_DN -w manager_DN_password -b baseDN "objectclass=ctcalresource" > resources_LDIFfile

Use the ldapsearch command with the following syntax to export directory entries for users and event calendars:

$ORACLE_HOME/bin/ldapsearch -h Netscape_directory_server_hostname -p Netscape_directory_server_port -D manager_DN -w manager_DN_password -b baseDN "objectclass=inetorgperson" > users_LDIFfile

The entries in the resulting LDIF files should look similar to the following:

dn: uid=hmoore,ou=People, dc=ca,dc=oracle,dc=com
uid:hmoore
sn:Moore
cn:Henry Moore
objectclass:top
objectclass:person
objectclass:organizationalPerson
objectclass:inetorgperson
objectclass:ctCalUser
givenname:Henry
ctcalxitemid:00010:00259
ctcalpublishedtype:0
...

Note:

With some older versions of ldapsearch, the line beginning dn: is not included in the file and all colons (:) are replaced by the equal to sign (=). In this case, modify the file so the user entries follow the same format as the example given.

Task 2: Analyzing the LDIF Files for Any Required Schema Additions Referenced in the LDIF Data

Before you import the LDIF files, you must add any attributes that are not in the Oracle Internet Directory base schema to the Oracle Internet Directory base schema.

If there were any modifications made to the base schema of your current directory server, you must make the same modifications to the base schema of the Oracle Internet Directory. However, this is only necessary if you also want to transfer the information in these attributes to the Oracle Internet Directory.

Some directory servers may support the use of configuration files for defining extensions to their base schema. However, Oracle Internet Directory does not. If you have a configuration file for your directory server, you can use it as a guideline for extending the base schema of the Oracle Internet Directory.

Task 3: Extending the Schema in Oracle Internet Directory

Use either the Oracle Directory Manager or the SchemaSynch tool to extend the schema in Oracle Internet Directory.

See Also:

Oracle Internet Directory Administrator's Guide

Task 4: Removing Any Proprietary Directory Data from the LDIF File

Various directory vendors implement access control item (ACI) policy objects in ways that do not translate well across vendor installations. Therefore, remove any ACI entries from the LDIF file.After the basic entry data has been imported from the cleaned up LDIF file to Oracle Internet Directory, you must explicitly reapply security policies in the Oracle Internet Directory environment. You can do this by using either Oracle Directory Manager, or command-line tools and LDIF files containing the desired access control policy (ACP) information.There may be other proprietary metadata unrelated to access control. You should remove this as well. Understanding the various Internet Engineering Task Force (IETF) Requests For Comments (RFCs) can help you determine which directory metadata is proprietary to a given vendor and which complies with the LDAP standards, and is portable using an LDIF file.

Task 5: Removing Operational Attributes from the LDIF File

Remove the following four operational attributes from the LDIF file:

  • creatorsName

  • createTimestamp

  • modifiersName

  • modifyTimestamp

These standard operational attributes are automatically generated by Oracle Internet Directory whenever entries are created or imported. It is not possible to instantiate these values by importing an LDIF file. Therefore, you should remove these attributes before importing the file.

Task 6: Removing Incompatible userPassword Attribute Values from the LDIF File

Oracle Internet Directory supports the following userPassword attribute hash algorithms:

  • No encryption

  • MD4

  • MD5

  • SHA

  • UNIX Crypt

If the userPassword attribute hash algorithm used by your directory server is not one of these, then remove all lines corresponding to the userPassword attribute and value from the LDIF data file. After you import the LDIF data into Oracle Internet Directory, manually re-enter or upload the hashed userPassword information into the directory.

Task 7: Adding the Oracle Internet Directory Object Classes to the LDIF Files

Many of the Oracle Collaboration Suite applications expect the user entry to contain orclUser and orclUserV2 object classes. Use the following script (convert.sh) to add these object classes to each user entry in the LDIF file.

Note:

To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:

The convert.sh Script

#!/bin/sh
SOURCEDN="ou=people, <basedn>"
TARGETDN="cn=users, <basedn>"
if [ "$1" = "" ]
then
  echo "usage: convert.sh filename"
exit 2;
fi
FILENAME=$1
while read XX
do
  if [ ! -z "`echo $XX | grep "$SOURCEDN"`" ]
  then
    # add "dn: " if necessary
    if [ -z "`echo $XX | grep "^dn:"`" ]
    then
      echo -n "dn: " >> $FILENAME.$$
    fi
    echo $XX | sed "s/$SOURCEDN/$TARGETDN/g" >> $FILENAME.$$
    echo "objectclass: orclUser" >> $FILENAME.$$
    echo "objectclass: orclUserV2" >> $FILENAME.$$
  else
    echo $XX >> $FILENAME.$$
  fi
done < $FILENAME
\mv $FILENAME.$$  $FILENAME

After you run convert.sh, the user entries in the LDIF file should look similar to the following:

dn: uid=hmoore,cn=users,dc=ca,dc=oracle,dc=com
objectclass: orclUser
objectclass: orclUserV2
uid:hmoore
sn:Moore
cn:Henry Moore
objectclass:top
objectclass:person
objectclass:organizationalPerson
objectclass:inetorgperson
objectclass:ctCalUser
givenname:Henry
ctcalxitemid:00010:00259
ctcalpublishedtype:0

You are now ready to import the directory entries into the Oracle Internet Directory server.

Task 8: Running bulkload.sh to Find Any Remaining Schema Violations or Duplication Errors (Optional)

Before you import the LDIF files, you can use the bulkload utility in check mode to perform a check on the LDIF file. The bulkload output reports any inconsistencies in the data.

Note:

To run shell script tools on the Windows operating system, you need one of the following UNIX emulation utilities:

See Also:

Oracle Internet Directory Administrator's Guide

Task 9: Importing the Modified LDIF Files into the Oracle Internet Directory Server

Import the modified LDIF files into the Oracle Internet Directory server using the following:

$ORACLE_HOME/bin/ldapadd -h OID_hostname -p OID_port -D "cn=orcladmin" -w orcladmin_password -f LDIFfile

Task 10: Converting the Directory Entries from Netscape to Oracle Internet Directory Format

Use the following command to convert the directory entries:

$ORACLE_HOME/ocal/bin/unioidconf -upgrade

You can safely ignore any warnings generated in the unioidconf.log file.

Configuring the Synchronization

Configure the synchronization between Oracle Internet Directory and the iPlanet, Netscape, or Sun ONE directory server.

The following are the tasks that you require to perform to configure the synchronization:

Task 1: Creating a Synchronization User Account on the iPlanet, Netscape, or Sun ONE Directory Server

The Oracle Internet Directory synchronization service needs to bind to a user account to access and optionally modify data on the iPlanet, Netscape, or Sun ONE directory server. Although it is possible to use an existing entry, it is highly recommended to create a new entry for this purpose. Take note of the distinguished name and the distinguished name password used for this entry.

Note:

Ensure the account password contains at least eight characters.

The synchronization user account must have certain access rights so that the Oracle Internet Directory synchronization service can perform the required operations. For example, if you wish to establish a one-way synchronization from the iPlanet, Netscape, or Sun ONE directory server to Oracle Internet Directory, the user account needs to have read access to the subtree and to all object classes and attributes to be synchronized. On the other hand, if you wish to establish a two-way synchronization, this user account need only have write access to the subtree.

Task 2: Creating a Retro Changelog Plugin on the iPlanet/Sun ONE 5.x Directory Server

The DIP synchronization service relies on a changelog capability to monitor any changes in the external directory server.

In the iPlanet or Sun ONE 5.x directory server, the changelog format has been modified and it is no longer compatible with DIP synchronization service. You must enable the Retro Changelog Plugin capability in the iPlanet or Sun ONE 5.x directory server in order to use the DIP synchronization service.

To enable the Retro Changelog Plugin feature in the iPlanet or Sun ONE directory server:

  1. Create an LDIF file with the following content:

    dn: cn=Retro Changelog Plugin, cn=plugins,cn=config
      changetype: modify
      replace: nssldapd-pluginenabled
      nssldapd-pluginenabled: on

  2. Apply the LDIF file using ldapmodify as follows:

    $ORACLE_HOME/bin/ldapmodify -h iplanethost -p iplanetport -D iplanetmgrdn -w iplanetmgrpassword -f ldif_filename

  3. Navigate to the slapd-hostname directory and run the following commands as root to restart the directory server.

    ./stop-slapd
./start-slapd

Task 3: Configuring Synchronization with Oracle Internet Directory

Once the external directory server is up, proceed with the following steps to configure the Oracle Internet Directory synchronization:

  1. Start the directory server console and log in as cn=manager with the password as Directory.

  2. Click the Server and Application tab.

  3. In the navigation tree, expand the ServerGroup container.

  4. Select the directory server instance to synchronize then click Open.

    A window for managing the directory server instance you selected is displayed.

  5. Click the Configuration tab.

  6. Select the Replication container.

  7. Click the Consumer Settings tab (Legacy Consumer Settings on iPlanet/Sun ONE 5.x directory server) and enter the synchronization user credentials.

    1. In the Supplier DN field, enter the distinguished name of the synchronization user.

    2. In the New Supplier Password field, enter the password for the synchronization user then click Confirm.

    3. Take note of these credentials as you will need them for the Oracle Internet Directory synchronization profile.

    4. Save the settings.

  8. Click the Supplier Settings tab.

  9. Set the Changelog Database Directory, if it has not been set.

  10. Save the settings.

  11. Obtain the value of the lastchangenumber attribute as you will need this value later. Use the following command:

    $ORACLE_HOME/bin/ldapsearch -h iPlanetHost -p iPlanetPort -D manager dn -w manager password -b "" -s base "objectclass=*" "lastchangenumber"

Task 4: Configuring the Login Attribute

To log in to an LDAP-enabled application users need to enter a login attribute and a password. On Netscape, iPlanet, or Sun ONE servers, the uid (user ID) attribute is the one that is typically used. On Oracle Internet Directory servers, the attribute is configurable and the default is the cn attribute.

You can specify the uid attribute as the login attribute on the Oracle Internet Directory server so that end-users can use the same login for LDAP-enabled applications connected to a Netscape, iPlanet, or Sun ONE directory server and for LDAP-enabled applications connected to an Oracle Internet Directory server.

To set uid as a login attribute, use the following steps:

  1. Create an LDIF file with the following contents.

    dn: cn=Common, cn=Products, cn=OracleContext, <basedn>
changetype: modify
replace: orclcommonnicknameattribute
orclcommonnicknameattribute: uid

  2. Use the ldapmodify command to change the login attribute to uid as follows.

    $ORACLE_HOME/bin/ldapmodify -h <OIDhost> -p <OIDport> -D cn=orcladmin -w <orcladminpassword> -f <LDIFfilename>

Task 5: Setting the Mapping Rules

The mapping rules specify which attributes are synchronized between the Netscape, iPlanet, or Sun ONE server and Oracle Internet Directory. The rules are defined in a mapping file which resides on the Oracle Internet Directory server.

To set the mapping rules:

  1. Using a text editor open the default mapping file at $ORACLE_HOME/ldap/odi/conf/iplanet.map.master

  2. Edit the domain rule to match your directory hierarchy. For example, given a source DN of ou=people,dc=ca,dc=oracle,dc=com and a target DN of cn=users,dc=oracle,dc=com the domain rule will be: ou=people,dc=ca,dc=oracle,dc=com:cn=users,dc=oracle,dc=com

  3. Edit the mapping file to define the mapping rules needed for your configuration.

    The completed file should look similar to the following:

    DomainRules
ou=people,dc=ca,dc=oracle,dc=com:cn=users,dc=ca,dc=oracle,dc=com
AttributeRules
# Mapping rules to map the domains and containers
o: : :organization: o: :organization
ou: : :organizationalUnit: ou: : organizationalUnit
dc: : :domain:dc: :domain
# Mapping Rules to map users
uid : : :person: uid: :inetOrgperson
sn: : :person:sn: :organizationalperson
cn: : :person:cn: :person
cn: : :person:orclisVisible: :orclUserV2:"True"
mail: : :inetorgperson: mail: :inetorgperson
employeenumber: : :organizationalPerson: employeenumber: :organizationalperson
c: : :country:c: :country
l: : :locality: l: :locality
telephonenumber: : :organizationalPerson: telephonenumber: :organizationalperson
userpassword: : :person:userpassword: :person
title: : :inetorgperson:title: :inetorgperson
givenname: : :inetorgperson:givenname: :inetorgperson
#Mapping rule to map calendar item
cn: : :person:cn: :ctcaluser
ctcalxitemid: : :ctcaluser:ctcalxitemid: :ctcaluser
ctcalpublishedtype: : :ctcaluser:ctcalpublishedtype: :ctcaluser

    Note:

    Ensure you have no extra spaces at the end of each line and no extra blank lines at the end of the file.

  4. Save the edited file with a .map extension (for example, iplanetmapfile.map).

Task 6: Configuring an Integration Profile

Once the mapping rules have been set, create an integration profile and register it to the Oracle Internet Directory server. This enables the synchronization service. The integration profile contains the information needed to synchronize data with the iPlanet directory server.

To configure an integration profile:

  1. Use the following command to upload the mapping file to the Oracle Internet Directory server.

    OracleHome_path/ldap/odi/admin/ldapUploadAgentFile.sh -name IplanetImport -LDAPhost OIDhostname -LDAPport OIDport -binddn cn=orcladmin -bindpass orcladminpassword -config 1 -attrtype "MAP" -filename fullpath/iplanetmapfile.map

    Note:

    • Make $ORACLE_HOME/bin the first path in the PATH environment variable.

    • Use the full path for the executable and the file location.

  2. Start the Oracle Directory Manager. Use the following command:

    $ORACLE_HOME/bin/oidadmin&

  3. Establish a connection to the Oracle Internet Directory server and log in as the directory manager.

  4. Expand the Server Management container.

  5. Expand the Integration Server container and then select the appropriate configuration set. In most cases, this is the first configuration set.

  6. Double-click the iPlanetImport profile.

    The Integration Profile: IPlanetImport window is displayed.

  7. Click the Execution tab.

  8. In the Connected Directory Account and Connected Directory Account Password fields, enter the distinguished name and distinguished name password of the synchronization user account created earlier.

  9. In the Connected Directory URL field, enter the hostname and port number of Netscape, iPlanet, or Sun ONE directory server. For example: iPlanet.oracle.com:589.

    Caution:

    It is very important to leave the Agent Execution Command field blank.

  10. Click the Mapping tab.

    Steps 11 and 12 prevent the same change from being exchanged between the two directories indefinitely.

  11. In the Connected Directory Matching Filter field, enter the following:

    modifiersname != <the distinguished name of the synchronization user>

  12. In the OID Matching Filter field, enter the following:

    modifiersname != orclodipagentname=iPlanetImport, cn=subscriber profile,cn=changelog subscriber, cn= oracle internet directory

  13. Click the Status tab.

  14. In the Last Applied Change Number field, enter the lastchangenumber attribute value obtained from the iPlanet directory server earlier.

Task 7: Granting Access Rights to the Oracle DIP Agent

For the synchronization to be successful, the Oracle DIP agent requires access rights to the user entries in the Oracle Internet Directory. Use Oracle Directory Manager to grant the necessary access rights.

To grant access rights to the Oracle DIP agent:

  1. In the Oracle Directory Manager interface, navigate to the System Objects navigation tree.

  2. In the System Objects navigation tree navigate to Entry Management, cn=OracleContext, cn=Groups, cn=IASAdmins.

  3. Click the Properties tab.

  4. In the uniquemember field, add the following user:

    orclodipagentname=IplanetImport,cn=subscriber profile,cn=changelog subscriber,cn=oracle internet directory

  5. Repeat this procedure for the following groups:

    • cn=OracleDASCreateUser

    • cn=OracleDASDeleteUser

    • cn=OracleDASEditUser

You must also propagate the access controls that you have set up in the Netscape, iPlanet, or Sun ONE directory server. For example, if you have an access control that says "only users with the attribute ou=HR Department is able to read the user salary attribute", you must create an equivalent access control in Oracle Internet Directory.

SeeAlso:

Oracle Internet Directory Administrator's Guide for more information on modifying access controls

Task 8: Starting the Synchronization Service

The Oracle Directory Integration Server provides the synchronization service.

See Also:

Oracle Internet Directory Administrator's Guide for more information on the Oracle Directory Integration Server

To start the synchronization service:

  1. Use the following command to start the Oracle Directory Integration Server.

    $ORACLE_HOME/bin/oidctl connect=database_instance_name server=odisrv instance=1 configset=1 flags="port=OIDport" start

    Note:

    Ensure the ORACLE_HOME and ORACLE_SID environment variables have been set.

  2. Click the General tab.

  3. Ensure the Profile Status is set to ENABLE.

  4. Click the Status tab and verify that the Synchronization Status is Synchronization Successful.

    The directory servers are now synchronized.

Migrating the Calendar Database

At this point, you have the following setup:

  • The old Calendar standalone server with a node network pointing to the iPlanet server

  • The new Oracle Collaboration Suite server installed and configured with a default node

  • A synchronization established between the Netscape, iPlanet, or Sun ONE Directory server and Oracle Internet Directory

Migrating the Calendar database involves moving a node from the Netscape, iPlanet, or Sun ONE server to the Oracle Collaboration Suite server then reconfiguring the node network to recognize this change. This section describes the steps required to complete the migration and reconfiguration for a node network.

The following are the tasks that you require to perform to migrate the Calendar database:

If you only have a single node as opposed to a node network, perform the steps listed in "Task 1: Moving the Database" and "Task 3: Creating a Calendar Node Entry on Oracle Internet Directory".

Task 1: Moving the Database

To move the Calendar database from Netscape, iPlanet, or Sun ONE Directory server to the Oracle Collaboration Suite server:

  1. Copy the master node directory ($ORACLE_HOME/ocal/db/nodes/N0) of the database, from the Calendar standalone server to the new server in the Oracle Collaboration Suite.

  2. Copy the [CLUSTER]masternode entry from the unison.ini file on the Calendar standalone server to the unison.ini file on the Oracle Collaboration Suite.

    Note:

    Legacy systems with only a single node may not have this [CLUSTER]masternode entry in the unison.ini file. If this is the case, skip this step and the next.

  3. In the unison.ini file on the Calendar standalone server, comment out the [CLUSTER]masternode entry as shown in the following example:

    #[CLUSTER]
#masternode = 10

  4. Copy the node information for the master node from the unison.ini file on the Calendar standalone server to the unison.ini file on the Oracle Collaboration Suite.

  5. In the unison.ini file on the Calendar standalone server, comment out the node information for the master node as shown in the following example:

    #[10]
#name = N0
#version = A.06.00
#timezone = EST5EDT
 
#[CLUSTER]
#masternode = 10
 
[21]
name = N1
version = A.06.00
timezone = EST5EDT

  6. In the unison.ini file on the Oracle Collaboration Suite, comment out the information on the installed node (not the master node information that was just placed in the file).

    The unison.ini file should look similar to the following:

    [CLUSTER]
masternode=10
 
#This is the information for the database copied from the iPlanet server
#calserver $ORACLE_HOME/ocal/db/nodes/N0 to the Oracle Internet Directory calendar server
#$ORACLE_HOME/ocal/db/nodes/N0
 
[10]
name = N0
version = A.06.00
timezone = EST5EDT
 
#Here is the node ID that was installed with the Collaboration Suite Calendar
#server. It has been replaced with the new node. 
 
#[11]
#name = N0
#version A.06.00
#timezone = EST5EDT

Task 2: Updating the Node Network Information on the Nodes

To preserve the node network and the related events and attendees information update the remotenode.ini file of each and every node in the Calendar node network. In the following procedure, the variable iplanet_node represents the node that is kept on the old Netscape, iPlanet, or Sun ONE server and the variable OID_node represents the node that was moved to the new Oracle Collaboration Suite server. The steps to update the node network information are:

  1. On the Calendar standalone server, run the following command:

    $ORACLE_HOME/ocal/bin/unidbfix -export -n iplanet_node

    This creates the $ORACLE_HOME/ocal/db/nodes/N1/perm/remotenode.ini. file

    Open the $ORACLE_HOME/ocal/db/nodes/N1/perm/remotenode.ini file.

    The contents of the file should appear similar to the following:

    [10]
RN_NUMCONNECT = 2
RN_ACCESSMETHOD = 2
RN_SERVICENAME = "unieng"
RN_HOSTNAME = "standalone.ca.acme.com:5802"

  2. Modify the remotenode.ini file with the new hostname and port of Oracle Collaboration Suite. The contents of the file should appear similar to the following:

    [10]
RN_NUMCONNECT = 2
RN_ACCESSMETHOD = 2
RN_SERVICENAME = "unieng"
RN_HOSTNAME = "ocs.ca.acme.com:5872"

  3. Update the remote host information with the following command:

    $ORACLE_HOME/ocal/bin/unidbfix -import -n iplanet_node

  4. On the Oracle Collaboration Suite server run the following command:

    $ORACLE_HOME/ocal/bin/unidbfix -export -n OID_node

    The variable OID_node is the node ID of the node that was copied to the Oracle Collaboration Suite server. This creates the $ORACLE_HOME/ocal/db/nodes/N0/perm/remotenode.ini file.

Task 3: Creating a Calendar Node Entry on Oracle Internet Directory

Use the Oracle Directory Manager to create an entry on the Oracle Internet Directory server for the node that was moved.

  1. Navigate to Entry Management, cn=Oracle Context, cn=Products, cn=Calendar, cn=Node installed_node

    The variable installed_node represents the node that was created when you installed Calendar.

  2. Right-click cn=Node installed_node and select Create Like.

  3. In the Distinguished Name field, change cn=Node to installed_nodecn=Node new_node.

    The variable new_node represents the node that was copied to the Oracle Collaboration Suite server.

  4. Click the Mandatory Properties tab.

  5. In the cn field, type Nodes new_node.

  6. Click the Optional Properties tab.

  7. Set the value of orclCalendarStore to new_node and click OK.

Task 4: Enabling the Replication of Calendar Data Between the Nodes

In the unison.ini file of the Oracle Collaboration Suite server set the [ENG]coexist_cwbasicauth parameter to TRUE.

Task 5: Regenerating the nodes.ini Files on both Calendar Servers

To regenerate the nodes.ini files:

  1. Start both servers.

  2. Rename the nodes.ini file on the Calendar server pointing to the Netscape, iPlanet, or Sun ONE directory server to nodes.ini.old.

  3. Run the following command on the Oracle Collaboration Suite server:

    uninode -init

    This generates the nodes.ini files with proper node network information on both servers.

The migration is now complete.

Upgrade Oracle Calendar to Oracle Collaboration Suite Without Coexistence

This scenario assumes that once the migration is complete the user accounts will be managed through the Oracle Internet Directory server. The section contains the following:

Note:

This procedure assumes that you have already upgraded the Oracle Calendar standalone installation to the latest release of Oracle Calendar.

Installing Oracle Collaboration Suite

When you install the Oracle Collaboration Suite, use the same node network configuration (nodes and node IDs) as your current configuration.

Refer to Oracle Collaboration Suite Installation Guide for Microsoft Windows for installation details.

Migrating the Directory Entries

Once you have Oracle Collaboration Suite installed you can migrate the directory entries from the Netscape, iPlanet, or Sun ONE directory server to the Oracle Internet Directory server.

Perform the following tasks to migrate directory entries:

Task 1: Stopping Both the Servers

Use the unistop utility to stop both the old standalone Oracle Calendar server and the new Oracle Collaboration Suite server.

Task 2: Exporting Directory Entries from the Netscape, iPlanet, or Sun ONE Directory Server into an LDIF File

Use the ldapsearch command with the following syntax to export directory entries for resources:

ldapsearch -h iplanet_hostname -p iplanet_port -D manager_DN -w manager_DN_password -b baseDN "objectclass=ctcalresource" > users_LDIFfile

Use the ldapsearch command with the following syntax to export directory entries for users and event calendars:

ldapsearch -h iplanet_hostname -p iplanet_port -D manager_DN -w manager_DN_password -b baseDN "objectclass=inetorperson" > resources_LDIFfile

The entries in the resulting LDIF files should look similar to the following:

dn: uid=hmoore,ou=People, dc=ca,dc=oracle,dc=com
uid:hmoore
sn:Moore
cn:Henry Moore
objectclass:top
objectclass:person
objectclass:organizationalPerson
objectclass:inetorgperson
objectclass:ctCalUser
givenname:Henry
ctcalxitemid:00010:00259
ctcalpublishedtype:0
...

Note:

With some older versions of ldapsearch, the line beginning dn: is not included in the file and all colons (:) are replaced by the equal to sign (=). In this case, modify the file so the user entries follow the same format as the example given.

Task 3: Analyzing the LDIF Files for Any Required Schema Additions Referenced in the LDIF Data

This task is identical to "Task 2: Analyzing the LDIF Files for Any Required Schema Additions Referenced in the LDIF Data".

Task 4: Extending the Schema in Oracle Internet Directory

This task is identical to "Task 3: Extending the Schema in Oracle Internet Directory".

Task 5: Removing Any Proprietary Directory Data from the LDIF File

This task is identical to "Task 4: Removing Any Proprietary Directory Data from the LDIF File".

Task 6: Removing Operational Attributes from the LDIF File

This task is identical to "Task 5: Removing Operational Attributes from the LDIF File".

Task 7: Removing Incompatible userPassword Attribute Values from the LDIF File

This task is identical to "Task 6: Removing Incompatible userPassword Attribute Values from the LDIF File"

Task 8: Adding the Oracle Internet Directory Object Classes to the User and Event Calendar Entries

This task is identical to "Task 7: Adding the Oracle Internet Directory Object Classes to the LDIF Files".

Task 9: Running the bulkload.sh -check Mode and Determine Any Remaining Schema Violations or Duplication Errors (Optional)

This task is identical to "Task 8: Running bulkload.sh to Find Any Remaining Schema Violations or Duplication Errors (Optional)".

Task 10: Importing the Modified LDIF Files into the Oracle Internet Directory Server

This task is identical to "Task 9: Importing the Modified LDIF Files into the Oracle Internet Directory Server".

Task 11: Converting the Directory Entries from iPlanet to Oracle Internet Directory Format

Use the following command to convert the directory entries:

unioidconf -upgrade

You can safely ignore any warnings generated in the unioidconf.log file.

Migrating the Calendar Database

Migrating the Calendar database involves moving the Calendar nodes from the Netscape, iPlanet, or Sun ONE server to the Oracle Collaboration Suite server then reconfiguring the node network to recognize this change. This section describes the tasks required to complete this migration and reconfiguration. The tasks are:

Task 1: Moving the Database

To move the Calendar database to Oracle Collaboration Suite:

  1. On the new Calendar server rename the $ORACLE_HOME/ocal/db directory to $ORACLE_HOME/ocal/db_blank.

  2. Copy the $ORACLE_HOME/ocal/db directory from the old standalone Calendar server to $ORACLE_HOME/ocal/db on the new Calendar server.

Task 2: Updating the Node Network Information on the New Server

Copy the $ORACLE_HOME/ocal/misc/nodes.ini file from the old standalone Calendar server to $ORACLE_HOME/misc/nodes.ini on the new Calendar server.

If the hostname of the new server has changed, do the following on the new Calendar server:

  1. Run the following command:

    unidbfix -export -n all

    This creates the $ORACLE_HOME/ocal/db/nodes/N#/perm/remotenode.ini file, where N# is the value of the name parameter in the unison.ini section corresponding to the target node.

  2. Modify the generated remotenode.ini file. Replace the old hostname and port with the new hostname and port. The remotenode.ini should be modified for each and every node in the Calendar node network.

  3. Update the host information with the following command:

    unidbfix -import -n all

  4. Modify the $ORACLE_HOME/ocal/misc/nodes.ini file. Replace the old hostname and port with the new hostname and port.

  5. Start the new Calendar server.

    The migration is now complete.

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Master Index
Master Index		 Go to Feedback page
Contact Us