4 Migrate Non-Clustered WebCenter Content 12c to a New Host on an Identical Infrastructure

If you would like to move a non-clustered WebCenter Content Release 12c instance to an infrastructure where Operating System and directory structure of WebCenter Content will remain the same as those on the existing infrastructure, then the topics that follow will guide you in accomplishing your goal.

4.1 Things to Consider Before Migrating Non-Clustered WebCenter Content Release 12c

Things You Should Consider Before Migrating Your WebCenter Content Release 12c

  • The chghost utility does not move binary data or data stored in a database.
  • The chghost utility does not support environments where SSL only is configured or where either the administration port or only the SSL port is enabled.
  • The same version of the JDK must be installed on the same path on both the old (source) host and the new (target) host.
  • You cannot change the topology, that is, you can't add, remove, or modify managed server, the WebLogic Server domain name, port number, and so on.
  • The paths of both, the source and target instances must be the same. You cannot change them.
  • You can move Oracle Fusion Middleware to only the same type of Operating System.
  • In a multinode environment, you can move or change the network configuration of each node separately. For example, if the administration server is on Host A and the managed servers are on Host B, you can move or change the network configuration of the administration servers, the managed servers, or both.
  • The versions of Fusion Middleware Infrastructure (WebLogic Server) and WebCenter Content must match between the old host and the new host. You cannot upgrade to a newer version while you migrate to new hosts.
  • If you are moving the database from one host to another, the database type must remain the same. For example, you cannot change the database type from an Oracle Database to a SQL Server database.
  • For information on migrating Fusion Middleware applications such as BPM, Portal, installed on the same WebLogic domain that you're planning to move, see Moving Oracle Fusion Middleware to a New Host in Administering Oracle Fusion Middleware.

4.2 Migrate Non-Clustered WebCenter Content Release 12c to a New Host

This set of sample steps can help you move an instance of WebCenter Content release 12c domain to a new host without using Archiver and ConfigMigrationUtility.

Perform these steps to move WebCenter Content, Refinery, and WebCenter Content user interface to a new host in conjunction with the steps in Moving Oracle Fusion Middleware to a New Host in Administering Oracle Fusion Middleware.
Tasks to Perform Before Migration:
  • Stop all managed servers, the admin server, and the node manager
  • Back up WebCenter Content's file system
  • Back up WebCenter Content's database
  • If JTA Transaction Log Persistence is set to Default Persistent Store, back that up.
  • If JMS Server Persistence is set to JMS File Store, back that up.
  • Download and install a JDK with an appropriate version and platform on the new host.
  • Download installation media for Fusion Middleware Infrastructure and WebCenter Content on the new host.
  • Install Fusion Middleware Infrastructure and WebCenter Content to the same directories on the new host as they exist on the old host or use copyBinary.sh and pasteBinary.sh to clone them from the old system.
  • Install any patches that were installed on the old host to the ORACLE_HOME on the new host. Skip this step if you processed copyBinary.sh and pasteBinary.sh as they cloned the ORACLE_HOME to the new host.
  • If WebCenter Content’s vault and weblayout are on a remote or shared disk, ensure that the file share is mounted on the new host with the same path as on the old host. Also make sure that the appropriate permissions have been granted to the file share.

To migrate WebCenter Content, Inbound Refinery, and WebCenter Content user interface:

  1. Create an input file with the following code on the new host at a location such as /tmp/myinputfile.txt. You'll need this during migration.
    [ARGUMENTS]
    
    [SERVER_HOST_MAPPING]
    #pattern source_host_name=target_host_name
    source.domain.com=target.domain.com

    Note:

    Either side of "=" could be an IP address. The left side MUST match what is presently being used in the config.xml, config.cfg, and so on on the old host. If the IP address is used in these files but the host name is used in the input file or vice versa, the chghost.sh script will fail when it's run later on.
  2. Create a wallet directory and wallet on the new host:
    1. mkdir /tmp/mywalletdir
    2. ORACLE_HOME/oracle_common/common/bin/configWallet.sh -walletDir /tmp/mywalletdir weblogic
    3. Provide the password for the weblogic user when prompted
  3. Create the ORACLE_HOME/user_projects/domains directory on the new host.
  4. Create the ORACLE_HOME/user_projects/applications directory on the new host.
  5. If you have relocated the search directory or the archives directory, also create them on the new host in an appropriate location.
  6. Run rsync for the domain:
    rsync -avzh ORACLE_HOME/user_projects/domains/DOMAINNAME
          USER@target.domain.com:/ORACLE_HOME/user_projects/domains
  7. Run rsync for the application:
    rsync -avzh ORACLE_HOME/user_projects/applications/DOMAINNAME
          USER@target.domain.com:/ORACLE_HOME/user_projects/applications
  8. Run chghost.sh on the new host. This following sample command must be run as a single command. Here it is split into multiple lines for clarity.
    ORACLE_HOME/oracle_common/bin/chghost.sh
    -chgHostInputFile /tmp/myinputfile.txt
    -javaHome JDK_INSTALL_LOCATION
    -domainLoc ORACLE_HOME/user_projects/domains/DOMAINNAME
    -domainAdminUserName weblogic
    -walletDir /tmp/mywalletdir
    -logDir /tmp
  9. Recreate the boot.properties files in the DOMAINHOME/servers/SERVERNAME/security directories if desired for the admin server and any managed servers. They are not available at this location after chghost.sh is run.
  10. If a refinery was also moved, check the DOMAINHOME/ucm/cs/data/providers/PROVIDERNAME/provider.hda on the new host to ensure it was updated with the new host tname.
  11. Edit any providers which may be pointing to this WebCenter Content instance from other WebCenter Content instances for replication purposes.
  12. Install any third-party video conversion tools for video conversion with the refinery on the same paths that they were at on the old host.
  13. Start the admin server and the WCCADF_server1 managed server.
  14. In the Fusion Middleware Control, edit the PropConnectionUrl mBean value used for establishing the connection from the WebCenter Content user interface to the WebCenter Content instance so that it uses the new host name.
    1. Click the Target Navigation icon in the upper left corner of the page to display the Target Navigation menu, and then select the WCCADF_server1 managed server.
    2. Go to the 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 and click Apply.
    5. Go to Application Defined MBeans > oracle.adf.share.connections > Server: WCCADF_server1 > Application: Oracle WebCenter Content - Web UI > ADFConnections > ADFConnections.
    6. On the Operations tab, click Save and then click Invoke.
  15. Update the SocketHostAddressSecurityFilter configuration setting on WebCenter Content and Inbound Refinery to use the new IP address or update the SocketHostNameSecurityFilter configuration setting on both to use the new host name.
  16. Stop the WCCADF_server1 managed server and restart all managed servers.
  17. Update the new location on other applications that connect to WebCenter Content to ensure uninterrrupted operations.
  18. If you're using SSL, update your SSL certificates with the new host names by importing them into the keystores of the new JDKs.
  19. Run IdcAnalyze to verify that everything works.