1. Migrating Oracle WebCenter Content
  2. Migrate Clustered WebCenter Content 12c to New Hosts on a Dissimilar Infrastructure

7 Migrate Clustered WebCenter Content 12c to New Hosts on a Dissimilar Infrastructure

If you would like to move clusters of WebCenter Content Release 12c to an infrastructure where Operating System and directory structure of WebCenter Content will differ from those on the existing infrastructure, then the topics that follow will guide you in accomplishing your goal.

Note:

The versions of WebLogic Server and WebCenter Content must match between the old hosts and the new hosts. The following topics DO NOT include instructions for upgrading to a newer version but for migrating current setup of WebCenter Content. To migrate other Oracle products from the existing infrastructure such as WebCenter Portal or BPM, make sure to take in account the required instructions. These topics focus only on migrating WebCenter Content.

Topics

7.1 Preliminary Steps for Migrating Clustered WebCenter Content 12c to a Dissimilar Infrastructure

Make sure to follow these steps before you start the migration process:
  1. Stop all managed servers, the admin server, and the node manager.
  2. Back up WebCenter Content file system.
  3. Back up WebCenter Content's database.
  4. Install the same JDK version on the new host as the one on the old host.
  5. Install WebLogic Server's binaries on the new host.
  6. Install WebCenter Content's binaries on the new host.
  7. Install the same patches on the new host as were applied to the old host.
  8. If WebCenter Content is being migrated, detach/unmount the shared file system from the old hosts.
  9. If WebCenter Content is being cloned, detach/unmount the shared file system from the old hosts and also copy the shared file system to its new location.
  10. There are a few scenarios in which the database will be moving as well. One such scenario is when WebCenter Content is moving to the Oracle Cloud. A second scenario is when the database is moving to a new infrastructure for an on-premise migration. A third scenario could be that WebCenter Content is being cloned. In any of these cases, the database schemas are assumed to be available in their new database instance and reachable from the new hosts on which WebCenter Content will reside. When the Configuration Wizard (config.sh) is run, additional steps will need to be taken to ensure connectivity to the database schemas in their new location.There are three objects within the system schema that are required for Fusion Middleware to operate properly, especially when it comes to upgrades. These objects are: schema_version_registry view, schema_version_registry synonym, and schema_version_registry$ table. If any of these items are missed, you must follow the steps in Recover Lost RCU Database SYSTEM.SCHEMA_VERSION_REGISTRY Objects to recreate the missing objects in the new database instance to prevent issues in the future. In addition to that, you must also include all of the schemas whose names contain the prefix that you defined for the environment in question.

7.2 Recover Lost RCU Database SYSTEM.SCHEMA_VERSION_REGISTRY Objects

The SYSTEM.SCHEMA_VERSION_REGISTRY schema version registry table contains version data for all the schemas. Many operations such as upgrade cannot proceed if this table is not available.

To restore lost database objects:
  1. Check if the schema version registry table/view/synonym are present:
    1. Run following database queries while connected to the repository database as user with the sysdba priviledge
    2. If SYSTEM.SCHEMA_VERSION_REGISTRY$.TABLE is present and only view/synonym is missing go to step 7.
      column OWNER format a10
select owner, object_name, object_type from all_objects where object_name like'%SCHEMA_VERSION_REGISTRY%';

OWNER OBJECT_NAME OBJECT_TYPE
---------- ------------------------------ -------------------
SYSTEM SCHEMA_VERSION_REGISTRY VIEW
PUBLIC SCHEMA_VERSION_REGISTRY SYNONYM
SYSTEM SCHEMA_VERSION_REGISTRY$ TABLE
  2. Use the same version of RCU that was used to create the schemas initially. Run RCU against the existing repository and create schemas with a new PREFIX. DEV1 will be used for the rest of the steps as the new prefix.
  3. Create duplicate entries in schema_version_registry by making copies of the original schemas. DEV will be used in the rest of the steps as the original prefix.
    1. Display schema entries that RCU execution just created for DEV1.
      select rowid, mrc_name, owner from system.schema_version_registry$;
ROWID MRC_NAME OWNER
----------------- ------------------------------ ------------------------------
AAASqQAABAAAUmJAAA DEV1 DEV1_MDSAAASqQ
AABAAAUmJAAB DEV1 DEV1_ORASDPM
AAASqQAABAAAUmJAAC DEV1 DEV1_SOAINFR
AAAASqQAABAAAUmJAAD DEV1 DEV1_ORABA
    2. Create duplicate entries in system.schema_version_registry$ from DEV1.
      insert into system.schema_version_registry$ select * from system.schema_version_registry$ where mrc_name='DEV1';
    3. Run query to display the duplicate entries.
      select rowid, mrc_name, owner from system.schema_version_registry$;

