1. Upgrading Oracle Identity Manager
  2. One-Hop Upgrade of Oracle Identity Manager
  3. Upgrading Oracle Identity Manager Highly Available Environments

8 Upgrading Oracle Identity Manager Highly Available Environments

You can upgrade Oracle Identity Manager highly available environments from 11g (11.1.2.3.0) to Oracle Identity Governance 12c (12.2.1.4.0) by using the one-hop upgrade process.

Note:

The product Oracle Identity Manager is referred to as Oracle Identity Manager (OIM) and Oracle Identity Governance (OIG) interchangeably in this guide.

Complete the steps as described in the following topics to perform the upgrade:

Parent topic: One-Hop Upgrade of Oracle Identity Manager

About the Oracle Identity Manager Multinode Upgrade Process

Review the roadmap for an overview of the one-hop upgrade process for Oracle Identity Manager highly available environments.

Note:

Multi Data Sources (MDS) are not supported in one-hop upgrade. You must switch to a single or generic data source, and then perform the one-hop upgrade. After completing the upgrade, you can switch back to Multi Data Sources on Oracle Real Application Clusters (RAC).

The upgrade steps explained in this section are for upgrading Oracle Identity Manager 11g Release 2 (11.1.2.3.0) to Oracle Identity Manager 12c (12.2.1.4).

Note:

The entire upgrade process is performed in an HA environment, on the OIG 12c (12.2.1.4) setup machine that runs the Administration Server. Therefore, every step is performed on the same machine (henceforth referred to as OIMHOST1 in this chapter).

In addition, the 11g and 12c (12.2.1.4) setup used/created for one-hop upgrade should use the actual host name or IP address to refer to the machine names/IP addresses instead of using localhost.

Table 8-1 Tasks for Upgrading Oracle Identity Manager Highly Available Environments.

Task Description

Required

Install the Oracle Identity Manager 12c (12.2.1.4) HA setup and apply the latest Stack Patch Bundle (SPB). See Doc ID 2657920.1.

Note: It is enough to apply the patch on the binaries in the Administration Server node. However, if there is a need to keep the binaries and Orainventory in sync between all the nodes of the HA setup, then you may apply the patch on all the nodes.

See Installing Oracle Identity Manager 12c (12.2.1.4) and the Required Patches.

Required

Create a backup of the newly installed 12c (12.2.1.4.0) Oracle Home and Domain Home folders.

Note:

Ensure that the ORACLE_HOME/idm/server/apps/oim.ear/metadata.mar file is included in the backup.

Take an offline backup of the 12c (12.2.1.4.0) folders. See Backing Up Your Environment.

Required

Export and copy the OPSS encryption keys.

See Exporting and Copying the OPSS Encryption Keys.

Optional

Run a pre-upgrade readiness check.

See Running a Pre-Upgrade Readiness Check.

Required

Copy the oracle.iam.ui.custom-dev-starter-pack.war from 11g Middleware Home.

See Copying the oracle.iam.ui.custom-dev-starter-pack.war from the 11g Middleware Home.

Required

Stop all the servers running on the 11g (11.1.2.3.0) setup machine. This includes the Administration Server, Managed Servers, Node Manager, and system components such as Oracle HTTP Server.

Shut down the 12c (12.2.1.4.0) Managed Servers.

Ensure that the 11g database, 12c database, and the 12c Administration Server is up during the upgrade.

See Stopping Servers and Processes.

Required

Create a backup of the existing 11g (11.1.2.3.0) database.

See Backing Up Oracle Identity Manager 11.1.2.x.x Environment.

Required

Upgrade the 11g Schema to 12c (12.2.1.4).

See Upgrading Product Schemas.

Required

Clean the temporary folder.

See Cleaning the Temporary Folder.

Required

Rewire the domain.

See Rewiring the Domain.

Required

Restart the servers.

Note: If the OIM 11g (11.1.2.3.0) setup with JMS persistent store is database based, see Errors Encountered if OIM 11g (11.1.2.3.0) Setup with JMS Persistent Store is Database Based Instead of File Based.

See Restarting the Servers.

Required

Invoke the MBean.

See Invoking the MBean.

Required

Update the endpoint address in SOA composites.

See Updating the EndPoint Address in SOA Composites.

Required

Pack the domain configurations on OIMHOST1.

See Packing Domain Configurations on OIMHOST1.

Required

Replicate the domain configurations on each OIM host machine in the HA environment.

See Replicating the Domain Configurations on Each OIMHOST.

Required

Start the servers on all the nodes.

See Starting the Servers on all Nodes.

Optional

After the one-hop upgrade to 12c (12.2.1.4), the embedded Oracle BI Publisher will not be available. Therefore, to use the Oracle BI Publisher, you have to install and integrate the standalone Oracle BI Publisher with OIM, post the upgrade.

See Installing and Integrating the Standalone Oracle BI Publisher.

Optional

After the upgrade to 12c (12.2.1.4), reinstall the ADF DI Excel plug-in

See Reinstalling the ADF DI Excel Plug-in.

Optional

After the upgrade, define the system properties for legacy connectors.

See Defining System Properties for Legacy Connectors.

Optional

After the upgrade, you to modify the Maximum Message Size from the default vale of 10 MB to 100 MB.

See Increasing the Maximum Message Size for WebLogic Server Session Replication.

Required

After the upgrade, you can increase the maxdepth value in the setDomainEnv.sh file.

See Increasing the maxdepth Value in setDomainEnv.sh.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Installing Oracle Identity Manager 12c (12.2.1.4) and the Required Patches

You should apply the one-hop upgrade one-off patch after the completing the installation and configuration of Oracle Identity Manager 12c (12.2.1.4).

  1. Install and configure Oracle Identity Manager 12c (12.2.1.4) HA environment on the same or on a different machine.

    See Configuring High Availability for Oracle Identity Governance Components in Installing and Configuring Oracle Identity and Access Management.

    Note:

    The settings in the User Messaging Service (UMS) Email Driver present in 11g Release 2 will not be migrated as part of the one-hop upgrade process. If required, you have to configure the UMS Email Driver after installing the 12c (12.2.1.4) software. See Configuring the User Messaging Drivers in Administering Oracle Identity Governance.
  2. Tune the newly installed Oracle Identity Manager 12c (12.2.1.4) setup as per the required load. Improperly tuned servers may fail to start correctly after the upgrade. For information on tuning, see Oracle Identity Governance Performance Tuning and Performance Tuning Guidelines and Diagnostics Collection for Oracle Identity Manager (OIM) (Doc ID 1539554.1)
  3. The Upgrade Assistant requires read-write access to the 11g domain. If you have chosen to install OIG 12c on a machine which does not have read-write access to the 11g domain home, copy over the 11g domain home to a writable location on OIMHOST1 that hosts the OIG 12c setup. Provide this new location when you perform schema upgrade by using the Upgrade Assistant.

    Note:

    If you are using localhost as hostname in your 11g datasources, you need to change all localhost references to the actual hostname on the 11g setup first. You can use the cloning utility to change the references. See Doc ID 2621548.1 and refer the section titled 'Update Hostname in configuration files in DOMAIN_HOME and MDS' of the Migration Document.
  4. Apply the latest Stack Patch Bundle (SPB) using OPatch, on the 12c (12.2.1.4) binaries. See Doc ID 2657920.1.

Note:

Perform the 12c (12.2.1.4) post patching steps only after completing the one-hop upgrade process.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Generating and Analyzing Pre-Upgrade Report for Oracle Identity Manager

Run the pre-upgrade report utility before you begin the upgrade process for Oracle Identity Manager, and address all of the issues using the solution provided in the report.

The pre-upgrade report utility analyzes your existing Oracle Identity Manager environment, and provides information about the mandatory prerequisites that you must complete before you begin the upgrade.

Note:

It is important to address all of the issues listed in the pre-upgrade report before you proceed with the upgrade, as the upgrade might fail if the issues are not resolved.

Ensure that the database of the 11g (11.1.2.3.0) Oracle Identity Manager is up and running before you run the pre-upgrade report utility.

  • Obtaining the Pre-Upgrade Report Utility
    Download the pre-upgrade report utility for Oracle Identity Manager from Oracle Technology Network (OTN).
  • Generating the Pre-Upgrade Report
    Generate the pre-upgrade report before you start the upgrade process for Oracle Identity Manager, and resolve any issues listed in the report.
  • Analyzing the Pre-Upgrade Report
    After you generate the pre-upgrade report for Oracle Identity Manager, review each of the reports, and perform all of the tasks described in them. If you do not perform the mandatory tasks described in the report, the upgrade might fail.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Obtaining the Pre-Upgrade Report Utility

Download the pre-upgrade report utility for Oracle Identity Manager from Oracle Technology Network (OTN).

The utility is available in a zip file named PreUpgradeReport_12cps4.zip at the following location on My Oracle Support:

My Oracle Support document ID 2579747.1

Parent topic: Generating and Analyzing Pre-Upgrade Report for Oracle Identity Manager

Generating the Pre-Upgrade Report

Generate the pre-upgrade report before you start the upgrade process for Oracle Identity Manager, and resolve any issues listed in the report.

