20 Moving from a Test to a Production Environment

You can move Oracle Fusion Middleware from a source environment, such as a test environment, to a target environment, such as a production environment. You can develop and test applications in a source environment, and then eventually roll out the test applications and, optionally, test data to your target environment. You can also use this approach for testing and rolling out upgrades.

Note:

Moving your environment from a test to a production environment is deprecated in this release. It will not be supported in a future release.

Topics:

Note:

The procedures in this chapter are valid for Oracle Fusion Middleware 12c (12.2.1.1) and the components that are part of that release.
The procedures in this chapter for the most part assume that you are using the standard installation topology, which consists of a WebLogic Server domain that contains an Administration Server and a cluster containing two Managed Servers or a standalone domain.

For more information about the standard topology, see "Understanding the Oracle Fusion Middleware Infrastructure Standard Installation Topology" in Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.

20.1 Introduction to Moving Oracle Fusion Middleware Components

You can move Oracle Fusion Middleware components from a source environment to a target environment.

Moving Oracle Fusion Middleware components minimizes the amount of work that would otherwise be required to reapply all the customization and configuration changes made in one environment to another. You can install, configure, customize, and validate Oracle Fusion Middleware in a source environment. Once the system is stable and performs as desired, you can create the target environment by moving a copy of the components and their configurations from the source environment, instead of redoing all the changes that were incorporated into the source environment.

20.2 Planning for Moving Your Environment

Before you move your environment, you should understand the movement scripts, check the source environment, prepare the target environment, and understand the limitations and restrictions.

This section describes important information that you should know before you begin moving your environment. It includes the following topics:

20.2.1 Introduction to the Movement Scripts

Oracle Fusion Middleware provides a series of scripts that you can use to move your environment:

copyBinary: Copies the binary files of the source Oracle home.
pasteBinary: Applies the copied Oracle home to the target.
copyConfig: Used for any of the following:
- Copies the configuration of a WebLogic Server domain, including any Java components or system components in the domain.
- Copies the configuration of a standalone domain, including any system components in the domain.
- Copies the configuration of Node Manager.
extractMovePlan: Extracts a move plan as an .xml file (called moveplan.xml) and other files from the archive file created by the copyConfig operation.
pasteConfig: Used for any of the following:
- Applies the copied configuration of a WebLogic Server domain, including any Java components or system components in the domain.
- Applies the copied configuration of a standalone domain, including any system components in the domain.
- Applies the copied configuration of Node Manager.

The scripts enable you to copy an Oracle home and Oracle WebLogic Server domains, as well as the configuration of certain Oracle Fusion Middleware components, such as Oracle HTTP Server and Oracle SOA Suite.

Table 20-1 shows which Oracle Fusion Middleware components support the movement scripts.

Table 20-1 Support for Movement Scripts

Component	Supported?
Oracle Application Development Framework	Yes
Oracle B2B	Yes
Oracle B2B for Healthcare	Yes
Oracle Business Activity Monitoring	Yes
Oracle Business Intelligence	No
Oracle Business Process Management	Yes
Oracle Coherence	Yes
Oracle Data Integrator	Yes
Oracle Enterprise Data Quality	Yes
Oracle Enterprise Scheduler	Yes
Oracle Forms Services	Yes
Oracle HTTP Server	Yes
Oracle HTTP Server WebGate	Yes
Oracle Managed File Transfer	Yes
Oracle Reports	No
Oracle Platform Security Services	Yes
Oracle Real-Time Integration Business Insight	No. However, domains that contain Insight can be moved using the scripts. You can move the Insight configuration, particularly Models, Connections and Consoles by exporting them from the source and importing them into the target after you run the scripts.
Oracle Service Bus	Yes
Oracle SOA Suite	Yes
Oracle Traffic Director	Yes
Oracle User Messaging Service	Yes
Oracle Web Services Manager	Yes
Oracle WebCenter Capture	Yes
Oracle WebCenter Content	Yes
Oracle WebCenter Portal	Yes
Oracle WebCenter Sites	Yes
Oracle WebLogic Server	Yes

Many of the components have specific move plan properties, as described in Table A-11.

20.2.2 Checking the Source Environment

The procedures in this chapter assume that you have installed and configured Oracle Fusion Middleware on the source environment, including some or all of the following:

Installed one or more databases to be used by Oracle Fusion Middleware components, such as Oracle SOA Suite.
Created the needed schemas in the source environment using RCU. See Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility.
Installed and configured Oracle Fusion Middleware products. For example, you have installed Oracle WebLogic Server and Oracle Web Services Manager, created the Oracle home, and configured an Oracle WebLogic Server domain.

When you configure the domain, you can choose one of two modes:
- Development mode: In this mode, the security configuration is relatively relaxed. User name and password are required to deploy applications.
- Production mode: In this mode, the security configuration is relatively stringent, requiring a user name and password to deploy applications and to start the Administration Server.
Alternatively, you have installed and configured system components, such as Oracle HTTP Server, in a standalone domain.
Configured security policies.
For Oracle Platform Security Services, created security policies and stored credentials in the Credential Store Framework (CSF).
Deployed one or more applications or SOA Composite applications. The applications may have internal and external references.

Also, note the following about the source environment:

Before you execute the copyConfig script in a WebLogic Server domain, make sure that the Administration Server and Managed Servers are running.
On Windows, before you execute the copyConfig script in a WebLogic Server domain, you must shut down Node Manager if the environment is a WebLogic Server domain with system components. The Administration server and Managed Servers must be running, but the system components should not be running

On operating systems other than Windows, for WebLogic Server domains and standalone domains, when you execute the copyConfig command on the source environment, any system components can be started or shut down. In either case, the copyConfig operation will complete.
For Oracle Web Services Manager, before you execute the copyConfig script, the server on which the Oracle Web Services Manager Policy Manager application is deployed must be running.

20.2.3 How the Movement Scripts Work with Keystores

Oracle Fusion Middleware supports two types of keystores:

JKS: Java Keystore
KSS: Oracle Platform Security Services Keystore Service. The Keystore Service is available only if you created a domain that includes Oracle JRF.

Keystore-related properties are populated for all servers in the move plan in the following circumstances:

If SSL is enabled (either the Administration Server port or the SSL port of the Administration Server) in the source domain, irrespective of which keystores configured.
If only non-SSL ports are enabled in the source domain and the keystores of the Administration Server are one of the following types:
- CustomIdentityandCustomTrust
- CustomIdentityandJavaStandardTrust
- CustomIdentityandCommandLineTrust
If only non-SSL ports are enabled and DemoIdentityAndDemoTrust keystores are configured in the source domain, the keystore-related properties are not populated in the move plan.

Irrespective of how the source environment is configured, note the following about how the move plan properties must be configured before you move the configuration to the target using the pasteConfig script:

For domains configured with Oracle JRF:
- All servers must have the same keystores.
- The keystore type (JKS or KSS) must be the same across all servers.
- You can modify the move plan to change the keystore type from JKS to KSS or KSS to JKS.
For domains not configured with Oracle JRF:
- All servers must have the same keystores.
- You can only use JKS keystores.
You can change keystores from source to target both for domains configured with Oracle JRF and those configured without Oracle JRF. Except when the source is only non-SSL and DemoIdentityAndDemoTrust, you can change the value of the keystore to one of following, whatever the value of keystores are at source:
- DemoIdentityAndDemoTrust
- CustomIdentityAndCustomTrust
- CustomIdentityAndJavaStandardTrust
- CustomIdentityAndCommandLineTrust

20.2.4 Preparing the Target Environment

To use the procedures in this chapter, your target environment must meet the following prerequisites:

You must use the cloningclient.jar file and movement scripts, such as pasteBinary, that are compatible with the version of the Oracle home and components that you want to copy. The procedures in this chapter presume that you are using the current version of the cloningclient.jar file and movement scripts.
The target environment must be on the same operating system as the source environment. Also, the operating system architecture must be the same in both environments. For example, both environments must be running 32-bit operating systems or 64-bit operating systems.
When you execute the scripts, you must specify a matching Java home. That is, if the Oracle homes are 64 bit, you must specify a 64-bit Java home. If the Oracle homes are 32 bit, you must specify a 32-bit Java home.
The host must have JDK 1.8.0_x or higher installed.
The target environment must have the same superuser or administrative user as the user at the source environment. After you complete the movement of the installation, you can modify the user on the target environment.
The database in the target environment must be the same type of database as in the source environment. For example, if the database in the source environment is an Oracle Database, the database in the target environment must be an Oracle Database. The database on the target environment should be the same version as on the source environment.
If the source environment uses a consolidated schema and consolidated data sources, the target environment must use a similar consolidated schema, with the exact same constituent schemas.
If the database is not tuned correctly, the copyConfig and pasteConfig operations can incur performance issues. To avoid these performance issues, in addition to following standard database performance tuning guidelines, ensure that you have sufficient RAM allocated for your database for the import of the MDS tables. Also run statistics against the target database by executing the following procedure:
```
BEGIN
dbms_stats.gather_schema_stats(ownname => 'prefix_MDS', 
           METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
           CASCADE => TRUE, ESTIMATE_PERCENT => NULL);
END;
```
In the procedure, prefix_MDS is the MDS schema name for your installation.
If the source environment is an SSL-only environment, make sure that you configure the keystores and credentials in the source environment before you execute the movement scripts.
If you are applying the archive of an Oracle home on a host that does not yet have Oracle Fusion Middleware installed, note the following:
- Copy the pasteBinary script from the following location in the source host to the target host:
```
(UNIX) ORACLE_HOME/oracle_common/bin/pasteBinary.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteBinary.cmd
```
  Note that on Windows, you do not copy pasteBinary.sh.