Example:
ROWID MRC_NAME OWNER
----------------- ------------------------------ ------------------------------
AAASqQAABAAAUmJAAA DEV1 DEV1_MDS
AAASqQAABAAAUmJAAB DEV1 DEV1_ORASDPMAAASqQ
AABAAAUmJAAC DEV1 DEV1_SOAINFR
AAAASqQAABAAAUmJAAD DEV1 DEV1_ORABAMAAASqQ
AABAAAUmJAAE DEV1 DEV1_MDSAAASqQ
AABAAAUmJAAF DEV1 DEV1_ORASDPMAAASqQ
AABAAAUmJAAG DEV1 DEV1_SOAINFR
AAAASqQAABAAAUmJAAH DEV1 DEV1_ORABAM
  4. Alter the duplicate entries to match the original schema PREFIX in the MRC_NAME column. This is done by using the ROWID column to distinguish the newly created RCU entries from the duplicates just made. Note that these ROWID values will be different for your database than this example shows. Using DEV as the original schema prefix.
    update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_MDS' where rowid='AAASqQAABAAAUmJAAE';
update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_ORASDPM' where rowid='AAASqQAABAAAUmJAAF';
update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_SOAINFRA' where rowid='AAASqQAABAAAUmJAAG';
update system.schema_version_registry$ set mrc_name='DEV', owner='DEV_ORABAM' where rowid='AAASqQAABAAAUmJAAH';
  5. Display the change showing the original prefix (DEV).
    select mrc_name, owner, status from schema_version_registry where mrc_name='DEV';

MRC_NAME OWNER STATUS
------------------------------ ------------------------------ -----------
DEV DEV_ORABAM LOADINGDEV 
DEV_MDS VALIDDEV 
DEV_ORASDPM VALIDDEV 
DEV_SOAINFRA VALID
  6. Commit changes
    commit;
  7. Create public synonym and view for system.schema_version_registry$.
    create view system.schema_version_registry as select comp_id, comp_name,mrc_name, mr_name, mr_type, owner, version, status, upgraded, start_time,modified, edition from system.schema_version_registry$;

create public synonym SCHEMA_VERSION_REGISTRY FOR SYSTEM.SCHEMA_VERSION_REGISTRY;
  8. May need to grant proper privilege to some schemas (eg. If schemas privs were lost during export/import). This step is site-specific and will depend on your situation and schemas created.
    For example:
grant select on system.schema_version_registry to DEV_IAU ;
grant select on system.schema_version_registry to DEV_IAU_APPEND;
grant select on system.schema_version_registry to DEV_IAU_VIEWER;
grant select on system.schema_version_registry to DEV_MDS ;
grant select on system.schema_version_registry to DEV_OPSS;
  9. Run RCU again to drop all the schemas that were created when run in Step#2 above. This will leave just the modified schema_version_registry entries for the PREFIX (Example: DEV) schemas in the system.schema_version_registry$ table that were just added.

7.3 Build a Template for an Existing Domain

After you've performed the preliminary steps, build a template for the domain you plan to migrate.

To build a template:
  1. Run the Template Builder on the host on which the admin server is running (in this example, apphost1).
    $ORACLE_HOME/oracle_common/common/bin/config_builder.sh
  2. In the Template Builder dialog box:
    1. On the Template Type page, select Create Domain Template and Use Domain as a Source, for Source Location, provide the directory of the domain for which you're creating this template, for Template Location, provide a name and location to save the new template.
    2. On the Template Information page, confirm the values and click Next.
    3. On the Template Summary page, confirm the values and click Create.
    4. On the Configuration Progress page, click Next.
    5. On the End of Configuration page, click Finish.
  3. Copy the domain template that was just created to the new host on which the new admin server will reside.

7.4 Create a New Domain

You've created the domain template and copied it to the new host to which you are migrating your clustered WebCenter Content 12c instance. Now create a new domain on the new host.