To generate the pre-upgrade report for Oracle Identity Manager, complete the following steps on your Administration server host machine:

  1. Create a directory at any location and extract the contents of PreUpgradeReport_12cps4.zip in the new directory.
  2. Create a directory in which to generate the pre-upgrade reports. For example, create a directory named OIM_preupgrade_reports.
  3. Go to the directory where you extracted PreUpgradeReport_12cps4.zip and open the preupgrade_report_input.properties file in a text editor. Update the properties file with the appropriate values of the OIM 11g (11.1.2.3.0) setup for the parameters listed in Table 8-2.

    Table 8-2 Parameters to be Specified in the preupgrade_report_input.properties File

    Parameter Description
    oim.targetVersion Specify the target version of the Oracle Identity Manager, that is, 12c (12.2.1.4.0).
    oim.jdbcurl Specify the JDBC URL for Oracle Identity Manager 11g (11.1.2.3.0) in one of the following formats:

    host:port/service_name

    or

    host:port:sid
    oim.oimschemaowner Specify the name of the OIM schema owner. For example, DEV_OIM.
    oim.mdsjdbcurl Specify the MDS JDBC URL in the one of the following formats:

    host:port/service_name

    or

    host:port:sid
    oim.mdsschemaowner Specify the name of the MDS schema owner. For example, DEV_MDS.
    oim.databaseadminname Specify the user with DBA privilege. For example, sys as sysdba.
    oim.outputreportfolder Specify the absolute path to the directory where you want the reports to be generated (OIM_preupgrade_reports). Ensure that this directory has read and write permissions.
    oim.mwhome Specify the absolute path to the Middleware home of 12c (12.2.1.4.0).

    For example: /u01/oracle
    oim.oimhome Specify the absolute path to the OIM home of 12c (12.2.1.4.0).

    For example: /u01/oracle/idm
    oim.javahome Specify the absolute path to the Java home. Ensure that you point to JAVA 8.
    oim.wlshome Specify the absolute path to the WebLogic Server home for 12c (12.2.1.4.0).

    For example: /u01/oracle/wlserver
    oim.domain Specify the absolute path to the Oracle Identity Manager domain home of 11g (11.1.2.3.0).

    For example: /Oracle/Middleware/user_projects/domains/IAMGovernanceDomain
  4. Run the following command from the location where you extracted the contents of PreUpgradeReport_12cps4.zip:
    • On UNIX:

      sh generatePreUpgradeReport.sh

    • On Windows:

      generatePreUpgradeReport.bat

  5. Provide the details when the following are prompted:
    • OIM Schema Password: Enter the password of the 11g (11.1.2.3.0) Oracle Identity Manager schema.
    • MDS Schema Password: Enter the password of the Metadata Services (MDS) schema.
    • DBA Password: Enter the password of the Database Administrator.
  6. The reports are generated as HTML pages at the location you specified for the parameter oim.outputreportfolder in the preupgrade_report_input.properties file. The logs are stored in the log file preUpgradeReport<time>.log in the folder logs at the same location.

Parent topic: Generating and Analyzing Pre-Upgrade Report for Oracle Identity Manager

Analyzing the Pre-Upgrade Report

After you generate the pre-upgrade report for Oracle Identity Manager, review each of the reports, and perform all of the tasks described in them. If you do not perform the mandatory tasks described in the report, the upgrade might fail.

Table 8-3 Pre-Upgrade Reports Generated for Oracle Identity Manager

Report Name Description and Action Item

Status of OIM System Property-XL.AllowedBackURLs

This report provides the status of the system property related to setting the back URLs in Oracle Identity Manager.

Changes to SCIM-JWT in 12c

This report lists the new SCIM URLs published during 12c (12.2.1.4.0).

You must use the new URLs instead of the old ones.

Potential upgrade issues for User Defined Attributes

This report lists the potential issues with the User Defined Field (UDF) defined in Oracle Identity Manager 11.1.2.3.0, during the upgrade.

Status of Mandatory Database Components

This report lists the installation status of the mandatory database components which are required for upgrade.

OIM-OMSS Integration Pre-Upgrade Report

This report gives the deprecation information about the Oracle Mobile Security Services (OMSS) with Oracle Identity Manager in 12c (12.2.1.4.0).

Status of Mandatory DB Privilege

This report lists the missing mandatory database privileges that are required for upgrade.

Status of data associated with access policies

In 12c, access policies are associated with application instances instead of resource object. To handle the same, this report lists in-consistent data (if present) in the Oracle Identity Manager 11.1.2.3.0.

Information about Schedule Jobs against Schedule task named as OIM Data Purge Task on source environment

This report provides important information regarding one of the schedule tasks which will be available after the upgrade.

Obsolete templates existence status on source environment

This report lists obsolete templates that are present in the source domain prior to the upgrade.

This is a conditional report and will be generated only if a related problem exists in the OIM 11g (11.1.2.3.0) setup.

soaOIMLookupDB data source status on source environment

This report lists non-transactional soaOIMLookupDB data sources in the source domain prior to the upgrade.

This is a conditional report and will be generated only if a related problem exists in the OIM 11g (11.1.2.3.0) setup.

Status of OIM default keystore in KSS on source environment

This report lists the OIM default keystore if it is present in the KSS of the source domain prior to the upgrade.

This is a conditional report and will be generated only if a related problem exists in the OIM 11g (11.1.2.3.0) setup.

MDS Back-up of source environment

This report lists the details regarding the MDS backup taken prior to upgrade.

Customized Notification Templates status on source environment

This report lists customized out-of-the-box (OOTB) notification templates. These customizations will be overwritten with OOTB values during upgrade.

Note:

This report is generated only if there are any discrepancies found.

Status of Domain Configuration

This report lists the applications (if any) that are in stage mode.

Authorization Policy Back-up of source environment

This report lists the details regarding the Oracle Identity Manager authorization policy backup taken prior to upgrade.

Copy Custom UI WAR from source environment

This report reminds you to copy the custom UI war from the previous Middleware home to the new Middleware home, to get the UI customizations after upgrade.

Status of Database Vault Configuration

This is a conditional report. If database vault is enabled on source setup, then this report is created. This report displays information related to database vault settings.

Note:

This report is generated only if there are any discrepancies found.

Parent topic: Generating and Analyzing Pre-Upgrade Report for Oracle Identity Manager

Exporting and Copying the OPSS Encryption Keys

Ensure that the encrypted data from 11g (11.1.2.3) OIG is read correctly after the upgrade to 12c (12.2.1.4) OIG. The exported keys will be required by the oneHopUpgrade tool to complete the upgrade process.

