1. Upgrading Oracle Access Manager
  2. Pre-Upgrade Requirements

2 Pre-Upgrade Requirements

Before you begin to upgrade Oracle Access Manager 14c (14.1.2.1.0), you must perform pre-upgrade tasks such as backing up, creating a replica of your current environment, and verifying that your system meets certified requirements.

Oracle Fusion Middleware Pre-Upgrade Checklist

Perform the tasks in this checklist before you begin any upgrade to ensure you have a successful upgrade and limited downtime.

Upgrades are performed while the servers are down. This checklist identifies important and often time-consuming pre-upgrade tasks that you can perform before the upgrade to limit your downtime. The more preparation you do before you begin the upgrade process, the less time you will spend offline.

Note:

The pre-upgrade procedures you perform will depend on the configuration of your existing system, the components you are upgrading, and the environment you want to create at the end of the upgrade and configuration process. Complete only those tasks that apply to your configurations or use cases.

Ensure that Oracle Access Manager and Oracle Identity Manager are in different domains. If they are in the same domain, then you need to separate them into multiple domains. For more information, see Separating Oracle Identity Management Applications Into Multiple Domains.

Table 2-1 Tasks to Perform Before You Upgrade

Task Description

Required

Create a complete backup of your existing environment.

Back up all system-critical files, including the Oracle home, Middleware home, and databases that contain any schemas that are to be upgraded. If the upgrade fails, you must restore your pre-upgrade environment and begin the upgrade again.

See Creating a Complete Backup.

Required

Verify that you are installing and upgrading your product on a supported hardware and software configuration.

Caution: Do not attempt an upgrade if you are unable to use the latest supported operating system. As with all supported configurations, failure to comply with these requirements may cause your upgrade to fail.

Oracle recommends that you verify this information right before you start the upgrade as the certification requirements are frequently updated.

Note:

Make sure that you have applied the latest patches to your components before you upgrade. Review the Oracle Fusion Middleware Infrastructure release notes to see if there are any mandatory patches required for the software products that you are installing.

See Install and Configure in Release Notes for Oracle Fusion Middleware Infrastructure.

Verify that your hardware and software configurations (including operating systems) are supported by the latest certifications and requirements. Also make sure to use a supported JDK version before you install the product distributions.

Upgrade a component at a time, whether it is an Oracle Component or a dependent component. For example. Do not upgrade OUD, OIM, OAM, the operating system, the database, and the hardware all at the same time.

See Verifying Certification and System Requirements.

Optional

Create a Non-SYSDBA user to run the Upgrade Assistant.

Oracle recommends that you create the FMW user to run Upgrade Assistant. User FMW can run the Upgrade Assistant without system administration privileges.

See Creating a Non-SYSDBA User to Run the Upgrade Assistant

Optional

Review the list of available schemas.

Query the schema version registry to view schema information.

See Identifying Existing Schemas Available for Upgrade.

Required

Change the database user assigned to the WLSSchemaDataSource data source from <PREFIX>_WLS_RUNTIME to <PREFIX>_WLS.

If the database user for the WLSSchemaDataSource data source is assigned to <PREFIX>_WLS_RUNTIME, then you must change it to <PREFIX>_WLS

This step is required only if your existing domain has a WLSSchemaDataSource data source.

See Verify the Database User for the WLSSchemaDataSource Data Source

Required

If JAX-RS (2.2.22.4.0) is present in the existing WebLogic domain, you must remove it before upgrading to 14c (14.1.2.1.0).

See Remove the JAX-RS Deployment

Optional

Shut down all the local and remote Node Managers before starting the upgrade process.

See Shutting Down the Node Managers.

Parent topic: Pre-Upgrade Requirements

Creating a Complete Backup

Before you start an upgrade, back up all system-critical files, including the Oracle home, Domain home, and databases that host your Oracle Fusion Middleware schemas.

The backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table so that you can restore the contents back to its pre-upgrade state if the upgrade fails.

See:
  • Backing Up the Schema Version Registry Table
    Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table.
  • Maintaining Customized Domain and Environment Settings
    If you have modified any domain-generated, server startup scripts, or configuration files in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, and reconfiguration operations. Oracle recommends you to take a backup of the the customized files to a shared library location. In case of any failure or issues during the upgrade process, you can restore these files, if required.

Parent topic: Pre-Upgrade Requirements