To create a new domain:
  1. Run the Fusion Middleware Configuration wizard on the new host using the template that was just created:
    $ORACLE_HOME/oracle_common/common/bin/config.sh
  2. In the Fusion Middleware Configuration Wizard dialog box:
    1. On the Create Domain page, select Create a new domain, provide a domain location and then click Next.
    2. On the Templates page, select Create Domain Using Custom Template, provide a template location, and click Next.
    3. On the Application Location page, provide an application location and click Next.
    4. On the Administrator Account page, provide values for Name, Password, and Confirm Password, and then click Next.
    5. On the Domain Mode and JDK page, select a domain mode and JDK, click Next.
    6. On the JDBC Data Sources page, do one of the following (as applicable):
      • If the database is not moving, select the MDS datasource and click Next.
      • If the database is moving, select MDS schema, then enter the new values for Host Name, DBMS/Service, Port, Username, and Password, and then click Next.
    7. On the JDBC Data Sources Test page, select the mds-WCCUIMDSREPO data source, then click Test Selected Connections. Ensure a successful test and then click Next.
    8. On the Database Configuration Type page, do one of the following (as applicable):
      • If the database is not moving, select Get RCU Configuration, and click Next.
      • If the database is moving, do the following:
        1. Enter the new values for Host Name, DBMS/Service, Port, Schema Owner, and Schema Password.
        2. Select Get RCU Configuration and click Next.
    9. On the JDBC Component Schema page, do one of the following (as applicable):
      • If the database is not moving, select the schema and click Next.
      • If the database is moving, enter the new values for Host Name, DBMS/Service, Port, Schema Owner, and Schema Password for each of the data sources and click Next.

      Note:

      If multiple data sources are selected on this page, then the value can be changed for the same field at the same time for all of the selected data sources.

    10. On the JDBC Component Schema Test page, do one of the following (as applicable):
      • Select all connections/component schemas, then click Test Selected Connections.
      • Ensuring a successful test, click Next.
    11. On the Advanced Configuration page, select Administration Server, Node Manager, Topology, and System Components, and then click Next.
    12. On the Administration Server page, provide an updated value for Listen Address from the new host on which the admin server will be residing and click Next.
    13. On the Node Manager page, confirm user name and passwords and click Next.
    14. On the Managed Servers page, provide an updated value for the Listen Address and Listen Port of each managed server and click Next.
    15. On the Clusters page, confirm the clusters and click Next.
    16. On the Server Templates page, click Next.
    17. On the Dynamic Servers page, click Next.
    18. On the Assign Servers to Clusters page, confirm the assignments and then click Next.
    19. On the Coherence Clusters page, click Next.
    20. On the Machines page, provide an updated value for the Node Manager Listen Address and Listen Port and then click Next.
    21. On the Assign Servers to Machines page, confirm the existing assignments if no machines were reworked for the node manager. Otherwise, map the managed servers and the admin server to the appropriate machines, and then click Next.
    22. On the Virtual Targets page, click Next.
    23. On the Partitions page, click Next.
    24. On the System Components page, confirm the listing of system components and click Next.
    25. On the OHS Server page, (do this for all OHS instances by selecting each instance from the System Component drop-down list), confirm the values for Admin Host, Admin Port, Listen Port, SSL Listen Port, provide an updated value for Listen Address, and then click Next.
    26. On the Assign System Components to Machines page, confirm the assignments and then click Next.
    27. On the Configuration Summary page, click Create.
    28. On the Configuration Progress page, click Next.
    29. On the End of Configuration page, click Finish.

7.5 Update JPS Configuration with New Database Information

If the database is moving, a couple of configuration files need to be modified using the steps below. However, if the database is not moving, ignore this procedure and continue with the next that describes how to copy the UCM directory to the new host.

  1. On the new apphost1, in a terminal window, go to the DOMAINHOME/config/fmwconfig directory on the new host.
  2. In the jps-config.xml file, update the jdbc.url property with the new JDBC connection string information for the new database location and then save the changes.
  3. In the jps-config-jse.xml file, make the following changes, and then save your changes:
    • Update the jdbc.url property with the new JDBC connection string information for the new database location.
    • Update the audit.loader.jdbc.string property with the JDBC connection string information for the new database location.

7.6 Disable Host Name Verification

To disable host name verification:
  1. Start the admin server on the target host (in this example, apphost1) and wait until the status shows as RUNNING.
  2. Login to the Admin server console. If running in production mode, click Lock & Edit in the Change Center.
  3. Go to Environment > Servers > AdminServer(admin).
  4. Click the SSL tab, then click Advanced.
  5. Set Hostname Verification to None and click Save.
  6. Go to Environment > Servers > your WebCenter Content server 1 (In this example, UCM_server1).
  7. Click the SSL tab and then click Advanced.
  8. Confirm Hostname Verification is set to None and click Save.
  9. Go to Environment > Servers > your WebCenter Content server 2 (In this example, UCM_server 2).
  10. Click the SSL tab and then click Advanced.
  11. Confirm Hostname Verification is set to None and click Save.
  12. Go to Environment > Servers > Oracle Inbound Refinery 1 (in this example, IBR_server1).
  13. Click the SSL tab and then click Advanced.
  14. Confirm Hostname Verification is set to None and click Save.
  15. Go to Environment > Servers > Oracle Inbound Refinery 2 (in this example, IBR_server2).
  16. Click the SSL tab and click Advanced.
  17. Confirm Hostname Verification is set to None and click Save.
  18. Go to Environment > Servers > WebCenter Content ADF 1 (in this example, WCCADF_server1).
  19. Click the SSL tab and click Advanced.
  20. Confirm Hostname Verification is set to None and click Save.
  21. Go to Environment > Servers > WebCenter Content ADF 2 (in this example, WCCADF_server2).
  22. Click the SSL tab and click Advanced.
  23. Confirm Hostname Verification is set to None and click Save.
  24. If running in production mode, click Activate Changes in the Change Center.

