1. Migrating Oracle WebCenter Content
  2. Migrate Clustered WebCenter Content 11g to New Hosts on an Identical or Dissimilar Infrastructure

3 Migrate Clustered WebCenter Content 11g to New Hosts on an Identical or Dissimilar Infrastructure

Topics that follow will guide you in moving clusters of WebCenter Content 11g to another infrastructure where Operating System and directory structure may or may not be the same as the existing infrastructure.

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

3.1 Preliminary Steps Before Migrating Clustered WebCenter Content Release 11g

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.

3.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.

3.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 domain template:
  1. Run the Template Builder on the host on which the admin server is running (in this example, apphost1).
    $ORACLE_HOME/wlserver_10.3/common/bin/config_builder.sh
  2. In the Template Builder Release 11g dialog box:
    1. On the Create a New Template page, select Create a Domain Template, and click Next.
    2. On the Select a Template Domain Source page, select the Domain and click Next.
    3. On the Describe the Template page, confirm or provide required values for Name, Version, and Author, and click Next.
    4. On the Specify Template Jar Name and Location page, confirm or provide the template JAR name and the template location, and then click Next.
    5. On the Add or Omit Applications page, click Next.
    6. On the Add Files page, click Next.
    7. On the Add SQL Scripts page, click Next.
    8. On the Configure the Administration Server page, confirm the values, and click Next.
    9. On the Configure Administrator User Name and Password page, confirm the values and click Next.
    10. On the Specify Start Menu Entries page, click Next.
    11. On the Prepare Scripts and Files with Replacement Variables page, click Next.
    12. On the Review WebLogic Domain Template page, click Create.
    13. On the Creating Template page, click Done.
  3. Copy the domain template that was just created to the new host on which the new admin server will reside.

3.4 Create a New Domain

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

To create a new domain:
  1. Run the Configuration Wizard on the new host using the template that was just created.
    FMW_HOME/Oracle_ECM1/common/bin/config.sh
  2. In the Configuration Wizard dialog box:
    1. On the Welcome page, select Create a New WebLogic Domain, and click Next.
    2. On the Select Domain Source page, select Base this domain on an existing template, select the template created earlier, and click Next.
    3. On the Specify Domain Name and Location page, provide or confirm the values for domain name, domain location, application location, and then click Next.
    4. On the Configure Administrator User Name and Password page, enter desired values for user name and password. Click Next.
    5. On the Configure Server Start Mode and JDK page, select the desired startup mode and JDK, and then click Next.
    6. On the Configure 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.

    7. On the Test JDBC Component Schema page, select the schema(s), then click Test Connections, and then Next.
    8. On the Select Optional Configuration page, select Administration Server, Managed Servers, Clusters, and Machines, and then click Next.
    9. On the Configure the Administration Server page, enter listen address and the listen port of new host and click Next.
    10. On the Configure Managed Servers page, enter the listen addresses and the listen ports of new host for all managed servers and click Next.
    11. On the Configure Clusters page, click Next.
    12. On the Assign Servers to Clusters page, confirm the assignments and click Next.
    13. On the Configure Machines page, enter the listen addresses of the new hosts for any defined machines and click Next.
    14. On the Assign Servers to Machines page, confirm the assignments and click Next.
    15. On the Configuration Summary page, click Create.
    16. On the Creating Domain page, click Done.

3.5 Copy WebCenter Content Directory to the New Host

Now that the domain is created, go ahead and copy the WebCenter Content directory to the new host. Several tools are available to help you accomplish this task. 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, apphost1) in the DOMAINHOME directory.
  2. Copy the DOMAINHOME/ucm directory from the source or old host (in this example, apphost1) to the target or new host (in this example, apphost1).
    rsync -avzh ucm/ oracle@target.domain.com:DOMAINHOME/ucm
In this example, the above command would be rsync -avzh ucm/ oracle@targetapphost1.domain.com:DOMAINHOME/ucm

3.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. If running in production mode, click Activate Changes in the Change Center.

3.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 Centent node:
  1. Open the DOMAINHOME/ucm/cs/bin/intradoc.cfg file on the new host 1 (in this example, apphost1) and update directory paths, if necessary.
    Update the following and then save the changes:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir
  2. Edit WebCenter Content'sconfig.cfg files to include the updated host name for SocketHostNameSecurityFilter or IP address for SocketHostAddressSecurityFilter.
  3. 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.
  4. Edit your load balancer's configuration with the new backend hosts' addresses for WebCenter Content.

3.8 Verify that WebCenter Content 1 (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.

3.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

3.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

3.11 Adjust Configuration Settings for the WebCenter Content Node

To adjust configurations settings for the WebCenter Content node:
  1. Open the DOMAINHOME/ucm/cs/bin/intradoc.cfg file on the new host 1 (in this example, apphost1).
  2. Update the following, if necessary, and then save the changes:
    • IdcHomeDir
    • FmwDomainConfigDir
    • AppServerJavaHome
    • TraceDirectory
    • EventDirectory
    • VaultTempDir
    • IntradocDir
    • VaultDir
    • WeblayoutDir
    • UserProfilesDir

3.12 Verify that UCM_server2 Starts on the New Host

  1. On the target cluster, on apphost1, start the admin server.
  2. On the target cluster, on apphost2, start the node manager.
  3. 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.

3.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/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/config/config.cfg file on the new host 2 (in this example, apphost2).
  6. Provide the updated host name and port as the value for HttpServerAddress.
  7. Provide host name for SocketHostNameSecurityFilter or IP address for SocketHostAddressSecurityFilter and save the changes.
  8. Open the DOMAINHOME/ucm/ibr/bin/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

3.14 Verify that Inbound Refineries Start Successfully on New Hosts

  1. In the Domain Structure, go to Environment > Servers.
  2. On the Control tab, select the check boxes for IBR_server1 and IBR_server2.
  3. Click Start and then Yes to confirm.
  4. Above the Servers table, click the refresh arrows. Observe that the state of IBR_server1 and IBR_server2 changes to RUNNING.
  5. Confirm that you can log in successfully to both refineries.

3.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.

3.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/Oracle_ECM1/ucm/idc/native/Launcher.sh 
    ln -s /FMWHOME/Oracle_ECM1/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/Oracle_ECM1/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 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/Oracle_ECM1/ucm/idc/native/Launcher.sh.
    ln -s FMWHOME/Oracle_ECM1/ucm/idc/native/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.
  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.

3.15.2 Linux to Linux

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

3.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/Oracle_ECM1/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/Oracle_ECM1/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/Oracle_ECM1/ucm/idc/native/windows-amd64/bin/NtProcCtrl.exe file to the DOMAINHOME/ucm/cs/admin/bin directory.
  10. Repeat steps 1 through 4 for other content server 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/Oracle_ECM1/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/Oracle_ECM1/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/Oracle_ECM1/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.

3.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.

3.17 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

3.18 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.

3.19 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

    If errors are reported, fix them as necessary.
  2. Update other applications' configuration settings with the new host name for WebCenter Content.