Backing Up the Schema Version Registry Table

Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table.

Each Fusion Middleware schema has a row in the SYSTEM.SCHEMA_VERSION_REGISTRY$ table. If you run the Upgrade Assistant to update an existing schema and it does not succeed, you must restore the original schema before you can try again. Before you run the Upgrade Assistant, make sure you back up your existing database schemas and the schema version registry.

Note:

Before you upgrade a schema using the Upgrade Assistant, you must perform a complete database backup. During the upgrade, you are required to acknowledge that backups have been performed.

Parent topic: Creating a Complete Backup

Maintaining Customized Domain and Environment Settings

If you have modified any domain-generated, server startup scripts, or configuration files in your pre-upgrade environment, it is important to note that these changes are overwritten during the installation, and reconfiguration operations. Oracle recommends you to take a backup of the the customized files to a shared library location. In case of any failure or issues during the upgrade process, you can restore these files, if required.

Every domain installation includes dynamically-generated domain and server startup scripts, such as setDomainEnv. These files are replaced by newer versions during the installation and upgrade process.

For example, if you want to customize server startup parameters that apply to all servers in a domain, you can create a file called setUserOverrides.cmd (Windows) or setUserOverrides.sh (UNIX) and configure it to add custom libraries to the WebLogic Server classpath, specify additional command-line options for running the servers, or specify additional environment variables. When using the pack and unpack commands, any custom settings that you add to this file are preserved during the domain upgrade operation and are carried over to the remote servers.

The following example illustrates startup customizations in a setUserOverrides file:
# add custom libraries to the WebLogic Server system claspath
  if [ "${POST_CLASSPATH}" != "" ] ; then
    POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  else
    POST_CLASSPATH="${HOME}/foo/fooBar.jar"
    export POST_CLASSPATH
  fi
 
# specify additional java command-line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

If the setUserOverrides file exists during a server startup, the file is included in the startup sequence and any overrides contained within this file take effect. You must store the setUserOverrides file in the DOMAIN_HOME/bin directory.

Note:

If you are unable to create the setUserOverrides script before an upgrade, you need to reapply your settings as described in Re-apply Customizations to Startup Scripts in Upgrading Oracle WebLogic Server.

Parent topic: Creating a Complete Backup

Verifying Certification and System Requirements

Review the certification matrix and system requirements documents to verify that your environment meets the necessary requirements for installation. You may be required to upgrade your operating system, hardware or other software packages.

Note:

When checking the certification, system requirements, and interoperability information, be sure to check specifically for any operating system requirements. It is important for you to download software specifically designed for your operating system environment, explicitly.

WARNING:

Make sure that your current environment has been patched to the latest patch set before you begin the upgrade. Certifications are based on fully patched environments, unless stated otherwise.

See Install and Configure in Release Notes for Oracle Fusion Middleware Infrastructure.

Parent topic: Pre-Upgrade Requirements

Verify Your Environment Meets Certification Requirements

Oracle has tested and verified the performance of your product on all certified systems and environments. Make sure that you are installing your product on a supported hardware and software configuration.

Whenever new certifications occur, they are added to the appropriate certification document right away. New certifications can occur at any time, and for this reason the certification documents are kept outside of the documentation libraries and are available on Oracle Technical Resources. See the Certification Matrix for 14c (14.1.2.1.0). Under Oracle Fusion Middleware Certifications, open or save System Requirements and Supported Platforms for Oracle Fusion Middleware 14c (14.1.2.1.0) (xls) file, and then in the Menu tab, click the link for Identity and Access Management.

Note:

Check for any mandatory patches that are required before the installation. Review the Oracle Fusion Middleware Infrastructure release notes to see if there are any mandatory patches required for the software products that you are installing.

See Install and Configure in Release Notes for Oracle Fusion Middleware Infrastructure.

Parent topic: Verifying Certification and System Requirements

Verify System Requirements and Specifications

It is important to use both the System Requirements and Specifications document and the Oracle Fusion Middleware Certification Matrix to verify that the system requirements such as disk space, available memory, specific platform packages and patches, and other operating system-specific items are met.

Use the Oracle Fusion Middleware System Requirements and Specifications document to verify that the requirements of the Oracle Fusion Middleware Certification matrix are met. For example, if the Certification Matrix indicates that your product is certified for installation on 64-Bit Oracle Linux 8, the System Requirements and Specifications document should be used to verify that your Oracle Linux 8 system has met the required minimum specifications such as disk space, available memory, specific platform packages and patches, and other operating system-specific items. This document is updated as needed and resides outside of the documentation libraries on the Oracle Technology Network (OTN).