7.7 Mount Shared File System and Adjust Configuration Settings for WebCenter Content

If WebCenter Content was migrated, mount the shared file system at this time. Instead, if it was cloned, mount the shared file system from the new location at this time.

To adjust configuration settings of the WebCenter Content node:
  1. Open the DOMAINHOME/ucm/cs/bin/UCM_server1_intradoc.cfg file on the new host 1 (in this example, apphost1) and, if necessary, update the values.
    Update the following and then save the changes:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  2. Open the DOMAINHOME/ucm/cs/bin/intradoc.cfg file on the new/target host (in this example, apphost1) to confirm or, if necessary, update the values.
    Update the following and then save the changes:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  3. Edit WebCenter Content's config.cfg files to include the updated host name for SocketHostNameSecurityFilter or IP address for SocketHostAddressSecurityFilter.
  4. If the load balancer's address is going to change, edit WebCenter Content's config.cfg on the shared file system to include the updated host name for HttpServerAddress.
  5. Edit your load balancer's configuration with the new backend hosts' addresses for WebCenter Content.
  6. Open the DOMAINHOME/nodemanager/nodemanager.properties file on the new/target host 1 (in this example, apphost1).
  7. If switching to or from Windows with another operating system that is not Windows, change the value for the weblogic.StartScriptName entry and save the change.

7.8 Verify that UCM_server1 Starts on the New Host

  1. On the target cluster, start the node manager on apphost1.
  2. In the Domain Structure, go to Environment > Servers.
  3. On the Control tab, select the check box for WebCenter Content 1 (in this example, UCM_server1).
  4. Click Start and then Yes to confirm.
  5. Above the Servers table, click the refresh arrow and note that UCM_server1's state changes to RUNNING.
  6. Open a browser and confirm that the portal.htm on the new apphost1 host loads successfully.

7.9 Perform Pack and Unpack Operations to Extend the Domain to the Second Node

  1. From the existing Administration Console browser tab, go to Environment > Servers.
  2. On the Control tab, select the check box for WebCenter Content 1 (in this example, UCM_server1).
  3. Click Shutdown/Force Shutdown Now (If Force is not used, running state issues will be experienced.)
  4. Click Yes to confirm.
  5. Above the Servers table, click the refresh arrow. Note that UCM_server1's state changes to SHUTDOWN.
  6. Stop the admin server from running in its terminal/console window.
  7. From the new apphost1, open a terminal/console window and go to the shared file system.
  8. Run the pack command:
    FMW_HOME/oracle_common/common/bin/pack.sh -managed=true -domain=/u01/oracle/user_projects/domains/cluster_domain -template=cluster.jar -template_name="cluster_domain"
  9. On apphost2, open a terminal.
  10. Go to the FMW_HOME/oracle_common/common/bin directory and run the unpack command:
    ./unpack.sh -domain=/u01/oracle/user_projects/domains/cluster_domain -template=/<SHAREDFILESYSTEM>/cluster.jar

7.10 Copy WebCenter Content Directory to the New Host

Several tools are available to help you copy the WebCenter Content directory to the new host. In this example, we'll use rsync to copy from one Linux host to another.

To copy the WebCenter Content directory to the new host:
  1. Run mkdir ucm on target host (in this example, apphost2) in the DOMAINHOME directory.
  2. Copy the DOMAINHOME/ucm directory from the old/source host (in this example, apphost2) to the new/target host (in this example, apphost2).
    rsync -avzh ucm/ oracle@targetapphost2.domain.com:DOMAINHOME/ucm
In this case, target = apphost2

7.11 Adjust Configuration Settings for WebCenter Content

