Out-of-Place Cloned Upgrade

Considerations for an Out-of-Place Cloned Upgrade

This section lists the consideration for an out-of-place cloned upgrade:

Parent topic: Out-of-Place Cloned Upgrade

Symmetry

It is recommended that the cloned environment be identical to the source environment. The less you change, the less you have to re-configure during the cloning process.

This includes the following:

Application URLS – If you access your application using login.example.com, then your cloned environment should use login.example.com as well.
Host Names – Host names should be identical on both the source and clone. As a best practice, Oracle recommends to use virtual host names rather than physical hostnames. For example, instead of using mhost.example.com, you use OAMHOST1.example.com. If you are using virtual host names, then simply alias those to the physical host names in your local hosts file. If you are not using virtual host names, then the same can be achieved by aliasing your source physical host names to your cloned host name in your local hosts file.

This will include database as well as middle ware host names.

Whilst this is the desired approach, which ensures that no reconfiguration is required using the cloning process it is possible to change host names, if required. But, this adds complexity to the solution.
File System Paths– File system paths should be identical on both your source and primary systems.

Parent topic: Considerations for an Out-of-Place Cloned Upgrade

Load Balancer

In a high availability configuration, Oracle Identity and Access Management will reside behind an Oracle HTTP server,which will be used to route requests to the Oracle Weblogic components. Access to the Oracle HTTP servers will be through a load balancer. In an Out of Place cloned environment, you can either utilise your existing Load Balancer or use a different one. If you are using a different load balancer, then you will need to ensure that you copy your SSL certificates across.

Parent topic: Considerations for an Out-of-Place Cloned Upgrade

Databases

The strategy involves cloning your database objects from the source system to the destination system. There are multiple ways of cloning a database and each has its merits.

Note:

Oracle Identity and Access Management 12c does not support Oracle Access Manager and Oracle Identity Manager configured to use the same database schema prefix. Before you upgrade, if both products co-exist and share the same database schemas, you must first split the database into two different prefixes and schema sets.

You can use the following options to clone the database:

Option 1 – Database Export Import

Suitable for smaller sized databases.
Allows movement between versions. For example, 12.1.0.3 to 19c.
Allows movement into Container Databases/Private Databases.
Is a complete copy; redoing the exercise requires data to be deleted from the target each time.
No ongoing synchronization.
During cut-over the source system will need to be frozen for updates.

Option 2 – Duplicate Database using RMAN

Suitable for databases of any size.
Takes a back up of an entire database.
The database version and patch level should be the same on both the source and destination.
Database upgrades will need to be performed as a separate task.
CDP/PDB migration will have to be done as a separate exercise.
No ongoing synchronization.
During cut-over, you should freeze the source system for updates.

Option 3 – Dataguard Database

Suitable for databases of any size.
Takes a back up of an entire database.
Database upgrades will need to be performed as a separate task.
CDP/PDB migration will have to be done as a separate exercise.
Ongoing synchronisation; Database can be opened to test the upgrade and closed again to keep data synchronized with the source system.

Note:

You should choose the solution based on your requirements.

Parent topic: Considerations for an Out-of-Place Cloned Upgrade

Cloning Application Binaries

Your source and destination systems must have identical binary installations with the same patches installed on both systems. There are several mechanisms that can be used to clone the application binaries:

Backup/Restore – You can use a backup and restore tool of your choice to copy the middleware homes from the source to the target system.
T2P – If your source environment is 11g, you can use the Oracle Test to Production utility (T2P) to copy the middleware homes from the source to the target system.
Manual Install – If you are certain of the binary installation contents, then you can perform a manual installation/patch application on the destination system.

Note:

You should choose an option based on your requirements. Oracle recommends that you choose the first option to ensure that both systems are identical.

Parent topic: Considerations for an Out-of-Place Cloned Upgrade

Cloning Configuration Information

Your source and destination systems must have an identical configuration. There are two mechanisms that can be used to clone the configuration information:

Backup/Restore – You can use your preferred backup and restore tool to copy the domain/instance configuration from the source to the target system. This will ensure an exact copy and will not let any changes in the configuration (for example, host names remain as that are).
T2P – You can use the Oracle Test to Production (T2P) utility to copy the configuration from the source to the target system. This is a more complicated approach, but lets you make host name changes.

You should choose option based on your requirements.

Parent topic: Considerations for an Out-of-Place Cloned Upgrade

Separate Domains

Oracle Identity and Access Management 12c does not support Oracle Access Manager and Oracle Identity Manager running in the same domain. Before you upgrade a domain where both products co-exist, you must first split the domain into two different domains. For more information, see Separating Oracle Identity Management Applications Into Multiple Domains.

Parent topic: Considerations for an Out-of-Place Cloned Upgrade

Performing an Out-of-Place Cloned Upgrade of Oracle Internet Directory

To perform a cloned upgrade of Oracle Internet Directory:

Place the source directory into read-only mode.
Back up the database that hosts your OID database schemas.
Back up your Oracle Internet binary installation.
Back up Oracle Internet Directory instance configuration.
Back up ODSM/DIP domain directory, if used.
Copy backup files to the destination system.
Restore the database on the destination system.
Restore binaries on destination system.
Restore the Oracle Internet Directory instances on the destination system.
Restore the ODSM/DIP domain directory, if used.
Make any host name changes you require.
Start the Oracle Internet Directory instances.
Start the Oracle OUDSM/DIP domain.
Validate that OID is functioning correctly using in-house tests.
Upgrade the OID installation using the in-place upgrade steps to reach your desired version.

Parent topic: Out-of-Place Cloned Upgrade

Performing an Out-of-Place Cloned Upgrade of Oracle Unified Directory

To perform a cloned upgrade of Oracle Unified Directory:

Place your source directory into read-only mode.
Back up your Oracle Unified Directory binary installation.
Back up your Oracle Unified Directory instance configuration.
Back up your ODSM/DIP domain directory, if used.
Copy your backup files to the destination system.
Restore the binaries on your destination system.
Restore the Oracle Unified directory instances on your destination system.
Restore the ODSM/DIP domain directory, if used.
Make any host name changes you require.
Start your Oracle Unified Directory instances.
Start your Oracle OUDSM/DIP domain.
Validate that OUD is functioning correctly using in-house tests.
Upgrade your OUD installation using the in-place upgrade steps to reach your desired version.

Parent topic: Out-of-Place Cloned Upgrade

Performing an Out-of-Place Cloned Upgrade of Oracle Access Manager

To perform a cloned upgrade of Oracle Access Manager:

Perform a pre-upgrade assessment to ensure that any deprecated products are not used or alternatives are put into place for them.
Place your source system into read-only mode.
Back up your database hosting your OAM database schemas.
Back up your Oracle Access Manager binary installation.
Back up your Oracle Access Manager instance configuration.
Back up your Oracle Access Manager domain directory.
Copy the backup files to the destination system.
Restore the binaries on your destination system.
Restore your Database hosting your OAM database schemas.
Restore the Oracle Access Manager domain directory.
Make any host name changes you require, this can be achieved using T2P.
Start your Oracle Access Manager domain.
Validate that OAM is functioning correctly using in-house tests, including:
- Ensuring that you can see your external directory users in the WebLogic console.
- Ensuring that you can log in to your console using an external directory user.
- Using the AccessManager Test tool.
Upgrade your OAM installation using the in-place upgrade steps to reach your desired version.

Note:

To ensure that you are using your new directory, temporarily shutdown the existing directory so that you do not access it accidentally.

For instructions, see Upgrading Oracle Access Manager for the release you want to upgrade.

Parent topic: Out-of-Place Cloned Upgrade

Performing an Out-of-Place Cloned Upgrade of Oracle Identity Manager

To perform a cloned upgrade of Oracle Identity Manager:

Perform a pre-upgrade assessment.
Place your source system into read-only mode.
Back up your database hosting your OIM database schemas.
Back up your Oracle Identity Manager binary installation.
Back up the Oracle Identity Manager configuration.
Back up the Oracle Identity Manager domain directory.
Copy your backup files to the destination system.
Restore your binaries on your destination system.
Restore your database to the destination system.
Restore the Oracle Identity Manager domain directory.
Make any host name changes you require by using T2P or the OIM host change utility.
Start your Oracle Identity Manager domain.
Validate that OIM is functioning correctly using in-house tests, including:
- Ensuring you can see your external directory users in the OIM console.
- Running the reconciliation jobs.
- Creating a user or role in OIM and ensuring that it gets created in your LDAP directory.
- Marking the end date of an employee and ensuring that any OIM sessions (if using OIM).
- Checking if any Connectors are still functioning.
Upgrade your OIM installation using the in-place upgrade steps to reach your desired version.
If moving from Oracle Identity Manager 11g to 12c, Oracle recomends that you migrate your directory interface from LDAPSYNC to Connector.
Upgrade SOA composites.
Upgrade OIM design console.
Install External BI publisher and install OIM reports.
Tune the application module for user interface.

For instructions, see Upgrading Oracle Identity Manager for the release you want to upgrade.

Parent topic: Out-of-Place Cloned Upgrade

Performing an Out-of-Place Cloned Upgrade of Oracle HTTP Server

To perform a cloned upgrade of Oracle HTTP Server:

Back up your Oracle HTTP Server binary installation.
Back up your Oracle HTTP Server instance configuration.
Copy your backup files to the destination system.
Restore your binaries on your destination system.
Restore the Oracle HTTP Sever instances on your destination system.
Make any host name changes you require.
Start your Oracle HTTP Server instances.
Validate that OHS is functioning correctly using in-house tests, including accessing protected resources.
Upgrade your Oracle HTTP Server installation using the in-place upgrade steps to reach your desired version.

Parent topic: Out-of-Place Cloned Upgrade