Note:

Do not attempt an upgrade if you are unable to meet the minimum system requirements.

Specifically, you can use the Oracle Fusion Middleware System Requirements and Specifications document to verify the following:
  • Processor Requirements
  • Java Development Kit (JDK) Requirements
  • General Memory and Disk Space Requirements
  • Product-Specific Memory and Disk Space Requirements
  • Network Requirements
  • UNIX Operating System Requirements
  • Windows Operating Systems Requirements
  • Virtualization Requirements
  • Database Requirements

What if my operating system is not supported?

If you are running your environment on an unsupported operating system, you will need to create a supported environment before you begin your upgrade. Do not attempt an upgrade on an unsupported operating system.

Use the migration steps for your environment.

Parent topic: Verifying Certification and System Requirements

Verify That the Database Hosting Oracle Fusion Middleware is Supported

You must have a supported Oracle database configured with the required schemas before you run Oracle Fusion Middleware 14c (14.1.2.1.0).

Review the Fusion Middleware database requirements before starting the upgrade to ensure that the database hosting Oracle Fusion Middleware is supported and has sufficient space to perform an upgrade. See the Certification Matrix for 14c (14.1.2.1.0).

Note:

If your database version is no longer supported, you must upgrade to a supported version before starting an upgrade.

Parent topic: Verifying Certification and System Requirements

Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware

If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK before you begin.

Refer to the Oracle Fusion Middleware Supported System Configurations information on the Oracle Technology Network (OTN) to verify that the JDK you are using is supported.

If your JDK is not supported, or you do not have a JDK installed, you must download the required Java SE JDK, from the following website:
http://www.oracle.com/technetwork/java/javase/downloads/index.html

Make sure that the JDK is installed outside of the Oracle home. The Oracle Universal Installer validates that the designated Oracle home directory is empty, and the install does not progress until an empty directory is specified. If you install JDK under Oracle home, you may experience issues in future operations. Therefore, Oracle recommends that you use install the JDK in the following directory: /home/oracle/products/jdk.

Parent topic: Verifying Certification and System Requirements

Creating a Non-SYSDBA User to Run the Upgrade Assistant

Oracle recommends that you create a non-SYSDBA user called FMW to run the Upgrade Assistant. This user has the privileges required to modify schemas, but does not have full administrator privileges.

SYSDBA is an administrative privilege that is required to perform high-level administrative operations such as creating, starting up, shutting down, backing up, or recovering the database. The SYSDBA system privilege is for a fully empowered database administrator. When you connect with the SYSDBA privilege, you connect with a default schema and not with the schema that is generally associated with your user name. For SYSDBA, this schema is SYS. Access to a default schema can be a very powerful privilege. For example, when you connect as user SYS, you have unlimited privileges on data dictionary tables. Therefore, Oracle recommends that you create a non-SYSDBA user to upgrade the schemas. The privileges listed below must be granted to user FMW before starting the Upgrade Assistant.

Notes:

The non-SYSDBA user FMW is created solely for the purpose of running the Upgrade Assistant. After this step is complete, drop the FMW user. Note that privileges required for running the Upgrade Assistant may change from release to release. 
By default, the v$xatrans$ table does not exist. You must run the XAVIEW.SQL script to create this table before creating the user. Moreover, the grant select privilege on the v$xatrans$ table is required only by Oracle Identity Governance . If you do not require Oracle Identity Governance for configuration, or if you do not have the v$xatrans$ table, then remove the following line from the script: 
   grant select on v$xatrans$ to FMW with grant option;
In the example below, <password> is the password that you set for the FMW user. When granting privileges, make sure that you specify your actual password.
create user FMW identified by <password>;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option; 
grant execute on SYS.DBMS_ASSERT to FMW with grant option;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

Parent topic: Pre-Upgrade Requirements

Identifying Existing Schemas Available for Upgrade

This optional step can be used before an upgrade to query the schema version registry table. This table contains schema information such as the schema owner, version number, component name and ID, date of creation and modification, and custom prefixes.

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 WHERE OWNER LIKE UPPER('<PREFIX>_%');

  2. Examine the report that is generated.