To adjust configuration settings of the WebCenter Centent node:
  1. Open the DOMAINHOME/ucm/cs/bin/<managedservername>_intradoc.cfg file on the new host 2 (in this example, apphost2) and, if necessary, update the values.
    Update the following and then save the changes:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  2. Open the DOMAINHOME/ucm/cs/bin/intradoc.cfg file on the new/target host (in this example, apphost2) to confirm or, if necessary, update the values.
    Update the following and then save the changes:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  3. Open the DOMAINHOME/nodemanager/nodemanager.properties file on the new apphost2.
  4. If switching to or from Windows with another operating system that is not Windows, change the value for the weblogic.StartScriptName entry and save the change.

7.12 Verify that UCM_server2 Starts on the New Host

  1. On the target cluster, on apphost2, start the node manager.
  2. On the target cluster, on apphost1, start the admin server and proceed to the next step after the admin server's state changes to RUNNING.
  3. In the Admin Server Console, in the Domain Structure, go to Environment > Servers.
  4. On the Control tab, select the check box for UCM_server2.
  5. Click Start, then click Yes to confirm.
  6. Above the Servers table, click the refresh arrow. Observe that UCM_server2’s state changes to RUNNING.
  7. Open a browser and confirm that the portal.htm on the new apphost2 host loads successfully.
  8. From the existing Administration Console browser tab, go to Environment > Servers.
  9. On the Control tab, select the check box for UCM_server2.
  10. Click Shutdown/Force Shutdown (If Force is not used, running state issues will be experienced.)
  11. Click Yes to confirm.
  12. Above the Servers table, click the refresh arrow. Observe that UCM_server2’s state changes to SHUTDOWN.

7.13 Adjust Configuration Settings for Inbound Refineries

  1. Open the DOMAINHOME/ucm/ibr/config/config.cfg file on the new host 1 (in this example, apphost1).
  2. Provide the updated host name and port as the value for HttpServerAddress.
  3. Provide host name for SocketHostNameSecurityFilter or IP address for SocketHostAddressSecurityFilter and save the changes.
  4. Open the DOMAINHOME/ucm/ibr/bin/MANAGEDSERVERNAME_intradoc.cfg file on the new host 1 (in this example, apphost1) and update the following and then save the changes.
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  5. Open the DOMAINHOME/ucm/ibr/bin/intradoc.cfg file on the new apphost1 host and update the following and then save the changes.
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  6. Open the DOMAINHOME/ucm/ibr/config/config.cfg file on the new host 2 (in this example, apphost2).
  7. Provide the updated host name and port as the value for HttpServerAddress.
  8. Provide host name for SocketHostNameSecurityFilter or IP address for SocketHostAddressSecurityFilter and save the changes.
  9. Open the DOMAINHOME/ucm/ibr/bin/MANAGEDSERVERNAME_intradoc.cfg file on the new host 2 (in this example, apphost2) and update the following and then save the changes.
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  10. Open the DOMAINHOME/ucm/ibr/bin/intradoc.cfg file on the new apphost2 host and update the following and then save the changes.
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir

7.14 Verify that Inbound Refineries Start Successfully on New Hosts

  1. In the Admin Server Console, in the Domain Structure, go to Environment > Servers.
  2. On the Control tab, select the check box for IBR_server1 and IBR_server2.
  3. Click Start, then click Yes to confirm.
  4. Above the Servers table, click the refresh arrows for both servers. Observe that IBR_server1’s and IBR_server2's states change to RUNNING.
  5. Verify that you are able to log into both refineries.

7.15 Swap Out Executables

If the operating system has changed or directory paths have changed, you will need to replace the executables or redo the symbolic links with the proper ones. Here are a few possible scenarios.

7.15.1 Windows to Linux

  1. Delete .exe files in the DOMAINHOME/ucm/cs/bin directory on the new Linux host.
  2. In the DOMAINHOME/ucm/cs/bin directory, create a symbolic link to FMWHOME/wccontent/ucm/idc/native/Launcher.sh::
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  3. In the DOMAINHOME/ucm/cs/bin directory, create symbolic links to DOMAINHOME/ucm/cs/bin/Launcher.sh called:
    • Archiver
    • BatchLoader
    • ComponentTool
    • ComponentWizard
    • ConfigurationManager
    • IdcAnalyze
    • IdcCommand
    • IdcServer
    • IdcShell
    • Installer
    • IntradocApp
    • RepositoryManager
    • SystemProperties
    • UnixProcCtrl
    • UserAdmin
    • WebLayoutEditor
    • WorkflowAdmin

    Example:

    ln -s Launcher.sh Archiver
  4. Go to the DOMAINHOME/ucm/cs/admin/bin directory and delete the following items:
    • IdcAdmin.exe
    • IdcAdminNT.exe
    • NTProcCtrl.exe
  5. Create the symbolic link for the Launcher.sh using the new location:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  6. Create the symbolic links for IdcAdmin and UnixProcCtrl to point to the DOMAINHOME/ucm/cs/admin/bin/Launcher.sh:
    ln -s Launcher.sh IdcAdmin