Complete the following steps:

  1. On OIMHOST1 that hosts the 11g setup, export the OPSS encryption key from the Oracle Identity Manager 11g (11.1.2.3) setup.
    1. Create a directory with read/write permissions. This location (<LOCATION_TO_EXPORT_KEY>) will be used in the exportEncryptionKey WLST command.
    2. Navigate to the <11g_(11.1.2.3_ORACLE_HOME>/oracle_common/common/bin location and launch the wlst.sh script.
    3. Execute the exportEncryptionKey WLST command in the offline mode.
      exportEncryptionKey('<11gR2PS3_DOMAIN_HOME>/config/fmwconfig/jps-config.xml', '<LOCATION_TO_EXPORT_KEY>', '<YOUR_OWN_PASSWORD_OF_EXPORTED_KEY>')

      For example:

      exportEncryptionKey('/u01/app/fmw/user_projects/domains/oim_domain/config/fmwconfig/jps-config.xml', '/scratch/opss/', '<password>')

      Note:

      Choose a password of your choice while invoking the exportEncryptionKey WLST offline command. You should provide the same password when you rewire the domain. See Rewiring the Domain.
  2. Create a directory with read/write permissions in the 12c (12.2.1.4) setup location on OIMHOST1. You will use this location for the 11g (11.2.1.3)_files_path_with_rw_permission property in the oneHop.properties file in a later step.
  3. Copy the exported encryption key files (<LOCATION_TO_EXPORT_KEY>/*) and <11g (11.2.1.3)_DOMAIN_HOME>/config/fmwconfig/.xldatabasekey from the 11g (11.1.2.3) setup location to the directory that you created in step 2 in on OIMHOST1.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check from the 12c (12.2.1.4) setup on the 11g (11.1.2.3) domain. Be aware that the readiness check may not be able to discover all potential issues with your upgrade. An upgrade may still fail, even if the readiness check reports success.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

About Running a Pre-Upgrade Readiness Check

You can run the Upgrade Assistant in -readiness mode to detect issues before you perform the actual upgrade. You can run the readiness check in GUI mode using the Upgrade Assistant or in silent mode using a response file.

The Upgrade Assistant readiness check performs a read-only, pre-upgrade review of your Fusion Middleware schemas and WebLogic domain configurations that are at a supported starting point. The review is a read-only operation.

The readiness check generates a formatted, time-stamped readiness report so you can address potential issues before you attempt the actual upgrade. If no issues are detected, you can begin the upgrade process. Oracle recommends that you read this report thoroughly before performing an upgrade.

You can run the readiness check while your existing Oracle Fusion Middleware domain is online (while other users are actively using it) or offline.

You can run the readiness check any number of times before performing any actual upgrade. However, do not run the readiness check after an upgrade has been performed, as the report results may differ from the result of pre-upgrade readiness checks.

Note:

To prevent performance from being affected, Oracle recommends that you run the readiness check during off-peak hours and ensure the following:
  • There is good connectivity between the 12c OIG server, 12c OIG database, and the 11g OIG database.
  • OIG 11g domain directory is accessible to the 12c OIG server in the read/write mode.
  • If the readiness check fails, stop the upgrade process and contact Oracle Support.

Parent topic: Running a Pre-Upgrade Readiness Check

Starting the Upgrade Assistant in Readiness Mode

Use the -readiness parameter to start the Upgrade Assistant in readiness mode.

To perform a readiness check on your pre-upgrade environment with the Upgrade Assistant:
  1. Go to the oracle_common/upgrade/bin directory:
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin

    Where, ORACLE_HOME is the 12c (12.2.1.4.0) Oracle Home.

  2. Start the Upgrade Assistant.
    • (UNIX) ./ua -readiness
    • (Windows) ua.bat -readiness

    Note:

    If the DISPLAY environment variable is not set up properly to allow for GUI mode, you may encounter the following error:
    Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

    To resolve this issue you need to set the DISPLAY variable to the host and desktop where a valid X environment is working.

    For example, if you are running an X environment inside a VNC on the local host in desktop 6, then you would set DISPLAY=:6. If you are running X on a remote host on desktop 1 then you would set this to DISPLAY=remoteHost:1.

    For information about other parameters that you can specify on the command line, see:

Parent topic: Running a Pre-Upgrade Readiness Check

Upgrade Assistant Parameters

When you start the Upgrade Assistant from the command line, you can specify additional parameters.

Table 8-4 Upgrade Assistant Command-Line Parameters

Parameter Required or Optional Description

-readiness

 Required for readiness checks

Note: Readiness checks cannot be performed on standalone installations (those not managed by the WebLogic Server).

Performs the upgrade readiness check without performing an actual upgrade.

Schemas and configurations are checked.

Do not use this parameter if you have specified the -examine parameter.

-threads

Optional

Identifies the number of threads available for concurrent schema upgrades or readiness checks of the schemas.

The value must be a positive integer in the range 1 to 8. The default is 4.

-response

Required for silent upgrades or silent readiness checks

Runs the Upgrade Assistant using inputs saved to a response file generated from the data that is entered when the Upgrade Assistant is run in GUI mode. Using this parameter runs the Upgrade Assistant in silent mode (without displaying Upgrade Assistant screens).

-examine

Optional

Performs the examine phase but does not perform an actual upgrade.

Do not specify this parameter if you have specified the -readiness parameter.

-logLevel attribute

Optional

Sets the logging level, specifying one of the following attributes:

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

The default logging level is NOTIFICATION.

Consider setting the -logLevel TRACE attribute to so that more information is logged. This is useful when troubleshooting a failed upgrade. The Upgrade Assistant's log files can become very large if -logLevel TRACE is used.

-logDir location

Optional

Sets the default location of upgrade log files and temporary files. You must specify an existing, writable directory where the Upgrade Assistant creates log files and temporary files.

The default locations are:

(UNIX)

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

Performing a Readiness Check with the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to complete the pre-upgrade readiness check.

Readiness checks are performed only on schemas or component configurations that are at a supported upgrade starting point.
To complete the readiness check:
  1. On the Welcome screen, review information about the readiness check. Click Next.
  2. On the Readiness Check Type screen, select the readiness check that you want to perform:

    Note:

    For a one-hop upgrade process, Oracle recommends you to use the ‘Domain Based’ option to ensure that all the required schemas and configurations are included in the readiness check

    The Domain Based option enables the Upgrade Assistant to discover and select all upgrade-eligible schemas or component configurations in the domain specified in the Domain Directory field.

    When you select this option, the screen name changes to Schemas and Configuration.

    Leave the default selection if you want the Upgrade Assistant to check all schemas and component configurations at the same time, or select a specific option:

    • Include checks for all schemas to discover and review all components that have a schema available to upgrade.

    • Include checks for all configurations to review component configurations for a managed WebLogic Server domain.

  3. In the Domain Directory field, select the 11g domain folder that was copied to the 12c (12.2.1.4) setup machine in step 3 of Installing Oracle Identity Manager 12c (12.2.1.4) and the Required Patches. If the 12c (12.2.1.4) setup is on the same machine as the 11g Release 2 setup, provide the 11g domain home location during the readiness check.

    Click Next.

  4. The Component List screen displays the list of components whose schema will be upgraded.

    Click Next.

  5. On the Schema Credentials screen, specify the database credentials to connect to the selected 11g (11.1.2.3) schema: Database Type, DBA User Name, and DBA Password. As part of the pre-upgrade requirements, you had created the required user, see Creating a Non-SYSDBA User to Run the Upgrade Assistant.

    Then click Connect.

    Note:

    Oracle database is the default database type. Make sure that you select the correct database type before you continue. If you discover that you selected the wrong database type, do not go back to this screen to change it to the correct type. Instead, close the Upgrade Assistant and restart the readiness check with the correct database type selected to ensure that the correct database type is applied to all schemas.

    Select the Schema User Name option and specify the Schema Password.

    Note:

    The Upgrade Assistant automatically enables the default credentials. If you are unable to connect, ensure that you manually enter the credentials for your schema before you continue.

    Click Next until all schema connections are validated (the screen name changes based on the schema selected).

    Note:

    If you encounter any connection failure, check the cause and fix it.
  6. On the UMS Remote Servers screen, specify whether you want to include the remote servers in the upgrade process. By default, all servers are included. Select Yes, but do not includes these servers in the upgrade if you want to run the check only on the local system and do not want to run the readiness check on the remote servers.
  7. On the UMS Remote Server Login screen, provide the login credentials for the operating system, that is, the user name and the password used during the software installation and configuration process. These credentials enable the readiness check to connect to the remote host through SSH and perform readiness checks on the remote host.
  8. On the Readiness Summary screen, review the summary of the readiness checks that will be performed based on your selections.
    If you want to save your selections to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.
    For a detailed report, click View Log.
    Click Next.
  9. On the Readiness Check screen, review the status of the readiness check. The process can take several minutes.
    If you are checking multiple components, the progress of each component displays in its own progress bar in parallel.
    When the readiness check is complete, click Continue.
    The following components are marked as ready for upgrade although they are not upgraded. Ignore the ready for upgrade message against these components:
    • Oracle JRF
    • Common Infrastructure Services
    • Oracle Web Services Manager
  10. On the End of Readiness screen, review the results of the readiness check (Readiness Success or Readiness Failure):

    • If the readiness check is successful, click View Readiness Report to review the complete report. Oracle recommends that you review the Readiness Report before you perform the actual upgrade even when the readiness check is successful. Use the Find option to search for a particular word or phrase within the report. The report also indicates where the completed Readiness Check Report file is located.

    • If the readiness check encounters an issue or error, click View Log to review the log file, identify and correct the issues, and then restart the readiness check. The log file is managed by the command-line options you set.

Parent topic: Running a Pre-Upgrade Readiness Check

Understanding the Readiness Report

After performing a readiness check for your domain, review the report to determine whether you need to take any action for a successful upgrade.

The format of the readiness report file is:

readiness_timestamp.txt

where timestamp indicates the date and time of when the readiness check was run.

A readiness report contains the following information:

Table 8-5 Readiness Report Elements

Report Information Description Required Action
Overall Readiness Status: SUCCESS or FAILURE The top of the report indicates whether the readiness check passed or completed with one or more errors. If the report completed with one or more errors, search for FAIL and correct the failing issues before attempting to upgrade. You can re-run the readiness check as many times as necessary before an upgrade.

Timestamp

The date and time that the report was generated.

No action required.

Log file location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated log file.

No action required.

Readiness report location

ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated readiness report.

No action required.

Names of components that were checked

The names and versions of the components included in the check and status.

If your domain includes components that cannot be upgraded to this release, such as SOA Core Extension, do not attempt an upgrade.

Names of schemas that were checked

The names and current versions of the schemas included in the check and status.

Review the version numbers of your schemas. If your domain includes schemas that cannot be upgraded to this release, do not attempt an upgrade.

Individual Object Test Status: FAIL

The readiness check test detected an issue with a specific object.

Do not upgrade until all failed issues have been resolved.

Individual Object Test Status: PASS

The readiness check test detected no issues for the specific object.

If your readiness check report shows only the PASS status, you can upgrade your environment. Note, however, that the Readiness Check cannot detect issues with externals such as hardware or connectivity during an upgrade. You should always monitor the progress of your upgrade.

Completed Readiness Check of <Object> Status: FAILURE The readiness check detected one or more errors that must be resolved for a particular object such as a schema, an index, or datatype. Do not upgrade until all failed issues have been resolved.
Completed Readiness Check of <Object> Status: SUCCESS The readiness check test detected no issues. No action required.
Here is a sample Readiness Report file. Your report may not include all of these checks. 
This readiness check report was created on Wed Dec 02 05:47:33 PST 2020 Log file is located at: 
/oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2020-12-02-05-35-03AM.log
Readiness Check Report File: 
/oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2020-12-02-05-47-33AM.txt
Domain Directory: 
/oracle/work/middleware_1212/user_projects/domains/oim_domain

Starting readiness check of components.

Oracle Platform Security Services
    Starting readiness check of Oracle Platform Security Services.
      Schema User Name: DEV_OPSS
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_OPSS is currently at version 11.1.1.9.0. 
Readiness checks will now be performed.
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
    Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
    Starting schema test:  Test that the schema does not contain any unexpected tables  TEST_UNEXPECTED_TABLES
    Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
    Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
    Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
    Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
    Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
    Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
    Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
    Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
    Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
    Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
    Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
    Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
    Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
    Starting datatype test for table CT_29: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
    Completed datatype test for table CT_29: TEST_COLUMN_DATATYPES_V2 
--> Test that all table columns have the proper datatypes +++ PASS
    Starting index test for table JPS_ENTITY_LOCK: TEST_REQUIRED_INDEXES 
--> Test that the table contains all the required indexes
    Completed index test for table JPS_ENTITY_LOCK: 
TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting index test for table CT_9_3:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
    Completed index test for table CT_9_3: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
    Starting schema test:  UPGRADE_SCRIPT_TEST  Test that the middleware contains the required Oracle Platform Security Services upgrade script
    Completed schema test: UPGRADE_SCRIPT_TEST --> Test that the middleware contains the required Oracle Platform Security Services upgrade script +++ PASS
    Starting schema test:  PRIVILEGES_TEST  Test that the Oracle Platform Security Services schema has appropriate system privileges
    Completed schema test: PRIVILEGES_TEST --> Test that the Oracle Platform Security Services schema has appropriate system privileges +++ PASS
    Starting schema test:  SEQUENCE_TEST  Test that the Oracle Platform Security Services schema sequence and its properties are valid
    Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid 
+++ PASS
    Finished readiness check of Oracle Platform Security Services with
status: SUCCESS.

Oracle Metadata Services
    Starting readiness check of Oracle Metadata Services.
      Schema User Name: DEV_MDS
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_MDS is currently at version 11.1.1.9.0. 
Readiness checks will now be performed.
    Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
    Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
    Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
    Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ PASS
    Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
    Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
    Starting index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES 
--> Test that the table contains all the required indexes
    Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
    Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
    Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
    Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Finished readiness check of Oracle Metadata Services with status: 
SUCCESS.

User Messaging Service
    Starting readiness check of User Messaging Service.
      Schema User Name: DEV_ORASDPM
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_ORASDPM is currently at version 11.1.1.9.0. Readiness checks will now be performed.
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Starting column test for table RULE_SET: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns
    Completed column test for table RULE_SET: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Starting column test for table STATUS: TEST_UNEXPECTED_TABLE_COLUMNS 
--> Test that the table does not contain any unexpected columns
    Completed column test for table STATUS: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Starting column test for table STATUS_ORPHAN: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns
    Completed column test for table STATUS_ORPHAN: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Starting column test for table USER_DEVICE: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns
    Completed column test for table USER_DEVICE: 
TEST_UNEXPECTED_TABLE_COLUMNS --> Test that the table does not contain any unexpected columns +++ PASS
    Finished readiness check of User Messaging Service with status: SUCCESS.

Oracle SOA
    Starting readiness check of Oracle SOA.
      Schema User Name: DEV_SOAINFRA
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
      VERSION Schema DEV_SOAINFRA is currently at version 11.1.1.9.0. Readiness checks will now be performed.
    Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
      INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
    Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
    Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
    Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
    Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ PASS
    Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
    Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
    Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
    Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
    Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
    Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
    Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
    Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
    Starting schema test:  SOA_TABLESPACE_VALIDATION  Test SOAINFRA schema for enough default table space and temp table space.
    Completed schema test: SOA_TABLESPACE_VALIDATION --> Test SOAINFRA schema for enough default table space and temp table space. +++ PASS
    Starting schema test:  SOA_INSTANCE_VALIDATION  Test SOAINFRA schema for inconsistencies of instance data.
    Completed schema test: SOA_INSTANCE_VALIDATION --> Test SOAINFRA schema for inconsistencies of instance data. +++ PASS
    Finished readiness check of Oracle SOA with status: SUCCESS.

Oracle Identity Manager
    Starting readiness check of Oracle Identity Manager.
      Schema User Name: DEV_OIM
      Database Type: Oracle Database
      Database Connect String: example.oracle.com:1521:oimdb
    Starting schema test:  examine  Calling examine method
      INFO Examine is successful
    Completed schema test: Examine --> Testing schema version +++ PASS
    Starting schema test:  TEST_MDS_BACKUP  Taking backup of MDS data related to OIM to handle any unseen situation during upgrade.
      INFO MDSBackup passes. Backup of MDS data related to OIM is here: 
/oracle/work/middleware_latest/oracle_common/upgrade/temp/mdsBackup/
    Completed schema test: TEST_MDS_BACKUP --> Taking backup of MDS data related to OIM to handle any unseen situration during upgrade. +++ PASS
    Finished readiness check of Oracle Identity Manager with status: 
SUCCESS.

User Messaging Service
    Starting readiness check of User Messaging Service.
    Starting config test:  TEST_USERMESSAGINGCONFIG  Test that configuration file usermessagingconfig.xml is accessible, in place and valid.
    Completed config test: TEST_USERMESSAGINGCONFIG --> Configuration file usermessagingconfig.xml is accessible, in place and valid. +++ PASS
    Starting config test:  TEST_ALREADY_UPGRADED  Test that configuration is not already upgraded.
    Completed config test: TEST_ALREADY_UPGRADED --> Configuration is not already upgraded. +++ PASS
    Finished readiness check of User Messaging Service with status: SUCCESS.

Oracle Identity Manager
    Starting readiness check of Oracle Identity Manager.
      INFO There are no configuration readiness tests for Oracle Identity Manager.
    Finished readiness check of Oracle Identity Manager with status: 
SUCCESS.

Oracle JRF
    Starting readiness check of Oracle JRF.
    Finished readiness check of Oracle JRF with status: SUCCESS.

System Components Infrastructure
    Starting readiness check of System Components Infrastructure.
    Starting config test:  TEST_SOURCE_CONFIG  Checking the source configuration.
      INFO
/oracle/work/middleware_1212/user_projects/oim_domain/opmn/topology.xml
was not found. No upgrade is needed.
    Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
    Finished readiness check of System Components Infrastructure with
status: ALREADY_UPGRADED.

Common Infrastructure Services
    Starting readiness check of Common Infrastructure Services.
    Starting config test:  CIEConfigPlugin.readiness.test  This tests the readiness of the domain from CIE side.
    Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
    Finished readiness check of Common Infrastructure Services with
status: SUCCESS.

Oracle Web Services Manager
    Starting readiness check of Oracle Web Services Manager.
    Completed config test: BOOTSTRAP_PROPERTIES_CHECK --> Bootstrap properties check +++ PASS
    Completed config test: CONFIGURATION_PROPERTIES_CHECK --> Configuration properties check +++ PASS
    Completed config test: TOKEN_TRUST_PROPERTIES_CHECK --> Trust issuer properties check +++ PASS
    Completed config test: MDS_REPOSITORY_CONNECTIVITY_CHECK --> MDS repository connectivity check +++ PASS
    Finished readiness check of Oracle Web Services Manager with status: 
SUCCESS.

Finished readiness check of components.

Note:

You can ignore the missing index error in the readiness report. This is a known issue. The corresponding missing index is added during the schema upgrade operation. This error does not occur if the schema to be upgraded was created in 12c using the RCU.

Parent topic: Running a Pre-Upgrade Readiness Check

Copying the oracle.iam.ui.custom-dev-starter-pack.war from the 11g Middleware Home

You have to manually copy the oracle.iam.ui.custom-dev-starter-pack.war file from the <11g Release 2_MW_HOME>/Oracle_IDM1/server/apps folder to the <12c (12.2.1.4)_ORACLE_HOME>/idm/server/apps folder.

You have to copy this file on each OIMHOST.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Stopping Servers and Processes

Before you run the Upgrade Assistant to upgrade the schemas, you must shut down all the processes and servers in the 11g OIG domain, including the Administration Server, Node Manager (if you have configured Node Manager), and all Managed Servers.

Note:

Ensure that the 11g server database is up and running during the upgrade process.

For instructions to shut down the servers, see Starting and Stopping Servers.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Upgrading Product Schemas

After stopping servers and processes, use the Upgrade Assistant to upgrade supported product schemas to the current release of Oracle Fusion Middleware.

The Upgrade Assistant allows you to upgrade individually selected schemas or all schemas associated with a domain. The option you select determines which Upgrade Assistant screens you will use.

Note:

  • At this point, downtime starts for the 11g setup. You can also make a copy of the 11g OIG database and use that to complete the rest of the steps. Making a copy keeps the 11g setup completely intact and enables you to easily roll back to 11g (11.1.2.3) if the upgrade to 12c (12.2.1.4) fails.
  • High waits and performance degradation may be seen due to 'library cache lock' (cycle)<='library cache lock' for DataPump Worker (DW) processes in the 12.2 RAC environment. To resolve this issue, you should disable S-Optimization by using the following command:
    ALTER SYSTEM SET "_lm_share_lock_opt"=FALSE SCOPE=SPFILE SID='*';
    After running the above command, restart all the RAC instances. After the upgrade is complete, you can reset the parameter by using the following command:
    alter system reset "_lm_share_lock_opt" scope=spfile sid='*';

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Identifying Existing Schemas Available for Upgrade

This optional task enables you to review the list of available schemas before you begin the upgrade, by querying the schema version registry. The registry contains schema information such as version number, component name and ID, date of creation and modification, and custom prefix.

You can let the Upgrade Assistant upgrade all of the schemas in the domain, or you can select individual schemas to upgrade. To help decide, follow these steps to view a list of all the schemas that are available for an upgrade:

  1. If you are using an Oracle database, connect to the database by using an account that has Oracle DBA privileges, and run the following from SQL*Plus:

    SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID;

  2. Examine the report that is generated.

    If an upgrade is not needed for a schema, the schema_version_registry table retains the schema at its pre-upgrade version.

Notes:

  • If your existing schemas are not from a supported version, then you must upgrade them to a supported version before using the 12c (12.2.1.4.0) upgrade procedures. Refer to your pre-upgrade version documentation for more information.

  • If you used an OID-based policy store in the earlier versions, make sure to create a new OPSS schema before you perform the upgrade. After the upgrade, the OPSS schema remains an LDAP-based store.

  • You can only upgrade schemas for products that are available for upgrade in Oracle Fusion Middleware release 12c (12.2.1.4.0). Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 12c (12.2.1.4.0).

Example 8-1 Sample Output of the Query

MRC_NAME COMP_ID OWNER VERSION STATUS UPGRADED
DEV BIPLATFORM DEV_BIPLATFORM 11.1.1.9.0 VALID N
DEV MDS DEV_MDS 11.1.1.9.0 VALID N
DEV OIM DEV_OIM 11.1.2.3.0 VALID N
DEV OPSS DEV_OPSS 11.1.1.9.0 VALID N
DEV ORASDPM DEV_ORASPDM 11.1.1.9.0 VALID N
DEV SOAINFRA DEV_SOAINFRA 11.1.1.9.0 VALID N

Parent topic: Upgrading Product Schemas

Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas to 12c (12.2.1.4.0). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user.

Note:

The Upgrade Assistant is invoked from the 12c (12.2.1.4) Oracle Home but all the parameters that are provided at run time point to the 11g schema and domain home.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, ensure that the JVM character encoding is set to UTF-8 for the platform on which the Upgrade Assistant is running. If the character encoding is not set to UTF-8, you will not be able to download files that contain the Unicode characters in their names. This can cause the upgrade to fail.

To ensure that UTF-8 is used by the JVM, use the JVM option -Dfile.encoding=UTF-8.

  1. Go to the oracle_common/upgrade/bin directory.
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin

      Note:

      In the above command, ORACLE_HOME refers to the 12c (12.2.1.4.0) Oracle Home.
  2. Set a parameter for the Upgrade Assistant to include the JVM encoding requirement:
    • (UNIX) export UA_PROPERTIES="-Dfile.encoding=UTF-8"
    • (Windows) set UA_PROPERTIES="-Dfile.encoding=UTF-8"
  3. Start the Upgrade Assistant:
    • (UNIX) ./ua
    • (Windows) ua.bat

For information about other parameters that you can specify on the command line, such as logging parameters, see Upgrade Assistant Parameters.

Parent topic: Upgrading Product Schemas

Upgrading Oracle Identity Manager Schemas Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade the product schemas.

Note:

  • If the pre-upgrade environment has Audit schema (IAU), you must first upgrade Audit schema only, using the Individually Selected Schema option on the Selected Schemas screen, and selecting Oracle Audit Services schema. Ensure that you select the appropriate IAU schema from the list of available IAU schemas. The upgrade assistant will not detect the corresponding IAU schema from the provided domain directory automatically. Hence, you must select it manually. Once the IAU schema is upgraded, run the Upgrade Assistant again to upgrade the remaining schemas using the All Schema Used by a domain option on the Selected Schemas screen.
  • If there is no Audit schema (IAU) in your pre-upgrade environment, use the All Schema Used by a Domain option on the Selected Schemas screen and proceed.
  • To check whether the pre-upgrade environment has the IAU schema, run the following SQL command using the user with sysdba privileges:
    select username from dba_users where username like '%IAU%';
    This command lists the IAU schemas available in your configured database.
To upgrade product schemas with the Upgrade Assistant:
  1. On the Welcome screen, review an introduction to the Upgrade Assistant and information about important pre-upgrade tasks. Click Next.

    Note:

    For more information about any Upgrade Assistant screen, click Help on the screen.
  2. On the Upgrade Type screen, select the schema upgrade operation that you want to perform:

    Note:

    For a one-hop upgrade process, Oracle recommends you to use the ‘All Schemas Used by a Domain’ option to ensure that all the required schemas are included in the upgrade.

    Selecting the All Schemas Used by a Domain option enables the Upgrade Assistant to discover and select all components that have a schema available to upgrade in the domain specified in the Domain Directory field. This is also known as a domain assisted schema upgrade. Additionally, the Upgrade Assistant pre-populates connection information on the schema input screens.

  3. In the Domain Directory field, select the 11g domain folder that was copied to the 12c (12.2.1.4) setup machine in step 3 of Installing Oracle Identity Manager 12c (12.2.1.4) and the Required Patches. If the 12c (12.2.1.4) setup is on the same machine as the 11g Release 2 setup, provide the 11g domain home location during the schema upgrade process.

    Click Next.

  4. The Component List screen displays the list of components whose schema will be upgraded, and the list of components for which new schemas, required for the 11g upgrade, will be created.

    Click Next.

  5. On the Prerequisites screen, acknowledge that the prerequisites have been met by selecting all the check boxes. Click Next.

    Note:

    The Upgrade Assistant does not verify whether the prerequisites have been met.
  6. On the Schema Credentials screen, specify the database credentials to connect to the selected 11g (11.1.2.3) schema: Database Type, DBA User Name, and DBA Password. As part of the pre-upgrade requirements, you had created the required user, see Creating a Non-SYSDBA User to Run the Upgrade Assistant.

    Then click Connect.

    Note:

    Oracle database is the default database type. Make sure that you select the correct database type before you continue. If you discover that you selected the wrong database type, do not go back to this screen to change it to the correct type. Instead, close the Upgrade Assistant and restart the schema upgrade with the correct database type selected to ensure that the correct database type is applied to all schemas.

    Select the Schema User Name option and specify the Schema Password.

    Note:

    The Upgrade Assistant automatically enables the default credentials. If you are unable to connect, ensure that you manually enter the credentials for your schema before you continue.

    Click Next until all schema connections are validated (the screen name changes based on the schema selected).

    Note:

    If you encounter any connection failure, check the cause and fix it.
  7. In the Create Schemas screen, enter the passwords for the new schemas to be created. Select the appropriate option and enter the passwords. If you want to use the same password for all schemas, select Use same passwords for all schemas and enter the password.

    Click Next.

  8. In Create Schemas Defaults screen, review the details and click Next.
  9. On the Examine screen, review the status of the Upgrade Assistant as it examines each schema, verifying that the schema is ready for upgrade. If the status is Examine finished, click Next.
    If the examine phase fails, Oracle recommends that you cancel the upgrade by clicking No in the Examination Failure dialog. Click View Log to see what caused the error and refer to Troubleshooting Your Upgrade in Upgrading with the Upgrade Assistant for information on resolving common upgrade errors.

    Note:

    • If you resolve any issues detected during the examine phase without proceeding with the upgrade, you can start the Upgrade Assistant again without restoring from backup. However, if you proceed by clicking Yes in the Examination Failure dialog box, you need to restore your pre-upgrade environment from backup before starting the Upgrade Assistant again.

    • Canceling the examination process has no effect on the schemas or configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

  10. On the Upgrade Summary screen, review the summary of the schemas that will be upgraded and/or created.

    Verify that the correct Source and Target Versions are listed for each schema you intend to upgrade.

    If you want to save these options to a response file to run the Upgrade Assistant again later in response (or silent) mode, click Save Response File and provide the location and name of the response file. A silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again.

    Click Next.

  11. In the Create Schema Progress screen, the required schemas get created and summary is displayed. Review the summary and ensure there are no errors.

    Click Upgrade to start the upgrade process.

  12. On the Upgrade Progress screen, monitor the status of the upgrade.

    Caution:

    Allow the Upgrade Assistant enough time to perform the upgrade. Do not cancel the upgrade operation unless absolutely necessary. Doing so may result in an unstable environment.
    If any schemas are not upgraded successfully, refer to the Upgrade Assistant log files for more information.

    Note:

    The progress bar on this screen displays the progress of the current upgrade procedure. It does not indicate the time remaining for the upgrade.

    Click Next.

  13. After the upgrade completes successfully, the Upgrade Assistant provides the upgrade status and lists the next steps to take in the upgrade process. You should review the Upgrade Success screen of the Upgrade Assistant to determine the next steps based on the information provided. The wizard shows the following information:
    Upgrade Succeeded.

Log File: /u01/oracle/products/12c/identity/oracle_common/upgrade/logs/ua2020-09-15-18-27-29PM.txt
Post Upgrade Text file: /u01/oracle/products/12c/identity/oracle_common/upgrade/logs/postupgrade2020-09-15-18-27-29PM.txt
Next Steps

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
   Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.

    Click Close to complete the upgrade and close the wizard.

    If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at ORACLE_HOME/oracle_common/upgrade/logs.

    Note:

    If the upgrade fails, you must restore your pre-upgrade environment from backup, fix the issues, then restart the Upgrade Assistant.

Parent topic: Upgrading Product Schemas

Verifying the Schema Upgrade

After completing all the upgrade steps, verify that the upgrade was successful by checking that the schema version in schema_version_registry has been properly updated.

If you are using an Oracle database, connect to the database as a user having Oracle DBA privileges, and run the following from SQL*Plus to get the current version numbers: 

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

In the query result:

  • Check that the number in the VERSION column matches the latest version number for that schema. For example, verify that the schema version number is 12.2.1.4.0.

    Note:

    However, that not all schema versions will be updated. Some schemas do not require an upgrade to this release and will retain their pre-upgrade version number.

  • The STATUS field will be either UPGRADING or UPGRADED during the schema patching operation, and will become VALID when the operation is completed.

  • If the status appears as INVALID, the schema update failed. You should examine the logs files to determine the reason for the failure.

  • Synonym objects owned by IAU_APPEND and IAU_VIEWER will appear as INVALID, but that does not indicate a failure.

    They become invalid because the target object changes after the creation of the synonym. The synonyms objects will become valid when they are accessed. You can safely ignore these INVALID objects.

Note:

Undo or remove any non-SYSDBA user role that you created when preparing for the upgrade.

Example 8-2 Sample Output of the Query

MRC_NAME COMP_ID OWNER VERSION STATUS UPGRADED
DEV BIPLATFORM DEV_BIPLATFORM 11.1.1.9.0 VALID N
DEV IAU DEV_IAU 12.2.1.2.0 VALID N
DEV IAU_APPEND DEV_IAU_APPEND 12.2.1.2.0 VALID N
DEV IAU_VIEWER DEV_IAU_VIEWER 12.2.1.2.0 VALID N
DEV MDS DEV_MDS 12.2.1.3.0 VALID Y
DEV OIM DEV_OIM 12.2.1.4.0 VALID Y
DEV OPSS DEV_OPSS 12.2.1.0.0 VALID Y
DEV SOAINFRA DEV_SOAINFRA 12.2.1.4.0 VALID Y
DEV STB DEV_STB 12.2.1.3.0 VALID N
DEV UCSUMS DEV_ORASDPM 12.2.1.0.0 VALID Y
DEV WLS DEV_WLS 12.2.1.0.0 VALID N

Parent topic: Upgrading Product Schemas

Cleaning the Temporary Folder

Before starting the updgrade process, clean the /tmp folder on all the Oracle Identity Governance 12c (12.2.1.4) machine(s).

As the /tmp directory is set against the JVM java.io.tmpdir property, any unwanted files in the /tmp folder can interfere with the OIG upgrade process and may result is MDS corruption.

For example, on Linux machines, you can run rm -rf /tmp/* as the user who has installed OIG.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Rewiring the Domain

When you execute the oneHopUpgrade.sh script, it wires the upgraded schemas of the OIM 11g (11.1.2.3.0) setup with the newly installed domain and Oracle Home of the OIM 12c (12.2.1.4) setup.

To enable the wiring, you have to provide the required values of both the setups [11g (11.1.2.3.0) and 12c (12.2.1.4)] in the oneHop.properties file. During runtime, the script will ask for the required passwords.

To wire the ugraded schemas:

  1. Stop the OIM, SOA Managed Servers, and Node Manager running on all the nodes of the 12c (12.2.1.4) domain. Ensure that only Database and Administrator server are up and running. At this stage, the reference is to the 11g (11.1.2.3) database that is now upgraded to 12c (12.2.1.4).
  2. Navigate to the <12c (12.2.1.4)_ORACLE_HOME>/idm/server/upgrade/oneHopUpgrade location.
  3. Fill the values for the various properties in the oneHop.properties file.

    Table 8-6 List of properties in the oneHop.properties File

    Sl. No. Property Name Description Sample Value

    1

    domain_home

    The newly installed 12c (12.2.1.4) WebLogic Domain Home location.

    /u01/mw_12cps4/user_projects/domains/oim_domain

    2

    admin_server_host

    The host name of the newly installed 12c (12.2.1.4) WebLogic domain’s Administration server.

    example.com

    3

    admin_server_port

    The port number of the newly installed 12c (12.2.1.4) WebLogic domain’s Administration server.

    7001

    4

    admin_server_user

    The username of the newly installed 12c (12.2.1.4) WebLogic domain’s Administrator.

    weblogic

    5

    ORACLE_HOME

    The newly installed 12c (12.2.1.4) Oracle Home location.

    /u01/mw_12cps4

    6

    JAVA_HOME

    Java 8 home.

    /u01/java/1.8.0-211-12-190401.1.8.0.211.12/jdk1.8.0_211

    7

    12csp4_opss_data_source_name

    Name of a new OPSS data source which will be created as part of the domain wiring step and value is populated OOTB.

    Note: This data source will be used for OPSS DB connections after the one-hop upgrade process.

    OPSSDataSourceUpgrade

    8

    12csp4_opss_jndi_name

    JNDI Name of a new OPSS data source which will be created as part of domain wiring step and value is populate OOTB.

    jdbc/OpssDSUpgrade

    9

    DATASOURCES1

    Username of the upgraded 11g (11.1.2.3.0) OIM schema to 12c (12.2.1.4).

    Note: Customer should not change the name of the data source populated OOTB for all the data source properties. For example: ApplicationDB, EDNLocalTxDataSource, WLSSchemaDataSource, and so on.

    DATASOURCES1 = name:ApplicationDB

    user: DEV_OIM

    10

    DATASOURCES2

    Username of the upgraded 11g (11.1.2.3.0) SOAINFRA schema to 12c (12.2.1.4).

    DATASOURCES2 = name:EDNLocalTxDataSource

    user: DEV_SOAINFRA

    11

    DATASOURCES3

    Username of the upgraded 11g (11.1.2.3.0) MDS schema to 12c (12.2.1.4).

    DATASOURCES3 = name:mds-oim

    user: DEV_MDS

    12

    DATASOURCES4

    Username of the upgraded 11g (11.1.2.3.0) OPSS schema to 12c (12.2.1.4).

    DATASOURCES4 = name:opss-data-source

    user: DEV_OPSS

    13

    DATASOURCES5

    Username of the newly created STB schema during the schema upgrade to 12c (12.2.1.4).

    DATASOURCES5 = name:LocalSvcTblDataSource

    user: DEV_STB

    14

    DATASOURCES6

    Username of the newly created IAU_APPEND schema during the schema upgrade to 12c (12.2.1.4).

    DATASOURCES6 = name:opss-audit-DBDS

    user: DEV_IAU_APPEND

    15

    DATASOURCES7

    Username of the newly created WLS schema during the schema upgrade to 12c (12.2.1.4).

    DATASOURCES7 = name:WLSSchemaDataSource

    user: DEV_WLS

    16

    DATASOURCES8

    Username of the newly created IAU_VIEWER schema during the schema upgrade to 12c (12.2.1.4).

    DATASOURCES8 = name:opss-audit-viewDS

    user: DEV_IAU_VIEWER

    17

    DATASOURCES9

    Username of the upgraded 11g (11.1.2.3.0) ORASDPM schema to 12c (12.2.1.4).

    DATASOURCES9 = name:OraSDPMDataSource

    user: DEV_ORASDPM

    18

    11gr2ps3_files_path_with_rw_permission

    The location for the 11g (11.1.2.3.0) OPSS schema's exported encryption key files from the 11g (11.1.2.3.0) setup, that is, files ewallet.p12 and ewallet.p12.lck.

    This location should also include the <11g_(11.1.2.3_DOMAIN_HOME>/config/fmwconfig/.xldatabasekey file.

    This location should have read-write permissions.

    /u01/onehop/files_from_11g

    19

    11gr2sp3_db_url

    JDBC URL of the upgraded 11g (11.1.2.3.0) DB schemas to 12c (12.2.1.4).

    jdbc:oracle:thin:@example11g.com:1521:oimdb

    20

    11g_OPSS_domain_farm_name

    This value is present in the <11g_(11.1.2.3.0)_DOMAIN_HOME>/config/fmwconfig/jps-config.xml file under <propertySet name="props.db.1"> as the value of the oracle.security.jps.farm.name property. For example, if the value of this property is cn=IAM, then the OPSS domain is IAM.

    IAM

    21

    11g_OPSS_jpsroot

    This is the OPSS LDAP root user of the 11g (11.1.2.3.0) setup's domain.

    This value is present in the <11g_(11.1.2.3.0)_DOMAIN_HOME>/config/fmwconfig/jps-config.xml file under <propertySet name="props.db.1"> as the value of the oracle.security.jps.ldap.root.name property. For example, if the value of this property is cn=jpsroot, the OPSS LDAP root user will be cn=jpsroot.

    cn=jpsroot

    22

    noOfRetries_for_admin_server_ping

    This property represents the number of times the domain rewiring utility will try to ping the 12c (12.2.1.4) domain’s Administration server during the restart phase. If you comment this property as "OOTB", it uses the default value of 10.

    To increase the value, uncomment the property.

    10

    23

    waitTime_to_stop_admin_server_inMinutes

    This property represents the time in minutes for which the domain rewiring utility will wait for the 12c (12.2.1.4) domain’s Administration server to stop after issuing the stop command. OOTB value is 5 minutes.

    5
  4. Invoke the oneHopUpgrade.sh script from the same directory location.
  5. At runtime, provide the following passwords:
    • A password and confirm password for new wallet creation.

      Note:

      You can provide the wallet password using the -p option also while invoking the oneHopUpgrade.sh script.

      For example:
      sh oneHopUpgrade.sh -p <WALLET_PWD>

      If you provide the wallet password using the -p option, you will not be asked for the wallet 'Password' and 'Confirm Password' during runtime. However, this option is not secure because it displays the confidential information such as wallet password in plain text. Therefore, Oracle recommends that you provide the wallet password during runtime when asked.

    • The WebLogic admin credentials of 12c (12.2.1.4) setup.
    • The passwords for all the upgraded schemas such as OIM, SOAINFRA, UMS, MDS, OPSS, STB, WLS, IAU_VIEWER, IAU_APPEND, and so on.
    • The keystore and key passwords for .xldatabasekey of the 11g (11.1.2.3) setup and .xldatabasekey of the 12c (12.2.1.4) setup.
    • The password (YOUR_OWN_PASSWORD_OF_EXPORTED_KEY) that was used to export the OPSS encryption key on the 11g (11.1.2.3) setup.
    The log files will be created with timestamp, in the <11gr2ps3_files_path_with_rw_permission>/logs location specified in the oneHop.properties file. This location will also contain the following files:
    • data/TaskDetails.csv file which stores the status of each sub-step of the domain wiring process for re-entrant purposes.
    • data/oneHopUpgradeResponse.prop file, which stores all the static inputs/data required to run the domain rewiring utility again. The utility is run in either the same environment after restoration or on the setup which has exactly the same environment-specific values.
    • data/wallet/ewallet.p12 and data/wallet/ewallet.p12.lck wallet files, which store secure data such as passwords. The response file and wallet files are always used in pairs.

    Note:

    • In case of any failure in the domain rewiring process, depending on the nature of the failure, you can use one of the following options:
      • If you are able to resolve the issue without the need to restore the 12c (12.2.1.4) or the 11g setup, do not delete the logs folder created in the location passed through the <11gr2ps3_files_path_with_rw_permission> property of the oneHop.properties file. Reinvoke the oneHopUpgrade.sh script after resolving error.
      • If the failure requires you to restore the entire 12c (12.2.1.4) or the 11g setup, and execute the one-hop upgrade process again, you have to delete the logs/data/TaskDetails.csv file created in the location passed through the <11gr2ps3_files_path_with_rw_permission> property of the oneHop.properties file.

      Note:

      During a re-run of the domain wiring utility in either of the failure cases, the utility will ask for all the required passwords again.

      If a failure occurs after you provide all the required passwords while executing the domain rewiring utility, you can avoid entering all the required passwords again and instead use the response file and wallet files created during the first run. You can use these files only if the values in the oneHop.properties file and passwords are the same during the re-run (that is, all the setup details are the same as the first run when the error occurred). See Rewiring the Domain Using the Silent Mode.

    • The oneHopUpgrade.sh script uses the WLST commands internally to rewire the domain and prints the data on the console without parsing. Therefore, you can view the exact details of all exceptions in case errors are encountered during the process.

    After the successful execution of the above script, the 12c (12.2.1.4) domain is wired to the upgraded 11g schema. At this point, all the servers of 12c (12.2.1.4) domain are shut down.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Rewiring the Domain Using the Silent Mode

During the Rewiring the Domain step, when you run the oneHopUpgrade.sh script, it creates a response file (oneHopUpgradeResponse.prop in the <11gr2ps3_files_path_with_rw_permission>/logs/data location) and wallet files (ewallet.p12 and ewallet.p12.lck in the <111gr2ps3_files_path_with_rw_permission>/logs/data/wallet location).

After a successful run of the oneHopUpgrade.sh script, you can use the response file and the wallet files to silently invoke the domain re-wiring utility in the following scenarios:

  • You can have the test and production setups to be the exact replicas with the same passwords and environment-specific values. In such a scenario, you can use the response file and the wallet generated on the test setup, on the production setup during the one-hop upgrade process.
  • If any failure occurs during domain rewiring, resolve the error first. During the re-run, use the response file and wallet to invoke the oneHopUpgrade.sh script in the silent mode. If you use the response file and the existing wallets, the script will not ask for the passwords again.
Execute the following command to use the response file and wallet for rewiring the domain in the silent mode:
sh oneHopUpgrade.sh -f <Absolute_path_to_response_file_along_with_name> -p <WALLET_PASSWORD>
For example:
sh oneHopUpgrade.sh -f /u01/11g_data/logs/data/oneHopUpgradeResponse.prop -p <password>

If you do not provide the password for the existing wallet with the -p option, the oneHopUpgrade.sh script will ask for the password during runtime.

Note:

  • You should provide the same password for the existing wallet (available in the <11gr2ps3_files_path_with_rw_permission>/logs/data/wallet location), which was used to create the wallet during the first run.
  • Oracle recommends that you provide the existing wallet password during runtime. The password you provide with the -p option should be in plain text (not secure).
  • The location of the wallet files should be same on both the test and production setups.
  • The oneHop.properties file is not used during the silent invocation of the oneHopUpgrade.sh script. Therefore, any changes done in the oneHop.properties file will not be used in the silent mode.
  • You cannot make any changes to the response (oneHopUpgradeResponse.prop) file.
  • Access permissions on wallet location/directory (<11gr2ps3_files_path_with_rw_permission>/logs/data/wallet) and wallet files (ewallet.p12 and ewallet.p12.lck) are provided as per the Oracle security standards, that is, 750 on directory and 600 on files.

Parent topic: Rewiring the Domain

Restarting the Servers

After you upgrade Oracle Identity Manager, start the servers.

  1. Start the following 12c (12.2.1.4) domain servers:

    Note:

    After the upgrade, for first boot, start the SOA and OIG Managed Servers manually from the command line by using the startup script, as shown in the examples below.

    From the terminal navigate to the 12c (12.2.1.4)_DOMAIN_HOME/bin location.

    • Start the Administration Server.
      For example:
      ./startWebLogic.sh
    • After the Administration Server come to a running state, start the Oracle SOA Suite Managed Server with the Administration Server URL, and the BPM property set to TRUE.
      For example:
      ./startManagedWebLogic.sh <soa_managed_server_name> t3://weblogic_admin_host:weblogic_admin_port -Dbpm.enabled=true
    • After the SOA Server comes to a running state and the soa-infra application is in the ACTIVE status, start the Oracle Identity Manager Managed Server with the Administration Server URL.
      For example:
      ./startManagedWebLogic.sh <oim_managed_server_name> t3://weblogic_admin_host:weblogic_admin_port

    During the start of the OIM Managed Server, bootstrap is initiated. After a successful bootstrap, the OIM Managed Server shuts down automatically.

  2. Stop the SOA Managed server and the Administrator server manually after a successful bootstrap of OIM.
  3. Restart the following 12c (12.2.1.4) domain servers:
    • Administrator server
    • SOA Managed server without BPM property -Dbpm.enabled
    • OIM Managed server

One-hop upgrade to Oracle Identity Manager Release 12c (12.2.1.4) is complete.

To process the inflight requests after the one-hop upgrade, update the endpoint addresses in the SOA composites. See Updating the EndPoint Address in SOA Composites.

Restart all the servers on node 1, after updating the endpoint addresses.

Note:

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Invoking the MBean

You should invoke the integrateWithSOAServer operation of the oracle.iam:Location=<OIM_Managed_Server>,name=OIMSOAIntegrationMBean,type=IAMAppRuntimeMBean,Application=oim MBean from the Oracle Enterprise Manager (OEM) console.

Note:

To perform this step, the OIM Managed Server should be up and running on, at the least, one node in the cluster setup.
To invoke the MBean from the OEM console:
  1. Log in to the 12c (12.2.1.4) Oracle Enterprise Manager by using the following URL:

    http://<admin_HOST:ADMIN_SERVER_PORT>/em

  2. Navigate to WebLogic Domain, right-click DOMAIN_NAME, and select System MBean Browser.
  3. Under Application Defined MBeans, navigate to oracle.iam:Location=<OIM_Managed_server>,name=OIMSOAIntegrationMBean,type=IAMAppRuntimeMBean,Application=oim.
  4. From the Operations tab, click integrateWithSOAServer.
  5. Provide the value for each parameter in the list that appears, and then click Invoke.
You should provide the value for each of the following parameters to invoke MBean:
  • WebLogic Admin User Name
  • WebLogic Password
  • OIM Frontend URL
  • OIM External Frontend URL
  • SOA SOAP URL
  • SOA RMI URL
  • UMS Webservice URL

Table 8-7 Description of the parameters required to invoke the MBean

Name Description Type Sample Value

p1

WebLogic administrator user name.

java.lang.String

weblogic

p2

The password for the WebLogic administrator account.

java.lang.String

<password>

p3

OIM Frontend URL (internal load balancer URL, which is configured for all internal traffic in the company. For example: http://idm internal.mycompany.com).

java.lang.String

http://idm.internal.mycompany.com:80

p4

OIM External Frontend URL (external load balancer URL, which is configured for external access by all end users to access OIM self service. For example: https://sso.mycompany.com).

java.lang.String

https://sso.mycompany.com:443

p5

SOA SOAP URL (internal load balancer URL, which is configured for all internal traffic in the company. For example: https://soainternal.mycompany.com.).

java.lang.String

https://soainternal.mycompany.com:80

p6

SOA RMI URL (SOA T3 URL, which is configured for remote method invocation. For example: t3://soainternal.mycompany.com).

java.lang.String

cluster:t3://<SOA_cluster_name>

p7

UMS Webservice URL (UMS Webservice URL, which is configured for UMS email notifications. For example: http://soainternal.mycompany.com).

java.lang.String

https://soainternal.mycompany.com:80/ucs/messaging/webservice

Note:

This step is required to update the 11g (11.1.2.3.0) setup's URLs in the upgraded MDS schema to 12c (12.2.1.4) URLs.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Updating the EndPoint Address in SOA Composites

SOA composites have endpoint address URL for Web services. This URL can be a load balancer URL or a Web server URL. The type of URL depends on whether the application server is front-end with load balancer or Web server, or a single application server URL.

After the successful completion of the one-hop upgrade process, update this URL with the target system host values.

To update the endpoint address:

  1. Log in to the 12c (12.2.1.4) Oracle Enterprise Manager by using the following URL:
    http://ADMIN_SERVER:ADMIN_PORT/em

    Note:

    Use the same administration credentials that was created during the installation and configuration of OIM 12c (12.2.1.4).
  2. For a HA deployment, ensure that the SOA server is up and running. On the left pane, navigate to SOA, soa-infra(SOA_SERVER_NAME), and then the Deployed Composites tab. You will see the list of SOA composites.

    Note:

    There can be multiple active versions of a composite. These steps are applicable to all versions deployed for a composite. Steps differ for different composites but are same for versions of the same composite.
  3. Click the DefaultRequestApproval SOA composite.
  4. In the Services and References section, click the CallbackService_2 link for Usage Type Reference.
  5. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/workflowservice/CallbackService

    Note:

    • Provide the OHS server host and port values of the 12c (12.2.1.4) setup.
    • Oracle has performed the one-hop upgrade process by using a single Oracle HTTP Server (OHS) on top of the OIM nodes to access the OIM identity and sysadmin URLs using the OHS host and port. Therefore, the OHS host and port are provided in the endpoint URL. For example: http://<OHS_HOST>:<OHS_PORT>/workflowservice/CallbackService.

      If you are using a hierarchy of Oracle HTTP servers with a load balancer or web host on top to mitigate the single point of failure, then use the host and port of the exposed machine to access the OIM identity and sysadmin URLs.

  6. Return to the DefaultRequestApproval composite details page.
  7. In the Services and References section, click the RequestWSPartnerLink link for Usage Type Reference.
  8. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/workflowservice/RequestDataService
  9. Repeat steps 4 to 8 for the following SOA composites:
    • DefaultOperationalApproval
    • ProvideInformation
    • RoleLCMApproval

    Note:

    Repeat steps 4 to 8 for all versions of custom composites.
  10. Repeat steps 4 and 5 for the following SOA composites:
    • DefaultRoleApproval
    • AutoApproval
    • BeneficiaryManagerApproval
    • RequesterManagerApproval
    • DefaultSODApproval
  11. Return to the DefaultSODApproval composite details page.
  12. In the Services and References section, click the SodCheckServicePortImplService link for Usage Type Reference.
  13. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/workflowservice/SodCheckServicePortImplService
  14. Click the OAACGRoleAssignSODCheck SOA composite.
  15. In the Services and References section, click the RoleSODService link for Usage Type Reference.
  16. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/workflowservice/OAACGRoleSODService
  17. Click the IdentityAuditRemediation SOA composite.
  18. In the Services and References section, click the IdentityAuditWSPartnerLink link for Usage Type Reference.
  19. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/workflowservice/IdentityAuditCallbackService
  20. Click the DisconnectedProvisioning SOA composite.
  21. In the Services and References section, click the ProvisioningCallbackService link for Usage Type Reference.
  22. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/provisioning-callback/ProvisioningCallbackService
  23. Click the CertificationProcess SOA composite.
  24. In the Services and References section, click the CertificationWSPartnerLink link for Usage Type Reference.
  25. Click the Properties tab, add the following URL as the value for the Endpoint Address property (this property value will be empty OOTB), and then click Apply.
    http://<OHS_HOST>:<OHS_PORT>/workflowservice/CertificationCallbackService
  26. Repeat steps 24 and 25 for the CertificationOverseerProcess SOA composite.
  27. In Oracle Enterprise Manager Console, expand SOA Infrastructure, select SOA Administration, and then select Common Properties.
  28. In the Server URLs section, check the values for Callback Server URL and Server URL. If these values are blank, no action required. If these values are pointing to the OIM 11g (11.1.2.3.0) setup, update them to the corresponding values of the OIM 12c (12.2.1.4) setup.
  29. Restart all the servers on node 1 after you update the end point address.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Packing Domain Configurations on OIMHOST1

After completing the upgrade process on OIMHOST1, pack the domain on OIMHOST1. You must unpack it later on OIMHOST2.

To do this, complete the following steps:
  1. On OIMHOST1, run the following command from the location $ORACLE_HOME/oracle_common/common/bin to pack the upgraded domain:
    • On UNIX:

      sh pack.sh -domain=<Location_of_OIM_domain> -template=<Location_where_domain_configuration_jar_to_be_created> -template_name="OIM Domain" -managed=true

    • On Windows:

      pack.cmd -domain=<Location_of_OIM_domain> -template=<Location_where_domain_configuration_jar_to_be_created> -template_name="OIM Domain" -managed=true

  2. Copy the domain configuration jar file created by the pack command on OIMHOST1 to any accessible location.

Note:

If you are upgrading an enterprise deployment, you need to extract the configuration to the Managed Server directory. See Replicating the Domain Configurations on Each OIMHOST.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Replicating the Domain Configurations on Each OIMHOST

Replicate the domain configurations on OIMHOST2. This involves unpacking the upgraded domain on OIMHOST2, which was packed on OIMHOST1.

To do this, complete the following steps:
  1. Earlier in the procedure, you created a copy of the domain configuration jar file by using the pack command on OIMHOST1. See Packing Domain Configurations on OIMHOST1.
    Copy the domain configuration jar file created by the pack command on OIMHOST1 to any accessible location on OIMHOST2.
  2. On OIMHOST2, rename the existing domain home to <domain_home>_old.
  3. On OIMHOST2, run the following command from the location $ORACLE_HOME/oracle_common/common/bin to unpack the domain:
    • On UNIX:

      sh unpack.sh -domain=<Location_of_OIM_domain> -template=<location_of_domain_configuration_jar> -overwrite_domain=true

    • On Windows:

      unpack.cmd -domain=<Location_of_OIM_domain> -template=<location_of_domain_configuration_jar> -overwrite_domain=true

  4. If you have other OIMHOSTs, repeat step 2 through step 3 on those hosts.

Note:

If you are following the EDG methodology, you also need to pack and unpack the domain in the OIM managed server location on OIMHOST1.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Starting the Servers on all Nodes

After you upgrade Oracle Identity Manager on OIMHOST2, restart the servers on all the OIMHOST machines.

For instructions, see Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

For information about stopping the servers and processes, see Stopping Servers and Processes.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Installing and Integrating the Standalone Oracle BI Publisher

When you upgrade Oracle Identity Manager 11.1.2.3.0 to Oracle Identity Manager 12c (12.2.1.4.0), the embedded Oracle BI Publisher becomes unavailable in 12c (12.2.1.4). Therefore, you must install and integrate a new standalone Oracle BI Publisher 12c (12.2.1.4.0) after the upgrade, for configuring the Oracle Identity Governance reports.

For information about installing and configuring Oracle BI Publisher 12c (12.2.1.4.0), see Installing and Configuring Oracle BI Publisher in Developing and Customizing Applications for Oracle Identity Governance.

For information about integrating standalone Oracle BI Publisher with Oracle Identity Governance 12c (12.2.1.4.0), see Integrating Standalone BI Publisher with Oracle Identity Governance in Developing and Customizing Applications for Oracle Identity Governance.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Reinstalling the ADF DI Excel Plug-in

After you upgrade Oracle Identity Manager to 12c (12.2.1.4.0), uninstall and reinstall the ADF DI Excel plug-in, and then re-download the Excel.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Defining System Properties for Legacy Connectors

As part of post-upgrade tasks, for legacy connectors such as Resource Access Control Facility (RACF) that use the tcITResourceInstanceOperationsBean.getITResourceInstanceParameters method, you should create the following two system properties and update their values to True:
  • Service Account Encrypted Parameter Value
  • Service Account Parameters Value Store

For more information about these system properties, see Table 18-2 of section Non-Default System Properties in Oracle Identity Governance in Administering Oracle Identity Governance.

Oracle recommends creating these system properties only if a legacy connector or an old custom code requires the legacy behavior.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Increasing the Maximum Message Size for WebLogic Server Session Replication

Oracle recommends you to modify the Maximum Message Size from the default value of 10 MB to 100 MB. This value is used to replicate the session data across nodes.

You should perform this step for all the Managed servers and the Administration server.

  1. Log in to the WebLogic Server Administration Console.
  2. Navigate to Servers, select Protocols, and then click General.
  3. Set the value of Maximum Message Size to 100 MB.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments

Increasing the maxdepth Value in setDomainEnv.sh

The recommended value for the maxdepth parameter is 250. To update this value:
  1. Open the $DOMAIN_HOME/bin/setDomainEnv.sh file in a text editor.
  2. Locate the following code block:
    ALT_TYPES_DIR="${OIM_ORACLE_HOME}/server/loginmodule/wls,${OAM_ORACLE_HOME}/a
gent/modules/oracle.oam.wlsagent_11.1.1,${ALT_TYPES_DIR}"
export ALT_TYPES_DIR
CLASS_CACHE="true"
export CLASS_CACHE
  3. Add the following lines at the end of the above code block:
    JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.oif.serialFilter=maxdepth=250"
export JAVA_OPTIONS
  4. Save and close the setDomainEnv.sh file.

Parent topic: Upgrading Oracle Identity Manager Highly Available Environments