- Copy the following file in the source host to the target host:
```
(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar
(Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar
```
- If you run the pasteBinary script from a different location than ORACLE_HOME/oracle_common/bin, then the pasteBinary script and the cloningclient.jar file must be in the same directory.
  
  If you are running pasteBinary on a host that has no prior Oracle Fusion Middleware installations, ORACLE_HOME/oracle_common/bin will not exist prior to running pasteBinary, and therefore the pasteBinary script and cloningclient.jar must be in the same directory.
- Ensure that the files have execute permission.
The ports that you specify in the move plans must be available on the target machine.The pasteConfig script checks that the specified ports are available.
On Windows, the file MSVCR90.DLL must exist on the target host. Otherwise, pasteConfig will fail.

This file (or various versions of it) are located in the directory tree underneath:
```
(Windows 32 bit) C:\Windows\System32 
(Windows 64 bit) C:\Windows\winsxs
```
On Windows, to successfully move Oracle Traffic Director and Oracle HTTP Server, MS Visual C++ version 12.0 must be installed.

20.2.5 Limitations in Moving from Source to Target

Note the following limitations and restrictions:

The source and the target environment must use the same encoding. For example, if the source environment uses the encoding ja_JP.utf8 locale and the target environment uses the encoding ja_JP locale, some file names may not be handled correctly in the target.
The movement scripts do not support domains that use multi-tenancy.
The movement scripts do not support WebSphere-based environments.
When you move the configuration of a component, the scripts replicate the topology of the source. For example, if the source domain contains Managed Servers server_1 and server_2 on Host A and Managed Servers server_3 and server_4 on Host B, you must specify a similar relationship between Managed Servers and hosts at the target. (You specify the hosts for each Managed Server in the move plan.)
If a custom application uses an internal data source (for example, the application was created and deployed with an internal data source using JDeveloper), the internal data source is not migrated during the pasteConfig operation.

To work around this, create an external data source in the domain, modify the application to use that data source, and deploy the application again.
If the source Oracle home uses a JDK that is external to the Oracle home, the pasteBinary operation must also use an external JDK.
The JDK used in the source and target must be the same type.
- The JDK used in the source and target must be the same type. For example, if the source uses Java SE, the target must use Java SE.
- The vendor used in the source and target must be the same. For example, if the source uses an Oracle JDK, the target must use a JDK from Oracle.
- The major version of the JDK used in the source and target must be the same. For example, if the source uses version 1.8, the target must use 1.8.
You cannot use the same shared security store for more than one domain.
If there is not enough space in the temporary directory when you are moving an entity, an error is returned, noting the space needed. To work around this problem, specify a different location for the temporary directory by using the T2P_JAVA_OPTIONS environment variable as described in Movement Scripts Syntax.
If you have moved your environment and executed the pasteBinary script using a custom inventory location (using the invPtrLoc parameter), you must invoke runInstaller with the following argument:
```
-invPtrLoc custom_inventory_pointer_location
```
When you are moving Oracle Platform Security Services and the data is moving from LDAP to LDAP, the source and target LDAP domain component hierarchy must be same. If it is not, the Oracle Platform Security Services data movement will fail. For example, if the source is hierarchy is configured as dc=us,dc=com, the target LDAP must have the same domain component hierarchy.
The movement scripts do not support dynamic cluster configuration.

To work around this, disable dynamic cluster configuration before you execute the copyConfig script. Then, after you execute the pasteConfig script, you can enable it.

If Oracle Service Bus is configured in the domain, during the pasteConfig operation, when the Administration Server is started for the first time, you may see the following error:

Failed to initialize the application "Service Bus Framework Starter
 Application" due to error java.lang.RuntimeException: OSB system user
authentication failed java.lang.RuntimeException: OSB system user authentication failed

You can ignore this error.

20.2.6 Overview of Procedures for Moving from a Source to a Target Environment

This section describes the general steps in moving installations from a source environment to a target environment. Figure 20-1 shows a flowchart illustrating the steps.

Figure 20-1 Flowchart for Moving Your Environment

Description of "Figure 20-1 Flowchart for Moving Your Environment"

The general steps are:

Check your source environment. See Checking the Source Environment.
Prepare your target environment. See Preparing the Target Environment.
If your environment uses a database, create a new database. See Installing the Database on the Target Environment.
Move a copy of the binary files in the Oracle home from the source environment to the target environment
- Using the copyBinary and pasteBinary scripts, as described in Moving the Oracle Home and the Binary Files Using the Scripts.
- Using storage-level cloning tools, if supported by your environment, to create a copy of an existing disk volume and move it to a different location. Then, you use the pasteBinary script to transform the target Oracle home to a proper Oracle home, creating or updating the necessary inventory information, file permissions, and string substitutions for the correct ORACLE_HOME path. See Moving the Oracle Home and Binary Files Using Storage-Level Cloning Tools.
  
  You can use this method if your environment is located on one disk volume.
Move a copy of the configuration of the domain and components. In most cases, you use the copyConfig, extractMovePlan, and pasteConfig scripts. The procedure you follow differs depending on your topology:
- To move the configuration of a WebLogic Server domain containing only Java components, or Java components and system components, see Moving the Configuration of a WebLogic Server Domain.
- To move the configuration of a standalone domain containing system components, see Moving the Configuration of a Standalone Domain.
In certain situations, as described in Moving the Configuration of Node Manager, you must separately move a copy of the configuration of Node Manager if it is configured in the source environment.
Take any additional steps that are required for some components. See Additional Steps or Information for Certain Components for information specific to each component.

Move other data, such as UMS user messaging preferences or data for the Oracle WebCenter Portal application. Modify any information that is specific to the new environment such as host name or ports. See Additional Steps or Information for Certain Components for information specific to each component.
Start the servers and components. See Starting Managed Servers and Components.

20.3 Common Procedures for Moving to a Target Environment

Many of the Oracle Fusion Middleware components use some of the same procedures to move from a source environment to a target environment. Note, however that not all components use all or some these procedures.

In addition, some components may require additional steps. You must check Table 20-2 to see if there are additional steps you need to take when moving a particular component.

This section describes the common procedures and contains the following topics:

The procedures in this section assume that you are using the standard installation topology. This topology consists of a WebLogic Server domain that contains an Administration Server and a cluster of two Managed Servers on one host or a standalone domain containing system components

If you have distributed your topology across multiple machines, see Moving Distributed Topologies.

Note:

In the scripts used in these procedures and in the move plans, you often need to provide files containing passwords. To generate a file that contains an obfuscated password, use the obfuscatePassword script, which is described in obfuscatePassword Script and API.

20.3.1 Installing the Database on the Target Environment

Some components, such as Oracle Application Development Framework and Oracle SOA Suite, may use a database to store metadata.

Note that the database in the target environment must be the same type of database as in the source environment. For example, if the database in the source environment is an Oracle Database, the database in the target environment must be an Oracle Database. The database on the target environment should be the same version as on the source environment.

You can install a new database or you can copy the database from the source environment:

Install a new database. You can use this for most components, except Identity Management components. Take the following steps:
1. Install and configure the database software.
2. Create the required schemas in the target database using RCU. See the Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility.
3. Create any custom schemas used by your applications. For example, if your application uses a custom schema in the source environment, create the schema in the target environment.

Create a duplicate database using the Oracle Database RMAN duplicate command. Use this method if you are moving Identity Management components. The duplicate database must be created with a different DBID than the source database, so that it functions entirely independently.

Note:

The RMAN utility refers to the source database (that is the original database) as the target database. It refers to the database that is created with the DUPLICATE command as the auxiliary database.

In the following steps, the source database name is referred to as test_DB_name; the target (auxiliary) database name is referred to as prod_DB_name.

To create a duplicate Oracle Database in the target environment:

On the target environment, install the Oracle Database software, but do not create a database. To do this, select Install Database Software only in the Select Configuration Option screen.

Note that the Oracle Database RMAN documentation refers to this as the auxiliary host.
On the target environment, create a password file. The path of the file should be:
```
ORACLE_HOME/dbs/orapwSID
```
The sys password must be the same as the password for the sys account in the database in the source environment. Use the following commands:
```
setenv ORACLE_HOME /scratch/dbhome/
setenv ORACLE_SID SID
$ORACLE_HOME/bin/orapwd password= password file=$ORACLE_HOME/dbs/orapwSID
```

On the target environment, create the startup pfile in the following location:

$ORACLE_HOME/dbs/initSID.ora

Note that the file name for initSID.ora is crucial and is case-sensitive.

Enter the following into the file:

DB_NAME=prod_DB_name
db_recovery_file_dest='/full_path_to_DBHOME/dest_file_recovery_db'
DB_RECOVERY_FILE_DEST_SIZE=2048m
*.remote_login_passwordfile='EXCLUSIVE'
*.local_listener='LISTENER_prod_DB_name'
audit_trail='NONE'
audit_file_dest='/full_path_to_DBHOME/audtrl'

The directories for the db_recovery_file_dest and audit_file_dest must exist. Create them if they do not exist.

On the target environment, create the following file, which you will execute in a subsequent step:

ORACLE_HOME/dbs/dup.cmd

Enter the following information in the file. In the example, the source database has the database name test_DB_name. The duplicate database has the database name prod_DB_name:

run {
allocate channel c1 device type disk;
allocate auxiliary channel c2 device type disk ;
DUPLICATE TARGET DATABASE to prod_DB_name
FROM ACTIVE DATABASE
NOFILENAMECHECK
SPFILE
SET DB_name='prod_DB_name'
SET DB_UNIQUE_NAME='prod_DB_name'
SET LOG_FILE_NAME_CONVERT 'test_DB_name','prod_DB_name'
SET DB_FILE_NAME_CONVERT 'test_DB_name','prod_DB_name'
SET audit_file_dest='/full_path_to_DBHOME/audtrl'
SET CONTROL_FILES='/full_path_to_DBHOME/dup.ctl'
set db_recovery_file_dest_size '1G'
set db_recovery_file_dest='/full_path_to_DBHOME/dest_file_recovery_db'
SET diagnostic_dest='/full_path_to_DBHOME';
}

On the target, create the following directory for the data files:
```
/full_path_to_DBHOME/oradata/prod_DB_name
```

On the target environment, create the following file:

ORACLE_HOME/network/admin/listener.ora

Add the following to the file

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))
    )
  )
 
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = prod_DB_name)
      (ORACLE_HOME = /full_path_to_prod_DBHOME)
      (GLOBAL_DBNAME = prod_DB_name)
    )
    (SID_DESC =
      (SID_NAME = test_DB_name
    )
  )

On the target environment, create the following file:

ORACLE_HOME/network/admin/tnsnames.ora

Add the following to the file:

  test_DB_name =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = test_DB_name.host.domain)
    )
  )
 
LISTENER_test_DB_name =
  (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))
 
 
prod_DB_name =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = prod_DB_name)
      (SERVICE_NAME = prod_DB_name)
    )
  )
 
LISTENER_prod_DB_name =
  (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num)

On the source environment, edit the tnsnames.ora file, adding an entry for the database on the target environment.

prod_DB_name =
    (DESCRIPTION =
      (ADDRESS =
        (PROTOCOL = TCP)
        (HOST = host_name)
        (PORT = port_num))
       (CONNECT_DATA =
        (SERVER = DEDICATED)
        (SID = prod_DB_name)
        (SERVICE_NAME = prod_DB_name)
      )
  )
   LISTENER_prod_DB_name =
  (ADDRESS = (PROTOCOL = TCP)(HOST = host_name)(PORT = port_num))

On the source environment, edit the listener.ora file, adding an entry for the database on the target environment.

The following shows the added entry:

LISTENER_prod_DB_name =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)
      (HOST = 192.168.2.4)
      (PORT = 1521)(IP = FIRST))
    )
  )
SID_LIST_LISTENER_prod_DB_name =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = prod_DB_name)
      (ORACLE_HOME = full_path_to_ORACLE_HOME)
    )
  )

On the source, start the listener:

setenv ORACLE_HOME full_path_to_ORACLE_HOME
setenv ORACLE_SID test_DB_SID
 
$ORACLE_HOME/bin/lsnrctl start

On the source, start the database. Use the following SQLPlus command:

$ORACLE_HOME/bin/sqlplus " /as sysdba"
SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'

Validate that the source database has Archive Log mode enabled.

SQL> archive log list
 
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST

If Archive Log mode is not enabled, execute the following commands:

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
SQL> alter system archive log current;

On the target, start the database in NOMOUNT mode. For example:
```
SQL> STARTUP NOMOUNT PFILE='ORACLE_HOME/dbs/pfile'
```
On the target, change to the directory that contains the file created in Step 4. For example:
```
cd ORACLE_HOME/dbs
```

On the target, use RMAN to connect to the source and duplicate databases:

ORACLE_HOME/bin/rman TARGET sys/password@test_DB_name 
                        AUXILIARY sys/password@prod_DB_name

On the target, run the file created in Step 4.
```
RMAN> @dup.cmd
```
RMAN automatically copies the server parameter file to the destination host, starts the auxiliary instance with the server parameter file, copies all necessary database files and archived redo logs over the network to the destination host, and recovers the database. Finally, RMAN opens the database with the RESETLOGS option to create the online redo logs.

For detailed steps, see the Oracle Database Backup and Recovery User's Guide.

20.3.2 Moving the Oracle Home and the Binary Files Using the Scripts

You can move a copy of the Oracle home to the target environment using the copyBinary and pasteBinary scripts:

The copyBinary script prepares the source and creates an archive. It also records the file permissions of the Oracle home.

The archive contains the Oracle home, including the product homes, such as Oracle WebLogic Server home and the Oracle HTTP Server home.
The pasteBinary script checks to see that the prerequisites are met at the destination. It extracts the files from the archive file, registers the Oracle home with the Oracle inventory.

The script then restores the file permissions and relinks any files if necessary.

Note the following:

The copyBinary and pasteBinary scripts do not carry over all the dependencies of the source Oracle home and the product homes, such as the WebLogic Server home, such as loadable modules or application-specific libraries to the target home, because the scripts proceed by copying the Oracle home and the entire source product homes to the destination Oracle home. Any files outside the source WebLogic Server or Oracle home are not automatically copied. Hence, any applications that refer to files outside the source WebLogic Server or Oracle home may not work properly in the target home.
When you copy an Oracle home, only the read-only portions of the Oracle home are copied. Any user configuration files, such as the user_projects directory, are excluded from the archive. The WebLogic Server domain is not copied. (Use the copyConfig and pasteConfig scripts to copy the domain.)
You cannot move an Oracle Home if its path is a symbolic link.

See

Table A-1 for the location of the scripts used in this section.

To move the Oracle home:

At the source, execute the copyBinary script, which copies the Oracle home and the product homes, such as the WebLogic Server home, contained within the Oracle home.
See copyBinary Script for the syntax of the copyBinary script.

For example, to copy an Oracle home that is located at /scratch/oracle/Oracle_home1, use the following command:
```
copyBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
              -archiveLoc /tmp/oh_copy.jar
              -sourceOracleHomeLoc /scratch/oracle/Oracle_home1
```
If you are copying the Oracle home to a different host, copy the archive file to that system, or if you are using storage-level cloning, copy the snapshot copy of the volume to the target system and mount the volume.
Copy the pasteBinary script and the cloningclient.jar file to the target system and ensure that they have execute permission.
The cloningclient.jar file is located in:
```
(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar
(Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar
```
Do not copy the other scripts, such as pasteConfig. Those scripts are generated when you extract the files, as in step 5.
On Linux and UNIX, if the target system does not contain any installed Oracle products, you must create an oraInst.loc file, specifying a group whose members are given access to write to the Oracle inventory (oraInventory), and where you want to put Oracle inventory. For example, the oraInst.loc file could contain the following:
```
inst_group=dba
inventory_loc=/scratch/oracle1/oraInventory
```
Then, if the location is not the default location, use the -invPtrLoc option to the pasteBinary script to specify the location of the oraInst.loc file. (For linux and AIX, the default location is/etc/oraInst.loc; for other UNIX platforms, it is /var/opt/oracle/oraInst.loc.)
At the target, extract the files from the archive using the pasteBinary script. See pasteBinary Script for the syntax of the pasteBinary script.
Note:

If the parent directory for the Oracle home does not exist, the pasteBinary script will create it.

The actual directory for the Oracle home (for example, Oracle_Home_prod) either must not exist or is an existing empty directory.