ln -s Launcher.sh UnixProcCtrl
  7. Repeat steps 1 through 4 for other content server cluster nodes in the domain.
  8. If a refinery was moved, delete the .exe files in the DOMAINHOME/ucm/ibr/bin directory.
  9. In the DOMAINHOME/ucm/ibr/bin directory, create a symbolic link to the FMWHOME/wccontent/ucm/idc/native/Launcher.sh.
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  10. In the DOMAINHOME/ucm/ibr/bin directory, create symbolic links to DOMAINHOME/ucm/ibr/bin/Launcher.sh called:
    • ComponentWizard
    • IdcCommand
    • IdcRefinery
    • Installer
    • SystemProperties
    • UnixProcCtrl

    Example:

    ln -s Launcher.sh ComponentWizard
  11. Go to the DOMAINHOME/ucm/ibr/admin/bin directory and delete the following items:
    • IdcAdmin.exe
    • IdcAdminNT.exe
    • NtProcCtrl.exe
  12. Create the symbolic link for the Launcher.sh using the new location:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  13. Create the symbolic links for IdcAdmin and UnixProcCtrl to point to the DOMAINHOME/ucm/ibr/admin/bin/Launcher.sh:
    ln -s Launcher.sh IdcAdmin
ln -s Launcher.sh UnixProcCtrl
  14. Repeat steps 8 through 13 for other refineries in the domain.

7.15.2 Linux to Linux

  1. Go to the DOMAINHOME/ucm/cs/bin directory and delete the Launcher.sh symbolic link.
  2. Create the symbolic link for the Launcher.sh using the new location:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  3. Delete the items below:
    • Archiver
    • BatchLoader
    • ComponentTool
    • ComponentWizard
    • ConfigurationManager
    • IdcAnalyze
    • IdcCommand
    • IdcServer
    • IdcShell
    • Installer
    • IntradocApp
    • RepositoryManager
    • SystemProperties
    • UnixProcCtrl
    • UserAdmin
    • WeblayoutEditor
    • WorkflowAdmin
  4. Create the various symbolic links to point to the Launcher.sh:
    ln -s Launcher.sh Archiver
ln -s Launcher.sh BatchLoader
ln -s Launcher.sh ComponentTool
ln -s Launcher.sh ComponentWizard
ln -s Launcher.sh ConfigurationManager
ln -s Launcher.sh IdcAnalyze
ln -s Launcher.sh IdcCommand
ln -s Launcher.sh IdcServer
ln -s Launcher.sh IdcShell
ln -s Launcher.sh Installer
ln -s Launcher.sh IntradocApp
ln -s Launcher.sh RepositoryManager
ln -s Launcher.sh SystemProperties
ln -s Launcher.sh UnixProcCtrl
ln -s Launcher.sh UserAdmin
ln -s Launcher.sh WeblayoutEditor
ln -s Launcher.sh WorkflowAdmin
  5. Go to the DOMAINHOME/ucm/cs/admin/bin directory and delete the following items:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  6. Create the symbolic link for the Launcher.sh using the new location:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh
  7. Create the symbolic links for IdcAdmin and UnixProcCtrl to point to the DOMAINHOME/ucm/cs/admin/bin/Launcher.sh.
  8. Repeat steps 1 through 4 for other WebCenter Content cluster nodes in the domain.
  9. Go to the DOMAINHOME/ucm/ibr/bin directory and delete the Launcher.sh.
  10. Create the symbolic link for the Launcher.sh using the new location:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  11. Delete the items below:
    • ComponentWizard
    • IdcCommand
    • IdcRefinery
    • Installer
    • SystemProperties
    • UnixProcCtrl
  12. Create the symbolic links to point to the DOMAINHOME/ucm/ibr/bin/Launcher.sh:
    ln -s Launcher.sh ComponentWizard
ln -s Launcher.sh IdcCommand
ln -s Launcher.sh IdcRefinery
ln -s Launcher.sh Installer
ln -s Launcher.sh SystemProperties
ln -s Launcher.sh UnixProcCtrl
  13. Go to the DOMAINHOME/ucm/ibr/admin/bin directory and delete the following items:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  14. Create the symbolic link for the Launcher.sh using the new location:
    ln -s FMWHOME/wccontent/ucm/idc/native/Launcher.sh Launcher.sh
  15. Create the symbolic links to point to the DOMAINHOME/ucm/ibr/admin/bin/Launcher.sh:
    ln -s Launcher.sh IdcAdmin