Notes:

  • After the upgrade you can generate the report again to see the updated versions of your schemas. If an upgrade was not needed for a schema, the schema_version_registry table retains the schema at its pre-upgrade version.

  • If your existing schemas are not from a supported version, then you must upgrade them to a supported version before using the 14c (14.1.2.1.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 14c (14.1.2.1.0). Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 14c (14.1.2.1.0).

Parent topic: Pre-Upgrade Requirements

Verify the Database User for the WLSSchemaDataSource Data Source

This step is required if your existing domain has a WLSSchemaDataSource data source.

If your domain has the WLSSchemaDataSource data source, then you will need to verify which database user is assigned to it. If <PREFIX>_WLS_RUNTIME is assigned to it, then you need to change that to <PREFIX>_WLS .

This change is necessary due to the following changes:
  • The 14c (14.1.2.1.0) Upgrade Assistant uses the information in the WLSSchemaDataSource data source,when a domain-based schema upgrade is performed. That upgrade will fail if the <PREFIX>_WLS database user is not assigned to the WLSSchemaDataSource, or if <PREFIX>_WLS is not entered as the "Schema User Name" on the "WLS Schema" page of the Upgrade Assistant.
  • Oracle recommends that you use the 12c Oracle WebLogic Administration Console to change the database user to <PREFIX>_WLS in the WLSSchemaDataSource data source. Doing this will avoid the Upgrade Assistant failure, and also allow the Reconfiguration Wizard to pre-populate fields with the correct values.
  • The <PREFIX>_WLS_RUNTIME database user is reserved for use with a new WLSRuntimeSchemaDataSource, which was introduced in 14c (14.1.2.1.0). This new WLSRuntimeSchemaDataSource will be created when the 14c (14.1.2.1.0) Reconfiguration Wizard (reconfig.sh) is used to upgrade the domain.
You can use your Oracle WebLogic 12c Administration Console to change the user in the WLSSchemaDataSource from <PREFIX>_WLS_RUNTIME to <PREFIX>_WLS.
  1. Log in the 12c (12.2.1.4.0) Administration Console.
  2. In the administration console under Domain Structure, expand Services (by clicking the + next to it). Then click Data Sources.
  3. If the user in Properties field contains <PREFIX>_WLS_RUNTIME, change it to <PREFIX>_WLS.
  4. Save the change.
  5. Use the Change Center to commit the change, if your domain is running in production mode.

Parent topic: Pre-Upgrade Requirements

Remove the JAX-RS Deployment

If JAX-RS (2.2.22.4.0) is present in the existing WebLogic domain, you must remove it before upgrading to 14c (14.1.2.1.0).

Use the 12c (12.2.1.4.0) WebLogic Administration Console to remove the deployment.

  1. Log in to the WebLogic Administration Console.
  2. Select Deployments.
  3. Locate the deployment called "jax-rs(2.2.22.4.0)"
  4. Select the checkbox next to the deployment and then Delete.

Parent topic: Pre-Upgrade Requirements

Ensuring that the Keystore Passwords are Same

Ensure that the passwords for .oamkeystore and default-keystore.jks are same for a successful upgrade.

To validate the keystore passwords, use the following keytool command: 
keytool -list -keystore $DOMAIN_HOME/config/fmwconfig/.oamkeystore -storepass
xxx -storetype jceks

keytool -list -keystore $DOMAIN_HOME/config/fmwconfig/default-keystore.jks
-storepass xxx -storetype jceks

If there is any mismatch between the keystore passwords, ensure that you correct the password for keystore-csf-key to be same as that of .oamkeystore, before starting the upgrade.

To change the password for keystore-csf-key:

  1. Log in to the EM console :
    http://host:port/em
  2. Navigate to WebLogic Domain, Security, and then Credentials.
  3. Locate oracle.wsm.security and expand it.
  4. Open the keystore-csf-key entry in the edit mode.
  5. Change the password to be the same as the password used for the .oamkeystore.
  6. Save the changes.

Parent topic: Pre-Upgrade Requirements

Shutting Down the Node Managers

Ensure that you have shut down all the local and remote Node Managers before starting the upgrade process.

The Node Managers should remain shut down until you start the WebLogic Administration Server after completing the upgrade. When the WebLogic Administration Server is up and running, start the Node Managers, followed by the Managed Servers.

Parent topic: Pre-Upgrade Requirements