For example, to apply the archive to the directory /scratch/oracle/ORACLE_HOME_prod, use the following command:
```
pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
               -archiveLoc  /tmp/oh_copy.jar 
               -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod 
               -targetOracleHomeName ORACLE_HOME_prod
               -invPtrLoc /scratch/oracle/oraInventory
```
The Oracle home is extracted to /scratch/oracle/ORACLE_HOME_prod and the product homes are extracted under it with the same names as that of the source product home names.
The copyBinary and pasteBinary scripts do not copy the user_projects directory. They do copy and paste other domain directories that are in the Oracle home. However, these domain directories are not functional. (Oracle recommends that you do not create domain directories under the Oracle home.)

Delete the domain directories from the target before you run the pasteConfig command The pasteConfig script will recreate the domain directories on the target environment, as described in Moving the Configuration of a WebLogic Server Domain.
At the target, if the Node Manager is per host and is located under the Oracle home, delete the Node Manager directory and the files in it.

In this situation, you will move the Node Manager configuration in Moving the Configuration of Node Manager.

20.3.3 Moving the Oracle Home and Binary Files Using Storage-Level Cloning Tools

As an alternative to the copyBinary script, you can use storage-level cloning tools, such as Oracle Solaris ZFS or NetApp Flex Cloning, to create a copy of an existing disk volume and move it to a different location.

You can use this method if your environment is located on one disk volume.

To move the Oracle home and binary files using storage-level cloning tools:

Use the cloning tool to replicate the disk volume to the target environment.

Refer to the documentation for your disk volume for more specific information.
At the target, use the pasteBinary script using the -ohAlreadyCloned option. With this option, the pasteBinary script creates or updates the necessary inventory information, file permissions, and string substitutions for the correct ORACLE_HOME path.
See pasteBinary Script for the syntax of the pasteBinary script.

For example, to apply the archive to the directory /scratch/oracle/ORACLE_HOME_prod, use the following command:
```
pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
               -ohAlreadyCloned  true 
               -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod 
               -targetOracleHomeName ORACLE_HOME_prod
```
At the target, if the Node Manager is "per host" and is located under the Oracle home, delete the Node Manager directory and the files in it.

In this situation, you will move the Node Manager configuration in Moving the Configuration of Node Manager.
Because the storage-level cloning tools copy the entire user directory, it copies not just the binary files, but also the domain directories if they have been configured in the source environment. However, these domain directories are not properly configured, so that they are not functional.

Delete the domain directories from the target before you run the pasteConfig command, which will recreate properly configured domain directories on the target environment, as described in Moving the Configuration of a WebLogic Server Domain.

20.3.4 Moving the Configuration of a WebLogic Server Domain

You can move a copy of the WebLogic Server domain configuration using the copyConfig, extractMovePlan, and pasteConfig scripts. This step moves a copy of the configuration, including the domain, the Administration Server and Managed Servers and any components in the domain.

When you move the configuration of a component, the scripts replicate the topology of the source. For example, if the source domain contains Managed Servers server_1 and server_2 on Host A and Managed Servers server_3 and server_4 on Host B, you must specify a similar relationship between Managed Servers and hosts at the target. (You specify the hosts for each Managed Server in the move plan.)

The domain directory is local to each machine. The pasteConfig script is performed only on the Administration Server domain directory. Subsequently, if the Managed Servers are not in the same directory as the Administration Server, you must re-create the domain directory for those Managed Servers by using the Oracle WebLogic Server pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.

Because, in most cases, the user-specific data is not the same in the target environment as in the source environment, this process does not move user-specific data.

See

Table A-1 for the location of the scripts used in this section.

Note:

If you are using an IBM JDK, set the maximum permanent generation space (-XX:MaxPermSize=value) using the T2P_JAVA_OPTIONS parameter of the copyConfig and pasteConfig scripts.

To move a copy of the domain configuration:

At the source, make sure that the Administration Server and all Managed Servers are started.
For an Oracle SOA Suite that has an SSL-only environment, enable SSL, as described in Configuring SSL in the Oracle Fusion Middleware Administering Oracle SOA Suite and Oracle Business Process Management Suite.
On Windows, before you execute the copyConfig script in a WebLogic Server domain, you must shut down Node Manager if the environment is a WebLogic Server domain with system components.
At the source, make sure that the domain configuration is not set to automatically acquire locks. If you configured the domain in development mode, automatically acquiring locks is enabled. If you configured the domain in production mode, it is disabled by default. Take the following steps:
1. In the Administration Console, click Preferences.
2. In the User Preferences tab, clear Automatically Acquire Lock and Activate Changes.
3. Click Save.
4. In the Change Center, click Release Configuration, if applicable.
At the source, run the following script to generate an obfuscated password file for the domainAdminPasswordFile parameter.
```
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  
        -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd  
         -javaHome path_to_java_home
```
The script prompts you to enter the password and the path, including the file name, where the password file is to be written.
At the source, copy the domain configuration by executing the copyConfig script.

The copyConfig script is located in:
```
(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd
```
See copyConfig Script for Oracle WebLogic Server Domains for the syntax of the copyConfig script.

For example, to copy the configuration of the domain named WLS_domain1 in the Oracle home /scratch/oracle/Oracle_home1, use the following command:
```
copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
              -archiveLoc /tmp/wls.jar
              -sourceDomainLoc /scratch/oracle/domains/WLS_domain1
              -sourceOracleHomeLoc /scratch/oracle/Oracle_home1
              -domainHostName example.com
              -domainPortNum 8001
              -domainAdminUserName domain_admin_username
              -domainAdminPasswordFile /scratch/admin/passwd.txt
              -logDirLoc /tmp/logs
```
For Oracle Service Bus, when you use the copyConfig script, you must pass it the -additionalParams option, with the key osb.configuration.passphrase.file and the key value specifying the absolute path to the file containing the passphrase. For example:
```
-additionalParams osb.configuration.passphrase.file=/scratch/passwd/osb_passwd
```
If you do not specify this option, the exported configuration will not be password protected.
If you are copying the domain configuration to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script.

See extractMovePlan Script for the syntax of the extractMovePlan script.

For example:
```
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
                 -archiveLoc /tmp/wls.jar
                 -planDirLoc /tmp/Oracle/t2p_plans/wls
```
Note:

You must extract a new move plan each time you use the copyConfig script even if no changes have been made to the source environment. The pasteConfig scripts checks that the move plan and archive match. If they do not, the script returns an error.
Edit the move plan, modifying the properties to reflect the values for the target environment. Edit all properties, such as host names, port numbers, listen addresses, that have different values in the target environment. See Table A-11 to find the list of properties for the type of component you are moving.

For the Oracle WebCenter Content server or Oracle WebCenter Content: Records, you specify one of the following options in the move plan:
- copy: This option copies the entire source system, including configuration and data, to the target system. Although this is the default, Oracle does not recommend using this option because it moves test data, which might not be appropriate for your environment.
- init: This option initializes a new Content Server or Records instance in the target system. It does not move data.
You specify the copy or init option in the move plan, in the MoveType configProperty, as described in Table A-26. Then, you modify the properties listed in that configGroup.

See Additional Information and Procedures for Moving Oracle WebCenter Content for information about these options.
If the extractMovePlan script generated deployment plans, update the Oracle home and domain home location in the deployment plan file, which is located at:
```
planDirLoc/deployment_plans
```
Copy the edited move plan, along with any folders created by the extractMovePlan script, to the target. (These folders are located in the location specified by the planDirLoc parameter.)

During the pasteConfig operation, you specify the location using the -movePlanLoc option.
At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.
```
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
```
The script prompts you to enter the password and the path, including the file name, where the password file is to be written.

At the target, extract the files from the archive using the pasteConfig script

See pasteConfig Script for Oracle WebLogic Server Domains for the syntax of the script.

For example, to apply the archive to the Oracle home /scratch/oracle/Oracle_home1, use the following command:

pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
            -archiveLoc /tmp/wls.jar
            -movePlanLoc /tmp/Oracle/t2p_plans/wls/moveplan.xml
            -targetDomainLoc /scratch/oracle/config/domains/WLS_domain1
            -targetOracleHomeLoc /scratch/oracle/Oracle_home1/
            -domainAdminPasswordFile /scratch/pwd_dir/passwd.txt

If Managed Servers are not located on the same host as the Administration Server, you must re-create the domain directory for those Managed Servers by using the Oracle WebLogic Server pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.
Configure users and groups, as described in Configuring Users and Groups.

When you complete this task, you may need to perform additional steps for some components, as described in Additional Steps or Information for Certain Components.

20.3.5 Moving the Configuration of a Standalone Domain

You can move the configuration of standalone domain containing system components. For example, you may have installed Oracle HTTP Server in a standalone domain.