ln -s Launcher.sh UnixProcCtrl
  16. Repeat steps 9 through 15 for other refineries in the domain.

7.15.3 Linux to Windows

  1. Go to the DOMAINHOME/ucm/cs/bin directory and delete these items:
    • Archiver
    • BatchLoader
    • ComponentTool
    • ComponentWizard
    • ConfigurationManager
    • IdcAnalyze
    • IdcCommand
    • IdcServer
    • IdcShell
    • Installer
    • IntradocApp
    • RepositoryManager
    • SystemProperties
    • UnixProcCtrl
    • UserAdmin
    • WebLayoutEditor
    • WorkflowAdmin
  2. Copy the FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exe to the DOMAINHOME/ucm/cs/bin directory
  3. Copy the DOMAINHOME/ucm/cs/bin/Launcher.exe to the DOMAINHOME/ucm/cs/bin directory with the following names:
    • Archiver.exe
    • BatchLoader.exe
    • ComponentTool.exe
    • ComponentWizard.exe
    • ConfigurationManager.exe
    • IdcAnalyze.exe
    • IdcCommand.exe
    • IdcServer.exe
    • IdcShell.exe
    • Installer.exe
    • IntradocApp.exe
    • RepositoryManager.exe
    • SystemProperties.exe
    • UserAdmin.exe
    • WebLayoutEditor.exe
    • WorkflowAdmin.exe
  4. Delete the DOMAINHOME/ucm/cs/bin/Launcher.exe file.
  5. Go to the DOMAINHOME/ucm/cs/admin/bin directory and delete these items:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  6. Copy the FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exe file to the DOMAINHOME/ucm/cs/admin/bin directory
  7. Copy the DOMAINHOME/ucm/cs/admin/bin/Launcher.exe to the DOMAINHOME/ucm/cs/admin/bin directory with the following names:
    • IdcAdmin.exe
    • IdcAdminNT.exe
  8. Delete the DOMAINHOME/ucm/cs/admin/bin/Launcher.exe file.
  9. Copy the FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exe file to the DOMAINHOME/ucm/cs/admin/bin directory.
  10. Repeat steps 1 through 4 for other WebCenter Content cluster nodes in the domain.
  11. Go to the DOMAINHOME/ucm/ibr/bin directory and delete these items:
    • ComponentWizard
    • IdcCommand
    • IdcRefineryInstaller
    • Launcher.sh
    • SystemProperties
    • UnixProcCtrl
  12. Copy the FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/Launcher.exe file to the DOMAINHOME/ucm/ibr/bin directory.
  13. Copy the DOMAINHOME/ucm/ibr/bin/Launcher.exe to the DOMAINHOME/ucm/ibr/bin directory with the following names:
    • ComponentWizard.exe
    • IdcRefinery.exe
    • IdcRefineryNT.exe
    • Installer.exe
    • SystemProperties.exe
  14. Delete the DOMAINHOME/ucm/ibr/bin/Launcher.exe file.
  15. Go to the DOMAINHOME/ucm/ibr/admin/bin directory and delete these items:
    • IdcAdmin
    • Launcher.sh
    • UnixProcCtrl
  16. Copy the FMWHOME/wccontent/ucm/idcnative/windows-amd64/bin/Launcher.exe file to the DOMAINHOME/ucm/ibr/admin/bin directory.
  17. Copy the DOMAINHOME/ucm/ibr/admin/bin/Launcher.exe to the DOMAINHOME/ucm/ibr/admin/bin directory with the following names:
    • IdcAdmin.exe
    • IdcAdminNT.exe
  18. Delete the DOMAINHOME/ucm/ibr/admin/bin/Launcher.exe file
  19. Copy the FMWHOME/wccontent/ucm/idc/native/windows-amd64/bin/NtProcCtrl.exe file to the DOMAINHOME/ucm/ibr/admin/bin directory.
  20. Repeat steps 11 through 19 for other refineries in the domain.

7.16 Adjust Outgoing Provider Settings for Inbound Refineries

  1. In the Domain Structure, go to Environment > Servers.
  2. On the Control tab, select the check boxes for UCM_server1 and UCM_server2.
  3. Click Start and then Yes to confirm.
  4. Above the Servers table, click the refresh arrows. Observe that the state of UCM_server1 and UCM_server2 changes to RUNNING.
  5. Log in to the WebCenter Content instance.
  6. On the Administration > Providers page, for the outgoing provider connecting to the refinery on apphost1, click Info.
  7. Click Edit and provide the new values for Server Host Name and HTTP Server Address.
  8. Click Update and for the outgoing provider connecting to the refinery on apphost2, click Info.
  9. Click Edit and provide the new values for Server Host Name and HTTP Server Address.
  10. Click Update.
  11. Restart the UCM_server1 and UCM_server2 managed servers.

