2 Pre-Upgrade Requirements

Before you begin to upgrade Oracle Fusion Middleware Infrastructure 12c (12.2.1.3.0), you must perform pre-upgrade tasks such as backing up, cloning your current environment, and verifying that your system meets certified requirements.

• Pre-Upgrade Checklist
  The Pre-Upgrade Checklist identifies tasks that can be performed before you begin your upgrade to ensure you have a successful upgrade and limited downtime.
• Creating a Complete Backup
  Before you start an upgrade, back up all system-critical files, including the databases that host your Oracle Fusion Middleware schemas.
• Cloning Your Production Environment for Testing
  Create a copy of your actual production environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.
• Verifying Certification and System Requirements
  Review the certification matrix and system requirements documents to verify that your environment meets the necessary requirements for installation.
• Updating Policy Files when Using Enhanced Encryption (AES 256)
  If you plan to use enhanced encryption, such as Advanced Encryption Standard (AES) 256, in your upgraded environment, Oracle recommends that you apply the latest required policy files to the JDK before you upgrade.
• Purging Unused Data
  Purging unused data and maintaining a purging methodology before an upgrade can optimize the upgrade process.
• Creating an Edition on the Server for Edition-Based Redefinition
  Before upgrading an Edition-Based Redefinition (EBR) enabled schema, you must connect to the database server and create an edition on the database server for 12c (12.2.1.3.0).
• 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.
• Maintaining Your Custom setDomainEnv Settings
  Every domain includes dynamically generated domain and server startup scripts, such as setDomainEnv. Oracle recommends that you do not modify these startup scripts, as any changes you make to them will be overwritten during subsequent domain upgrade operations.
• Using No-Auth SSL Mode in OID Security Store
  The SSL protocol provides transport layer security with authenticity, integrity, and confidentiality, for a connection between a client and server. The SSL authentication mode is controlled by the attribute orclsslauthentication in the instance-specific configuration entry. By default, Oracle Internet Directory (OID) uses SSL No Authentication Mode (orclsslauthentication=1).
• Removing the Server Instance Scope from OWSM Policy Sets
  The Server Instance Scope in policy sets was not recommended in 11g (11.1.1.7.0) and is not supported in 12c. However, if you have policy sets that use the Server Instance Scope, they are disabled during the upgrade to 12c. Therefore, you must remove the Server Instance Scope from all the 11g policy sets before upgrading to 12c.
• Cloning Predefined Documents and Migrating OWSM Policy Attachments
  When upgrading, it is important to note that any predefined documents that have not been customized for your environment are replaced with read-only versions, and new, predefined, read-only documents are added. However, any existing predefined documents that have been customized and any user-created custom policies in the repository are not overwritten.

Cloning Your Production Environment for Testing

Create a copy of your actual production environment, upgrade the cloned environment, verify that the upgraded components work as expected, and then (and only then) upgrade your production environment.

Cloning your production environment for testing is recommended, but not required.

Upgrades cannot be reversed. In most cases, if an error occurs, you must stop the upgrade and restore the entire environment from backup and begin the upgrade process from the beginning. Identifying potential upgrade issues in a development environment can eliminate unnecessary downtime.

Note:

It is beyond the scope of this document to describe the cloning procedures for all components and operating systems. Cloning procedures are component and operating system-specific. At a high level, you install the pre-upgrade version of your component domain on a test machine, create the required schemas using the Repository Creation Utility (RCU), and perform the upgrade.

Additional benefits of running an upgrade in a cloned production environment include the following:

• Uncover and correct any upgrade issues.

• Practice completing an end-to-end upgrade.

• Understand the upgrade performance and how purge scripts can help.

• Understand the time required to complete the upgrade.

• Understand the database resource usage (such as temporary tablespace; PGA, and so on).

Note:

You can run the pre-upgrade Readiness Check on the cloned production environment to help identify potential upgrade issues with your data, but you must perform a complete test upgrade on a cloned environment to ensure a successful upgrade.

Maintaining Your Custom setDomainEnv Settings

Every domain includes dynamically generated domain and server startup scripts, such as setDomainEnv. Oracle recommends that you do not modify these startup scripts, as any changes you make to them will be overwritten during subsequent domain upgrade operations.

Caution:

Changes made to the setDomainEnv script - or any other startup script - before an upgrade are overwritten by the new, regenerated scripts during the domain reconfiguration process. Create a separate file to store your customized domain settings before you upgrade.

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 java command line options for running the servers, or specify additional environment variables, for instance. Any custom settings you add to this file are preserved during domain upgrade operation and are carried over to the remote servers when using the pack and unpack commands.

Following is an example of 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.

Using No-Auth SSL Mode in OID Security Store

The SSL protocol provides transport layer security with authenticity, integrity, and confidentiality, for a connection between a client and server. The SSL authentication mode is controlled by the attribute orclsslauthentication in the instance-specific configuration entry. By default, Oracle Internet Directory (OID) uses SSL No Authentication Mode (orclsslauthentication=1).

If you are upgrading to 12c Infrastructure, and using OID as the security policy store with Oracle WebLogic Server, then you may need to modify the default SSL mode. In Oracle Internet Directory 11g, SSL interoperability mode is enabled by default. But Oracle Internet Directory is fully compliant with the JDK's SSL, provided SSL interoperability mode is disabled.

The default use of No-Auth SSL mode in Oracle Internet Directory (OID) is discouraged for production environments due to the susceptibility to Man-in-the-Middle (MITM) attacks.

However, if No-Auth SSL is required, and WebLogic Server is the client, the following system properties must be applied to the weblogic.properties file before you upgrade:

• -Dweblogic.security.SSL.AllowAnonymousCipher=true

• -Dweblogic.security.SSL.ignoreHostnameVerification=true

Note:

Setting these properties can make the WebLogic Server susceptible to MITM attacks, since anonymous cipher suites are enabled, and the client connections are without Hostname Verification checking.

Oracle strongly recommends that you to use either server or client/server SSL authentication when using OID with WebLogic Server 12c.

Removing the Server Instance Scope from OWSM Policy Sets

The Server Instance Scope in policy sets was not recommended in 11g (11.1.1.7.0) and is not supported in 12c. However, if you have policy sets that use the Server Instance Scope, they are disabled during the upgrade to 12c. Therefore, you must remove the Server Instance Scope from all the 11g policy sets before upgrading to 12c.

For instructions, see Editing a Policy Set in Security and Administrator's Guide for Web Services in the Oracle Fusion Middleware 11g Release 1 (11.1.1.7.0) documentation library.

Cloning Predefined Documents and Migrating OWSM Policy Attachments

When upgrading, it is important to note that any predefined documents that have not been customized for your environment are replaced with read-only versions, and new, predefined, read-only documents are added. However, any existing predefined documents that have been customized and any user-created custom policies in the repository are not overwritten.

To ensure that you always get all of the latest policies, Oracle recommends that you clone any predefined documents that you have modified and migrate any policy attachments. For details, see Upgrading the OWSM Repository in Securing Web Services and Managing Policies with Oracle Web Services Manager.