See

Table A-1 for the location of the scripts used in this section.

To move the configuration of a standalone domain containing system components:

At the source, copy the configuration by executing the copyConfig script.
See copyConfig Script for Standalone Domains for the syntax of the copyConfig script.

For example, to copy the configuration of the domain named OHS_domain1 in the Oracle home /scratch/oracle/Oracle_home1, use the following command:
```
copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
               -archiveLoc /tmp/stdalone_dom.jar
               -sourceDomainLoc /scratch/oracle/domains/OHS_domain1 
               -sourceOracleHomeLoc /scratch/oracle/Oracle_home1/
```
Note that you do not need to shut down Node Manager before executing this script.
If you are copying the configuration to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive created by the copyConfig script, using the extractMovePlan script.
See extractMovePlan Script for the syntax of the extractMovePlan script.

For example:
```
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
                 -archiveLoc /tmp/stdalone_dom.jar
                 -planDirLoc /tmp/Oracle/t2p_plans/
```
Note:

You must extract a new move plan each time you use the copyConfig script even if no changes have been made to the source environment. The pasteConfig scripts checks that the move plan and archive match. If they do not, the script returns an error.
Edit the move plan, modifying the properties to reflect the values for the target environment. See Table A-11 to find the list of properties for the type of component you are moving.
If the extractMovePlan script generated deployment plans, update the Oracle home and domain home location in the deployment plan file, which is located at:
```
planDirLoc/deployment_plans
```
Copy the edited move plan, along with any folders created by the extractMovePlan script, to the target. (These folders are located in the location specified by the planDirLoc parameter.)

During the pasteConfig operation, you specify the location using the -movePlanLoc option.
At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.
```
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
```
The script prompts you to enter the password and the path, including the file name, where the password file is to be written.

At the target, extract the files from the archive using the pasteConfig script

See pasteConfig Script for Oracle WebLogic Server Domains for the syntax of the script.

For example, to apply the archive to the Oracle home /scratch/oracle/Oracle_home1, use the following command:

pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
            -archiveLoc /tmp/stdalone_dom.jar
            -targetDomainLoc /scratch/oracle/config/domains/dom_cl
            -targetOracleHomeLoc /scratch/oracle/Oracle_home1 
            -movePlanLoc /tmp/Oracle/t2p_plans/move_plan.xml
            -logDirLoc /tmp/log

20.3.6 Moving the Configuration of Node Manager

If Node Manager is configured in the source environment, you must separately move Node Manager in the following circumstances:

The Node Manager is "per host."
In an environment on multiple hosts, the Node Manager is "per domain" and its configuration is within the domain directory, but each host has customized Node Manager properties that are applicable to only that host.

If the Node Manager is "per domain," the scripts for moving the domain also move the Node Manager.

See

Table A-1 for the location of the scripts used in this section.

To move the Node Manager configuration:

At the source, ensure that the Node Manager is running.

At the source, copy the Node Manager configuration, by executing the copyConfig script.

See copyConfig Script for Node Manager for the syntax of the script. For example, use the following command:

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
              -archiveLoc /tmp/nm.jar
              -sourceNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
              -logDirLoc /tmp/logs

If you are copying the Node Manager to a different host, copy the archive file to that system.
At the source, extract the move plan from the archive, using the extractMovePlan script.
See extractMovePlan Script for the syntax of the extractMovePlan script.

For example:
```
extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
                 -archiveLoc /tmp/nm.jar
                 -planDirLoc /tmp/Oracle/t2p_plans/nm
```
Edit the move plan, modifying the properties to reflect the values for the target environment. See Table A-12 and Table A-13 to find the list of properties for Node Manager.
Copy the edited move plan, along with any folders created by the extractMovePlan script to the target. (These folders are located in the location specified by the planDirLoc parameter.)

During the pasteConfig operation, you specify the location using the -movePlanLoc option.
At the target, run the following script to generate obfuscated password files required by the move plan. Run the script for each password file.
```
(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home
```
The script prompts you to enter the password and the path, including the file name, where the password file is to be written.

At the target, extract the files from the archive using the pasteConfig script.

See pasteConfig Script for Node Manager for the syntax of the script.

For example, use the following command:

pasteConfig -javaHome /scratch/oracle/jdk1.8.0_40
            -archiveLoc /tmp/nm.jar
            -targetNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
            -targetOracleHomeLoc /scratch/oracle/Oracle_home1
            -movePlanLoc /tmp/Oracle/t2p_plans/nm/moveplan.xml

20.3.7 Configuring Users and Groups

You must configure security in the new target environment. The steps you take depends on the configuration of your environment and application.

The target environment LDAP identity store may not use the same users and groups as the source environment, or it may already be populated with users and groups. Take the following steps only if the LDAP store is an Oracle Fusion Middleware Administering Oracle WebCenter Enterprise Capture LDAP store and you need to move users, groups, and passwords from the source environment to the target environment:

Export the users and groups from LDAP identity store on the source environment, using the ldapsearch command. This produces an ldif file that you later import into the LDAP identity store in the target environment. The ldapsearch command is located in the ORACLE_HOME/bin directory of the Identity Management components. For example:
```
ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port 
  -D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"
```
Import the ldif file that you exported from the source environment into the target environment, using the ldapaddmt command, as shown in the following example. (ORACLE_HOME is the Oracle home for Identity Management.)
```
ORACLE_HOME/bin/ldapaddmt -h production_oid_host
   -p production_oid_port -D "cn=orcladmin"
   -w "production_orcladmin_passwd" -r -f ldif_filename
```

20.3.8 Additional Considerations in an SSL-Only Environment

If you are moving an environment that is configured for SSL only, note the following:

On Windows, for an SSL-only environment with Demo KSS certificates, set the following environment variable before starting Managed server:
```
set JAVA_OPTIONS=-Dweblogic.security.SSL.ignoreHostnameVerification=true
```
Then, start the Managed Server using the additional parameter noted in the next item.

For an SSL-only environment with Demo KSS certificates, pass the following additional parameter to start the Managed Server:.

-Dweblogic.security.SSL.ignoreHostnameVerification=true)

For example:

StartManagedWebLogic.sh Managed_Server_name https://hostname:port_num
-Dweblogic.security.SSL.ignoreHostnameVerification=true

For an SSL-only environment with custom JKS certificates, take one of the following steps:

Before starting the Managed Servers, import the certificates to the target, using a command similar to the following:

keytool -importcert -trustcacerts -alias hostalias -file
/scratch/oracle/keystores/hostalias_identity_exportcert.cer -keystore
/scratch/oracle/ORACLE_HOME/wlserver/server/lib/cacerts
-storepass changeit

Explicitly pass the trust keystore location when you start the Managed Server. For example:

startManagedWebLogic.sh Managed_Server_name https://hostname:port_num
"-Dweblogic.security.SSL.trustedCAKeyStore=/scratch/Oracle/keystores/Hostname_trust.jks"

20.3.9 Starting Managed Servers and Components

When the movement procedure completes, the Administration Server, Managed Servers, Node Manager, and the components are stopped. Take the following steps:

Start Node Manager, as described in Starting and Stopping Node Manager.
Start the Administration Server, as described in Starting and Stopping Administration Server.
Start the Managed Servers, as described in Starting and Stopping Managed Servers
Start components, as described in Starting and Stopping Components.

20.4 Additional Steps or Information for Certain Components

Some components require additional step to complete the movement process from a test to a production environment.

Table 20-2 shows whether any additional steps are needed to complete the movement of particular components or provides additional information.

Table 20-2 Components Requiring Additional Steps for Movement to a New Environment

Component	Additional Procedures
Oracle Application Development Framework	None
Oracle B2B	See Additional Steps for Moving Oracle B2B
Oracle Business Activity Monitoring	None
Oracle Business Process Management	See Additional Steps for Moving Oracle Business Process Management
Oracle Coherence	None
Oracle Data Integrator	Additional Steps for Moving Oracle Data Integrator
Oracle Enterprise Data Quality	None
Oracle Enterprise Scheduler	None
Oracle Forms Services	See Additional Steps for Moving Oracle Forms Services.
Oracle HTTP Server	None
Oracle Managed File Transfer	None
Oracle Service Bus	See Step 6 in Moving the Configuration of a WebLogic Server Domain
Oracle SOA Suite	None
Oracle Traffic Director	Additional Steps for Moving Oracle Traffic Director
Oracle User Messaging Service	None
Oracle WebCenter Content	See Additional Information and Procedures for Moving Oracle WebCenter Content for information about using the `init` or `copy` options in the move plan and for information about an SSL-only environment.
Oracle WebCenter Portal	See Additional Steps for Moving Oracle WebCenter Portal
Oracle WebCenter Sites	See Additional Steps for Moving Oracle WebCenter Sites
Oracle Web Services Manager	None
Oracle WebLogic Server	None