7.17 Adjust Configuration Settings for WebCenter Content User Interface

To reconfigure WebCenter Content user interface:
  1. In the Domain Structure, go to Environment > Servers.
  2. On the Control tab, select the check boxes for WCCADF_server1 and WCCADF_server2.
  3. Click Start and then Yes to confirm.
  4. Above the Servers table, click the refresh arrows. Observe that the state of WCCADF_server1 and WCCADF_server2 changes to RUNNING.
  5. If your load balancer has changed, log into the Fusion Middleware Control and edit the PropConnectionUrl mBean value used for establishing the connection from the WebCenter Content user interface to the WebCenter Content so that this value uses the new address for your load balancer.
    1. From the target navigation in the upper left corner of the page, go to WebLogic Domain > <DOMAINNAME> - UI_cluster - WCCADF_server1 and then select the WCCADF_server1 managed server.
    2. From the WebLogic Server drop-down list, select WebLogic Server - System MBean Browser.
    3. Navigate to Application Defined MBeans > oracle.adf.share.connections > Server: WCCADF_server1 > Application: Oracle WebCenter Content - Web UI > ADFConnections > ADFConnections > WccConnection > WccAdfServerConnection.
    4. Update the value for PropConnectionUrl to contain the new load balancer listening on the socket port and click Apply.
    5. Go to Application Defined MBeans > oracle.adf.share.connections > Server: WCCADF_server1 > Application: Oracle WebCenter Content - Web UI > ADFConnections
    1. On the Operations tab, click Save and then click Invoke to display Operation executed successfully message.

7.18 Configure Oracle HTTP Server

  1. On the new apphost1, open a terminal.
  2. Go to the DOMAINHOME/config/fmwconfig/components/OHS/instances/ohs_1 directory.
  3. Open the mod_wl_ohs.conf file in a text editor.
  4. Replace existing values for apphost1 and apphost2 with the new values.
  5. Save the file and exit the text editor.
  6. Go to the DOMAINHOME/config/fmwconfig/components/OHS/ohs_1 directory.
  7. Open the mod_wl_ohs.conf file in a text editor.
  8. Replace existing values for apphost1 and apphost2 with the new values.
  9. Save the file and exit the text editor.
  10. Copy the DOMAINHOME/config/fmwconfig/components/OHS/instances/ohs_1/mod_wl_ohs.conf on the new apphost1 to the DOMAINHOME/config/fmwconfig/components/OHS/instances/ohs_2 on the new apphost2.
  11. Log in to Fusion Middleware Control.
  12. To display the Target Navigation menu, click the Target Navigation icon in the upper left corner.
  13. Expand the HTTP Server section and select ohs_1.
  14. Click Start Up and proceed to the next step after the Confirmation message appears.
  15. In the upper left corner, click the Target Navigation icon and in the Target Navigation menu, select ohs_2.
  16. Click Start Up and close the Confirmation message when it is displayed.

7.19 Configure Security Providers

Manually port the security provider data to the domain's new location. This is required because the Domain Template Builder is an offline utility, and therefore, does not export security provider data such as embedded LDAP data, into domain templates.

Related Topics

7.20 Update Database Information for Standalone Java Applications

If the database location has changed:
  1. From the DOMAINHOME/ucm/cs/bin directory of one of the cluster nodes, run the SystemProperties application.
  2. From within the SystemProperties application, update the database information on the Database tab so that the standalone Java applications in WebCenter Content's bin directory can be launched successfully.

7.21 Verify That Everything Works

If you have never run any of the standalone java applications before, you need to reset the local sysadmin user's password using the UserAdmin applet and also configure the jdbc connection using SystemProperties so the standalone java applications can interact with the database and function.
To check that migration has been successful:
  1. Run IdcAnalyze to confirm there are no errors. On the Configuration tab, ensure the following:

    • Database is selected

    • Database → RevClassIDs is selected

    • Database → Clean Database is deselected

    • Search index is selected

    • Search index → Clean Search Index is deselected

    • file system is selected

    • Generate Report is selected

    For information, see Using the Content Server Analyzer in Administering Oracle WebCenter Content.
    If errors are reported, fix them as necessary.
  2. Update other applications' configuration settings with the new host name for WebCenter Content.