| Oracle® Collaboration Suite Migration and Coexistence Guide 10g Release 1 (10.1.1) Part Number B14486-02 |
|
|
View PDF |
| Oracle® Collaboration Suite Migration and Coexistence Guide 10g Release 1 (10.1.1) Part Number B14486-02 |
|
|
View PDF |
This appendix describes how to migrate a standalone Calendar 10gR1 server with an internal directory to a standalone Calendar server with an external directory.
Note:
This migration procedure assumes all installations are on the same operating system.The appendix has the following sections:
To ensure a successful migration from an internal Calendar server deployment to external Calendar, it is important to take time to carefully plan the migration. If multiple Calendar servers existed in the standalone deployment, all the servers must be migrated at the same time. In addition, during the migration process, all Calendar servers must be stopped. Although a planned outage will be necessary, an effective preparation will help minimize migration time.
Migrating from an internal Calendar server deployment to external Calendar can be broken down into three steps:
Install the standalone external calendar.
Populate the iPlanet Directory Server with the user and resource information.
Migrate the Calendar nodes and adjust the node network.
When installing external Calendar, it is important to install a mirror image of the node setup that currently exists in your internal deployment. This means installing the same number of External Calendar servers, with the same number of nodes, same node IDs, same alias values, and the same masternode configuration. The first external Calendar server installed must correspond with the internal Calendar server masternode value. These new external Calendar servers will be installed against an iPlanet Directory.
The node IDs of the external Calendar installation should be the same as that of the existing internal Calendar server installation. Specify the proper NodeID during the installation phase.
To find the hostname and port for a Calendar server (either internal or external), see the $ORACLE_HOME/ocal/misc/unison.ini file and note the [ENG] calendarhostname and [ENG] port values. These form the host:port values in the following model table.
| NodeID | InternalHost | ExternalHost |
|---|---|---|
| nodeid1 | int_host1:port | ext_host1:port |
| nodeid2 | int_host1:port | ext_host1:port |
| nodeid3 | int_host2:port | ext_host2:port |
This table will be used later to help configure the calendar node network.
Once all the Oracle Collaboration Suite Calendar servers are installed, you must stop all Calendar servers. For more information on stopping and starting Oracle Calendar, see "Starting and Stopping the Calendar Server" in Chapter 5 of Oracle Calendar Administrator's Guide.
This section outlines how to migrate the user and resource entries to iPlanet Directory. This procedure involves exporting the user and resource entries from Oracle Calendar to an LDAP Data Interchange Format (LDIF) file and then importing the LDIF file into iPlanet Directory.
This section contains the following:
Use the unidb2ldif utility to export the user and resource entries from Oracle Calendar standalone internal to an LDIF file. You need to perform this operation against each and every node of your internal Calendar deployment while both the standalone internal server and the iPlanet Directory are active.
The unidb2ldif utility generates an LDIF file for each node. As a result, if you have a four-node network, you will have four generated LDIF files. Because the content of these files depend on the configuration you supply to unidb2ldif through its.ini file, it is important that the.ini file is set up properly.
See Also:
For more information about the
unidb2lidf utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.Note:
Theunidb2ldif utility is not available with external Calendar installations. It is intended for use with Oracle Calendar Standalone installations only.After you have generated the LDIF files, you must ensure that no new accounts get created, deleted, or modified on any internal Calendar server nodes. Any changes made to the accounts information done after the unidb2ldif is run are not applied to the external Calendar accounts.
If you allow logins by a resource, add a userPassword attribute to the resource entries in the LDIF file.
After modifying the LDIF file, verify that all the external Calendar servers are down. This can be accomplished by running the $ORACLE_HOME/ocal/bin/unistatus utility. For more information about the unistatus utility, see "Calendar Server Utilities" in Chapter 6 of Oracle Calendar Reference Manual.Then import the LDIF files into the iPlanet Directoryserver by using the following command:
$ORACLE_HOME/bin/ldapmodify -c -h iPlanet_hostname -p iPlanet_port -D "cn=orcladmin" -w orcladmin_password -f LDIFfile
You need to update the.ini files on the external Calendar installation for successful migration.
For each external Calendar server installation, copy any customizations that were made in the corresponding Calendar standalone unison.ini file. However, this is optional.
WARNING:
Do not overwrite the destination (external Calendar standalone) unison.ini file with the source (internal Calendar standalone) unison.ini file.
But you must:
Remove all the numeric sections [number] along with their keys from the unison.ini file of external Calendar. The following is an example of a numeric section:
[1234] name = N1 version = A.06.10 timezone = EST5EDT
Copy the numeric section from the internal standalone unison.ini file to the matching external Calendar server unison.ini file.
In addition to unison.ini, some of the configuration files may have been modified in your internal Calendar installation. So, for each external Calendar server installation, copy the following files (located in $ORACLE_HOME/ocal/misc) of the matching internal Calendar installation to the external Calendar installation:
user.ini
resource.ini
eventcal.ini
categories.ini
categorytype.ini
The most critical part of the migration process is migrating the Calendar database to external Calendar server.
Before the database migration, your Calendar system should be similar to the following:
The internal Calendar deployment is still up and running, but without any new account creations, modifications, or deletions.
The external deployment should be inactive, and the appropriate configuration files should be updated.
iPlanet Internet Directory filled with the accounts information from the internal Calendar deployment.
The following steps need to be taken for all Calendar standalone instances:
For each internal Calendar server, run $ORACLE_HOME/ocal/bin/unistop. This stops both the internal and the external Calendar servers.
On the external Calendar server, rename the $ORACLE_HOME/ocal/db directory to $ORACLE_HOME/ocal/db_blank. In addition, copy the $ORACLE_HOME/ocal/db directory from the internal Calendar server to $ORACLE_HOME/ocal/db on the matching (corresponding) external Calendar server.
Each of the Calendar databases stores a record with host information of other servers that are part of the node network. Use the mapping table that you have created in "Installing the Standalone External Calendar" to apply the appropriate changes to the node network on the migrated external Calendar instances.
The following are the steps to update node network information:
On an external Calendar server, run the following command:
$ORACLE_HOME/ocal/bin/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 within the node-specific section in the $ORACLE_HOME/ocal/misc/unison.ini file.
The content of remotenode.ini should look like the following with a section for each remote node:
[nodeid2] RN_NUMCONNECT = 3 RN_ACCESSMETHOD = 2 RN_SERVICENAME = "unieng" RN_HOSTNAME = "int_host1:port"
Modify the generated remotenode.ini files. Using your mapping table, replace the RN_HOSTNAME value from the internal hostname:port to the new external hostname:port.
[nodeid2] RN_NUMCONNECT = 3 RN_ACCESSMETHOD = 2 RN_SERVICENAME = "unieng" RN_HOSTNAME = "ext_host1:port"
Note:
You may have several[nodeid] sections in remotenode.ini, and all of them must be adjusted in this way.If the external Calendar server has several nodes, you will have several remotenode.ini files, one per N# directory. Update each of the files.
Update the host information using the following command:
$ORACLE_HOME/ocal/bin/unidbfix -import -n all
This must be done on all the external Calendar installations to ensure a consistent calendar node network.
After you migrate the Calendar database and update the node network information, you need to update the nodes.ini file. To do so:
Start all the external Calendar servers.
Locate the external server acting as the master node server. The Calendar server with the $ORACLE_HOME/ocal/misc/nodes.ini file houses the masternode, and will be on the first external Calendar tier that was installed.
Run $OH/ocal/bin/uninode -init to update $ORACLE_HOME/ocal/misc/nodes.ini.
Edit the $ORACLE_HOME/ocal/misc/nodes.ini file and verify that all the information matches.
Notify end users of the change in hostname and port. End users will need to reconfigure their Oracle Connector for Outlook, Oracle Calendar desktop clients, Oracle Calendar Sync clients to reflect the new hostname and port information. Additionally, this information may need to be modified for the Oracle Calendar Web client.