20.4.1 Additional Steps for Moving Oracle Data Integrator

Note the following additional steps that you must take when moving Oracle Data Integrator:

Create the required master and work repositories schemas in the target database using RCU. See the Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility.

Make sure that both the work and master repositories in the target environment are created with unique IDs across your entire organization, including your development and source repositories. Also make sure that the target work repository is created with the same type as the source repository (For example, if the source work repository is created as a development repository, the target work repository must also be created as a development repository).

The ODI Work Repository Name, created as part of RCU's Custom Variables for Oracle Data Integrator, is reflected as <configProperty id="WORKREP1"> in the moveplan.xml file, as shown in the following example:

...
 <configProperty id="WORKREP1">
       <configProperty>
          <name>Url</name>
          <value>jdbc:oracle:thin:@localhost:1521:ora1120</value>
          <itemMetadata>
             <dataType>STRING</dataType>
             <scope>READ_WRITE</scope>
          </itemMetadata>
       </configProperty>
       <configProperty>
          <name>User</name>
          <value>odi_work_11g</value>
          <itemMetadata>
             <dataType>STRING</dataType>
             <scope>READ_WRITE</scope>
          </itemMetadata>
       </configProperty>
       <configProperty>
@           <name>Password File</name>
          <value>/tmp/all_pswd.txt</value>
          <itemMetadata>
             <dataType>STRING</dataType>
@              <password>true</password>
             <scope>READ_WRITE</scope>
          </itemMetadata>
       </configProperty>
    </configProperty>
...

It is important to note that if default ODI Work Repository name, WORKREP reflected as WORKREP1 in the moveplan.xml, is changed, the corresponding name change is correctly modified and followed in the production environment.

For more details about creating schemas, see Oracle Fusion Middleware Creating Schemas with the Repository Creation Utility. Additional information is provided in the Online Help for RCU.

Create Projects and Models by using the ODI Client (Studio) before running the movement scripts.

When you run the copyConfig script, note the following:

You must pass a configuration file to the copyConfig script when the Agent is configured. You pass this using the -additionalParams option with the argument odiCustomArg. For example:

./copyConfig.sh -javaHome /private/Middleware/jrockit_160_26_D1.2.0-5
   -archiveLocation /tmp/ar.jar 
   -sourceOracleHomeLoc /private/Middleware 
   -sourceDomainLoc /scratch/oracle/domains/base_domain 
   -domainHostName host1.example.com 
   -domainPortNum 7001 
   -domainAdminUserName weblogic 
   -domainAdminPasswordFile /tmp/wls_pswd.txt 
   -additionalParams odiCustomArg=/private/t2p/odiCustomArg.xml

The file odiCustomArg.xml is the configuration file. A sample file is located in:

ORACLE_HOME/ODI_Oracle_Home/odi/plugin/t2p/odiCustomArg.xml

The configuration file that you pass to the script contains the connection information for all Oracle Data Integrator master repositories. The following shows a sample configuration file:

<?xml version="1.0" encoding="UTF-8" ?>
<config>
   <masterRepositories>
       <masterRepository>
           <driver>oracle.jdbc.OracleDriver</driver>
           <url>jdbc:oracle:thin:@localhost:1521:sid</url>
           <schema>odi_master_12c</schema>
           <schema_password_file>/tmp/all_pswd.txt</schema_password_file>
            <supervisor>SUPERVISOR</supervisor>
            <supervisor_password_file>/tmp/sup_pswd.txt</supervisor_password_file>
       </masterRepository>
       <masterRepository>
                        .....content for 2nd master repository
       </masterRepository>
    </masterRepositories>
</config>

The following explains the entries in the configuration file:

masterRepositories: Contains the list of ODI Master Repositories.
masterRepository: The section for ODI Master Repositories.
driver: The JDBC Driver to connect to the ODI Master Repository.
url: The JDBC URL to connect to the ODI Master Repository. You must use the proper syntax based on the usage of SID or service name.Use one of the following formats:
```
<url>jdbc:oracle:thin:@hostname:port/servicename</url>
<url>jdbc:oracle:thin:@hostname:port:SID</url> 
```
schema: The schema name for the ODI Master Repository.
schema_password_file: The path for the file containing the password for the schema.
supervisor: The supervisor user for the ODI Master Repository.
supervisor_password_file: The path for the file containing the password for the supervisor user.

The movement scripts update the physical architecture in the target environment according to the information you specified in the move plan. Review the following items in the physical architecture in the target environment before proceeding:
- Physical Agents: Change the host, port, and Web application context (for Java EE Agent) to match the configuration of the target environment.
- Data Servers: Change the data server connection information (JDBC, JNDI, data source name) to match the configuration of the target environment.
- Physical Schemas: The schemas (including file folder location) defined for the data servers must match the configuration of the target environment.
After you complete the movement, restart the Java EE agents in the target environment. These agents start processing the scheduled scenarios.

20.4.2 Additional Steps for Moving Oracle B2B

Oracle B2B is moved to the target environment when you execute the movement scripts. However, you must take the following additional steps:

Migrate the Keystore Service certificates, as described in "Migrating Keystore Service Artifacts Within a Domain" in Oracle Fusion Middleware Securing Applications with Oracle Platform Security Services and update the keystore password using the B2B interface.
The movement process deploys the Agreements and enables the channels. After you complete the movement process, and before you start the Oracle B2B and Oracle B2B for Healthcare runtime, make sure respective Agreements are deployed and expected listening channels are enabled.

20.4.3 Additional Steps for Moving Oracle Business Process Management

To move Oracle Business Process Management organizational units and dashboards to the new target environment:

To create organizational units, see "Managing Organizational Units in Process Workspace" in the Oracle Fusion Middleware Managing and Monitoring Processes with Oracle Business Process Management.
To move dashboards, use the ant-t2p-workspace.xml migration tool. The migration tool is available as an ant target that can be executed in the command line. It calls a configuration file that you create specifying the input parameters for the migration of data, as described in this task.

This script moves dashboards data with the BAM_WIDGET data type in the BPMUserApplicationData table to the target environment.

Note that the migration tool does not move any user-specific configuration because users in the source and target environments would not be same.

You use the following script:

ORACLE_HOME/soa/bin/ant-t2p-workspace.xml

The command has the following format:

ant -f ant-t2p-workspace.xml
     -Dbea.home=BEA_HOME
     -Dbpm.home=BPM_HOME
     -Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE

Take the following steps:

Ensure that the PATH environment variable contains the required JAVA_HOME and ANT_HOME environment variables and that they point to the locations within the Oracle SOA Suite installation.
Set the encryption key oracle.bpm.services.client.key as an environment variable. For example:
```
oracle.bpm.services.client.key=1XXXX6XXXXX98XXX
```
You can also set the encryption key by passing it as an argument to the ant command. If you do not specify it, the ant task prompts you to enter it.

Export dashboards from the source environment:

Create a configuration file to export dashboards:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration 
  xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" 
  xmlns:ns2="http://xmlns.oracle.com/bpm/common" 
  override="true" skip="true">
  <sourceEndPoint>
    <serverEndPoint>
      <serverURL>t3://host:port</serverURL>
      <adminUserLogin>admin_username</adminUserLogin>
      <adminUserPassword>admin_password</adminUserPassword> 
      <realm>jazn.com</realm>
    </serverEndPoint>
  </sourceEndPoint>
  <targetEndPoint>
    <fileEndPoint>
       <migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
    </fileEndPoint>
  </targetEndPoint>
  <operation>EXPORT</operation>
  <object>DASHBOARD</object>
  <objectDetails>
      <login>username</login>
      <password>password</password>
      <identityContext>jazn.com</identityContext>
      <userApplicationData>
         <ownerId>username/ownerId>
        <option>CUSTOMLAYOUT</option>
      </userApplicationData>
  </objectDetails>
</testToProductionMigrationConfiguration>

In the configuration file, you must specify the values for the source environment in the following elements:

serverURL: The SOA server URL.
adminUserLogin: The Administration user name.
adminUserPassword: The password for the Administration user.
migrationFile. The file that was generated by the export operation.
objectDetails: The login and password elements.
userApplicationData: The ownerID element.

Export dashboards, using the following command:

ant -f ant-t2p-workspace.xml
     -Dbea.home=WLS_HOME
     -Dbpm.home=BPM_HOME
     -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE

Import dashboards:

Create a configuration file to import dashboards:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration 
  xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config" 
  xmlns:ns2="http://xmlns.oracle.com/bpm/common" 
  override="true" skip="true">
  <sourceEndPoint>
    <fileEndPoint>
        <migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
    </fileEndPoint>
  </sourceEndPoint>
  <targetEndPoint>
    <serverEndPoint>
      <serverURL>t3://host:port</serverURL>
      <adminUserLogin>admin_username</adminUserLogin>
      <adminUserPassword>admin_password</adminUserPassword>
      <realm>jazn.com</realm>
    </serverEndPoint>
  </targetEndPoint>
  <operation>IMPORT</operation>
  <object>DASHBOARD</object>
  <objectDetails>
      <login>username</login>
      <password>password</password>
      <identityContext>jazn.com</identityContext>
      <userApplicationData>
        <ownerId>username/ownerId>
        <option>CUSTOMLAYOUT</option> 
      </userApplicationData>
  </objectDetails>
</testToProductionMigrationConfiguration>

In the configuration file, you must update the following elements with the values for the target environment:

serverURL: The SOA server URL.
adminUserLogin: The Administration user name.
adminUserPassword: The password for the Administration user.

The password will be encrypted when you first run the ant-t2p-workspace.xml tool.
migrationFile. The file that was generated by the export operation.
objectDetails: The login and password elements.

The password will be encrypted when you first run the ant-t2p-workspace.xml tool.
userApplicationData: The ownerID element.

Import dashboards, using the following command:

ant -f ant-t2p-workspace.xml
     -Dbea.home=BEA_HOME
     -Dbpm.home=BPM_HOME
     -Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE

20.4.4 Additional Steps for Moving Oracle Forms Services

Oracle Forms Services is moved to the target environment when you execute the movement scripts. However, you must take the following additional steps:

There are no specific move plan properties for Oracle Forms Services. However, you must update the Oracle home location in the deployment plan file on the target, which is located in:
```
planDirLoc/deployment_plans
```
If there any Forms application files (fmx's, mmx's, pll's etc.) that are not shared over the network, copy them to the target environment.
If the source and target environments don't share a common application database, enter the target database connection information in the tnsnames.ora file on the target environment. This file is located under the directory:
```
DOMAIN_HOME/config/fmwconfig
```
If your environment includes an SSL-only configuration with Demo KSS certificates or with Custom JKS certificates, you must take additional steps before you start the Managed Server, as described in Additional Considerations in an SSL-Only Environment.

20.4.5 Additional Steps for Moving Oracle Traffic Director

After you move the configuration of Oracle Traffic Director, you must reconfigure the certificates in the target environment. See "Managing Certificates" in Oracle Fusion Middleware Administering Oracle Traffic Director.

20.4.6 Additional Steps for Moving Oracle WebCenter Portal

Oracle WebCenter Portal is moved to the target environment when you execute the movement scripts. However, you must take the additional steps in the following topics:

20.4.6.1 Move Oracle WebCenter Portal Data to the Target Environment (Optional)

If you want to move Oracle WebCenter Portal data such as data associated with events, lists, links, tags, and people connections, to the target environment:

Export WebCenter Portal data from the source database, using the following commands from the ORACLE_HOME/bin (UNIX) and the ORACLE_HOME\bin (Windows) directories, where ORACLE_HOME is the Oracle home for the Oracle Database:

sqlplus "sys/password as sysdba"
create or replace directory directory as 'path';
exit;

expdp "sys/password@connect_id as sysdba"
schemas=prefix_WEBCENTER directory=directory dumpfile=filename
 logfile=expdp_prefix_WEBCENTER.log

Import WebCenter Portal data to the target database, using the file you exported in Step 1. Execute the following commands, where ORACLE_HOME is the Oracle home for the Oracle Database:

ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
create or replace directory directory as 'path';
exit;

ORACLE_HOME/bin/impdb "sys/password@connect_id as sysdba"
DIRECTORY=directory dumpfile=filename remap_schema=wcp_WEBCENTER:WEBCENTER
TABLE_EXISTS_ACTION=REPLACE

20.4.6.2 Move Oracle WebCenter Content Documents and Folders Associated with Spaces (Optional)

If you want to move data stored through WebCenter Portal in Oracle WebCenter Content, move Oracle WebCenter Content using the copy option, as described in Additional Information and Procedures for Moving Oracle WebCenter Content.

20.4.6.3 Move Discussions Server Data to the Target Environment (Optional)

If your Oracle WebCenter Portal application uses the Discussions service, move the discussion server data from the source environment to the target environment:

Export the discussion server data using the Oracle Database export utility from the ORACLE_HOME/bin (UNIX) and the ORACLE_HOME\bin (Windows) directories, where ORACLE_HOME is the Oracle home for the Oracle Database:

expdp "sys/password@connect_id as sysdba"
  OWNER=src_prefix_DISCUSSIONS DUMPFILE=dumpFileName.dmp STATISTICS=none 
  schemas=src_prefix_DISCUSSIONS directory=directory dumpfile=filename
  schemas=src_prefix_DISCUSSIONS_CRAWLER directory=directory dumpfile=filename

Import the discussion server data:

Shut down the target discussions server.
Go to the ORACLE_HOME/bin directory of the database where WebCenter Portal's discussions server schema is installed, and connect to the database using sqlplus as sysdba:
```
ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"
```

Drop the target user and create a new user:

drop user trgt_prefix_DISCUSSIONS cascade;
create user trgt_prefix_DISCUSSIONS identified by password 
   default tablespace trgt_prefix_IAS_DISCUSSIONS temporary 
   tablespace name_IAS_TEMP;

Grant connect and resource to the user:

grant connect,resource, create view to trgt_prefix_DISCUSSIONS;

Exit SQLPlus:
```
exit;
```

Import the discussion server data, using the Oracle Database import utility from the ORACLE_HOME/bin (UNIX) and the ORACLE_HOME\bin (Windows) directories, where ORACLE_HOME is the Oracle home for the Oracle Database:

impdp \"sys/password@serviceid as sysdba\" 
remap_schema=src_prefix_DISCUSSIONS:trgt_prefix_DISCUSSIONS
remap_schema=src_prefix_DISCUSSIONS_CRAWLER:trgt_prefix_DISCUSSIONS_CRAWLER
 remap_tablespace=source_tablespace:target_tablespace exclude=user
DUMPFILE=dumpFileName STATISTICS=none

20.4.7 Additional Information and Procedures for Moving Oracle WebCenter Content

Oracle WebCenter Content is moved to the target environment when you execute the movement scripts. For the Oracle WebCenter Content server or Oracle WebCenter Content: Records, you have two options for moving the component:

copy: This option copies the entire source system, including configuration and data, to the target system. Although this is the default, Oracle does not recommend using this option because it moves test data, which might not be appropriate for your environment. In addition, that step:
- Copies the configuration, including the modified settings, of Oracle WebCenter Content and its components.
- Copies the BPEL credentials.
- Moves Oracle WebCenter Capture.
- Moves Oracle Web Services Manager policies.
- Sets the Listen address for the Managed Server that contains Oracle Application Extension Framework (AXF).
- Starts the Administration Server and Managed Servers.
init: This option initializes a new Content Server or Records instance in the target system. It does not move data. It copies the source domain and Managed Servers to the target system.

In addition, when you use the init option, the pasteConfig script copies the following initialization properties from the source system:
```
IDC_Name
IDC_Id
InstanceMenuLabel
InstanceDescription
IntradocServerPort
IdcCommandServerHost
SocketHostAddressSecurityFilter
HttpServerAddress
HttpRelativeWebRoot
UseSSL
MailServer
SysAdminAddress
IsAutoNumber
AutoNumberPrefix
AdditionalRegisteredComponents
AdditionalEnabledComponents
```

You specify the copy or init option in the move plan, in the MoveType configProperty, as described in Table A-26. Then, you modify the properties listed in that configGroup.

Note that if custom certificates are used, custom certificates are generated and identity and trust keystores are updated accordingly in the move plan. For an SSL-only environment, follow the procedure in Additional Considerations in an SSL-Only Environment.

If your target environment is an SSL-only environment with Demo certificates, take the following steps after you run the copyConfig script.

Export the certificate used by the Content Server URL from the browser.
Make sure all servers are started.

Import the certificate to the local JDK cacerts directory using the following command:

JDK_HOME/bin/keytool -import -keystore
JDK_HOME/jre/lib/security/cacerts -file cscert_file_location
/path-to-keystores/custom_keystores/hostname_identity_exportcert.cer

Restart the WebCenter Content and WebUI servers.
In Fusion Middleware Control, navigate to the MBean browser, as described in Using the System MBean Browser.
In the MBean Browser, expand Application Defined MBeans. Then, expand oracle.adf.share.connections, then Server:WCCcontentADF_server, then Application: Oracle WebCenter Content - Web UI, then ADFConnections, then ADFConnections, then WccConnection. Select WccAdfDefaultConnection.
Update the following fields:
- PropConnectionURL: For example, https://hostname.domainname:16201/cs/idcplg
- PropCredentialPassword
- PropProtocolHttpLibrary
- PropCredentialImpersonationAllowed. Set this to true.
Click Apply.
Navigate to Application Defined MBeans and expand it. Then, expand oracle.adf.share.connections, then Server:WCContentADF_server, then Application: Oracle WebCenter Content - Web UI. Select ADFConnections.
Select the Operations tab. Click Save.
Click Invoke.
Restart the WebUI server (WCCADF_servername).

20.4.8 Additional Steps for Moving Oracle WebCenter Sites

Oracle WebCenter Sites is moved to the target environment when you execute the movement scripts. However, you must take additional steps: to configure Oracle WebCenter Sites, as described in Switching from Test Mode to Production Mode in Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Sites.

20.5 Incrementally Moving Artifacts

The movement scripts are intended for moving to a new target environment. They do not support moving artifacts to an already existing environment.

If you have already moved your environment to a new target, at some later time, you may want to move artifacts that have changed in your source environment to your target environment. For information about moving artifacts that have changed, see the documentation for the particular component, such as Oracle HTTP Server.

20.6 Moving Distributed Topologies

There are special considerations when you have a distributed topology, such as a multiple host or Oracle RAC environment.

The following topics describe considerations when you have a distributed topology:

20.6.1 Considerations with a Multiple Host Environment

If your domain is distributed across multiple hosts, you must take additional steps to complete the movement.

These steps assume that you have taken the steps in Common Procedures for Moving to a Target Environment on the Administration Server host:

If you do not use shared disks, use the pasteBinary command to create an Oracle home on the remote host, for example, Host B. You use the same archive that you created in Moving the Oracle Home and the Binary Files Using the Scripts Step 1.
For example:
```
pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40 
               -archiveLoc  /tmp/oh_copy.jar 
               -targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod 
               -targetOracleHomeName ORACLE_HOME_prod
```
Re-create the domain directory for the remote Managed Servers by using the Oracle WebLogic Server pack and unpack commands. For more information, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.

20.6.2 Considerations in Moving to and from an Oracle RAC Environment

If you are moving your environment to or from an Oracle Real Application Cluster (Oracle RAC) environment, note the following:

If you are moving from a source environment that is not an Oracle RAC environment to a target environment that uses Oracle RAC, the move plan will have one entry for a generic data source (for example mds-adf.) You update the move plan to point to one of the Oracle RAC instances and complete the move from the source environment to the target environment.

Then, you configure your target environment for Oracle RAC, as described in the Oracle Fusion Middleware High Availability Guide, especially "Database Considerations."
Multi data sources are moved to the target environment, even though they are not listed in the move plan.
If you are moving from a source environment that uses Oracle RAC to a target environment that does not use Oracle RAC, the move plan will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances, you will have four generic data sources that are named mds-adf-rac1 through mds-adf-rac4. You update the move plan to point all generic data sources to the single non-RAC instance in the target environment.
If you are moving from a source environment that uses Oracle RAC to a target environment that uses Oracle RAC, but you have more Oracle RAC instances in the target environment, the move plan will have multiple entries for generic data sources. For example, if you have three Oracle RAC instances on the source environment, you will have three generic data sources that are named mds-adf-rac1 through mds-adf-rac3. You have four Oracle RAC instances in the target environment. You update the move plan to point the generic data sources to the first three generic data sources in the target environment.
If you are moving from a source environment that uses Oracle RAC to a target environment that uses Oracle RAC, but you have fewer Oracle RAC instances in the target environment, the move plan will have multiple entries for generic data sources. For example, if you have four Oracle RAC instances on the source environment, you will have four generic data sources that are named mds-adf-rac1 through mds-adf-rac4. You have three Oracle RAC instances in the target environment. You update the move plan to point the first three generic data sources to the three generic data sources in the target environment. You point the last generic data source to the third generic data source. (The third Oracle RAC instance will contain both mds-adf-rac3 and mds-adf-rac4).

Then, you can add an additional data source, as described in Creating a JDBC Data Source Using Fusion Middleware Control.

20.7 Recovering from Test to Production Errors

When you execute the pasteBinary or pasteConfig scripts and enter incorrect information in the move plan, the scripts return an error. In some cases, the scripts may have partially completed the paste operation.

To recover, take the following actions, depending on the script that returned the error:

When you move any environment which contains a Web Tier component, such as Oracle HTTP Server, the copyBinary script may return the following message:

Warning Message  :1
  Nov 20, 2014 10:47:57 - WARNING - CLONE-20266   Unable to archive a file.
  Nov 20, 2014 10:47:57 - CAUSE - CLONE-20266   The file
"/scratch/oracle/webtier6400/network/log/cgisock.9465" did not have
sufficient permission to access.
  Nov 20, 2014 10:47:57 - ACTION - CLONE-20266   Correct the permission of
above file and run copyBinary again.

You can safely ignore this message.

On Windows if you are using the Sun JDK, the copyBinary, pasteBinary, copyConfig, or pasteConfig operations may fail with the following error:
```
java.nio.channels.OverlappingFileLockException
```
In this case, use the T2P_JAVA_OPTIONS to set the system property sun.nio.ch.disableSystemWideOverlappingFileLockCheck as shown in the following example:
```
set T2P_JAVA_OPTIONS=
-Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true
```
Then, retry the operation.
If you need to re-run the pasteConfig script and your environment includes Oracle Platform Security Services, set the following environment variable:
```
setenv T2P_JAVA_OPTIONS="-Dopssdata.import=false"
```
This setting prevents the pasteConfig script from attempting to import data into the OPSS schema. If the data already exists in the schema, the pasteConfig script will fail.
If the pasteBinary script returns an error while moving the Oracle home directory at the target:
1. Delete the target Oracle home.
2. Remove the Oracle home entry from the Oracle inventory, if it is present.
3. For Windows, remove the shortcut for the Oracle home.
The copyConfig script requires that all servers be running, but that they are idle, so that no directories are being modified. If a server is not idle, the copyConfig script reports that the cloning operation completed successfully and the copyConfig error log file will remain at 0 bytes. However, the copyConfig standard log file will contain an error regarding writing to the packed_domain.jar. That error will cause the pasteConfig process to fail.

To work around this issue, wait for a short period of time, then retry the copyConfig operation again.
If the pasteConfig script returns an error while moving Java components:
1. Stop all processes related to the domain.
2. Delete the following directories:
```
ORACLE_HOME/user_projects/domains/domain_name
ORACLE_HOME/user_projects/applications/domain_name
```
3. Drop the schemas and re-create them using RCU.
In addition, if the Oracle Platform Security reassociation failed:
- If you are moving from a file-based store to an LDAP store, specify a different value in the move plan.
- For an LDAP store, delete the domain node.
- For a database-based store, drop the schema and re-create it using RCU.
If you encounter an out-of-memory error when you are using the pasteConfig script, you can work around this in one of the following ways:
- Increase the JVM heap size: Use the option -Xmx for maximum heap size, and -Xms for initial heap size. For example:
```
CONFIG_JVM_ARGS="-Xms512m -Xmx1024m"
```
- Often, the Oracle WebLogic Server domain directory structure contains some large, unnecessary files, such as large older log files. You can delete these files, then run the copyConfig and pasteConfig scripts again.
If you encounter the following error when you are using the copyConfig script for an Oracle SOA Suite installation, use the T2P_JAVA_OPTIONS environment variable to increase the message size:
```
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'. 
```
You use the T2P_JAVA_OPTIONS environment variable, as described in About the Movement Scripts, to pass the -Dweblogic.MaxMessageSize=20000000 property to both the copyConfig and pasteConfig scripts.
When you use the pasteConfig operation and Oracle B2B inbound/outbound dispatcher is configured, you may receive the following error:
```
oracle.mds.exception.MDSRuntimeException: java.sql.SQLException: Data Source
mds-soa does not exist.
Data Source mds-soa does not exist.
 
```
In this situation, after the failure, kill the Managed Server process and manually restart the Managed Server.
If you receive an error when you attempt to start the Oracle SOA Suite Managed Server, you must modify system parameters using the Administration Console after you run the pasteConfig script. (Note that the pasteConfig script sets these system parameters with temporary values.)
1. Log into the Oracle WebLogic Server Administration Console.
2. In the Domain Structure window, expand Environment.
3. Click Servers. The Summary of Servers page appears.
4. Select the server.
5. Select the Server Start tab.
6. In the Arguments field, enter the following parameters:
```
-Dtangosol.coherence.wkan=hostname
-Dtangosol.coherence.localhost=hostname
-Dtangosol.coherence.localport=localport_number
-Dtangosol.coherence.wka1.port=port_number_for_Coherence
```
7. Click Save and Activate Changes.
8. Start the server.