Oracle® Fusion Middleware

Upgrading Oracle WebCenter

12c (12.2.1.2)

E77897-04

October 2017

Explains how to upgrade your existing Oracle WebCenter environment.

Oracle Fusion Middleware Upgrading Oracle WebCenter, 12c (12.2.1.2)

E77897-04

Copyright © 2013, 2017, Oracle and/or its affiliates. All rights reserved.

Primary Authors: Lisa Jamen, Priyanka Chheda, Megha Sharma

Contributing Author: Savita Thakur

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Contents

Preface

- Intended Audience

- Related Documents

- Conventions

1 Introduction to the Oracle WebCenter 12c Upgrade

- 1.1 Understanding the Oracle WebCenter Upgrade to 12c

- 1.2 Understanding the Starting Points for an Oracle WebCenter 12c Upgrade

- 1.3 Understanding the Interoperability and Compatibility Restrictions

2 Pre-Upgrade Tasks for Oracle WebCenter Components

- 2.1 Oracle Fusion Middleware Pre-Upgrade Checklist

- 2.2 Creating a Complete Backup

- 2.2.1 Backing Up the Schema Version Registry Table

- 2.2.2 Maintaining Customized Domain and Environment Settings

- 2.3 Cloning Your Production Environment for Testing

- 2.4 Verifying Certification and System Requirements

- 2.4.1 Verify Your Environment Meets Certification Requirements

- 2.4.2 Verify System Requirements and Specifications

- 2.4.3 Verify That the Database Hosting Oracle Fusion Middleware is Supported

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

- 2.5 Updating Policy Files when Using Enhanced Encryption (AES 256)

- 2.6 Purging Unused Data

- 2.7 Creating an Edition on the Server for Edition-Based Redefinition

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

- 2.9 Identifying Existing Schemas Available for Upgrade

- 2.10 Performing the Oracle WebCenter Pre-Upgrade Tasks

- 2.10.1 Disabling Obsolete Components Before Upgrade

- 2.10.2 Determining Which Schemas Can be Upgraded for WebCenter

3 Upgrading an Oracle WebCenter Domain

- 3.1 About the Oracle WebCenter Upgrade Process to 12c (12.2.1.2)

- 3.2 Installing a Product Distribution

- 3.3 Creating the Required 12c Schemas with the RCU

- 3.4 Running a Pre-Upgrade Readiness Check

- 3.4.1 About Running a Pre-Upgrade Readiness Check

- 3.4.2 Starting the Upgrade Assistant in Readiness Mode

- 3.4.2.1 Upgrade Assistant Parameters

- 3.4.3 Performing a Readiness Check with the Upgrade Assistant

- 3.4.4 Understanding the Readiness Report

- 3.5 Stopping Servers and Processes

- 3.6 Upgrading Product Schemas

- 3.6.1 Identifying Existing Schemas Available for Upgrade

- 3.6.2 Starting the Upgrade Assistant

- 3.6.2.1 Upgrade Assistant Parameters

- 3.6.3 Upgrading Oracle WebCenter Schemas Using the Upgrade Assistant

- 3.6.4 Verifying the Schema Upgrade

- 3.7 About Reconfiguring the Domain

- 3.7.1 Backing Up the Domain

- 3.7.2 Starting the Reconfiguration Wizard

- 3.7.3 Reconfiguring the Domain with the Reconfiguration Wizard

- 3.8 Upgrading Domain Component Configurations

- 3.8.1 Starting the Upgrade Assistant

- 3.8.1.1 Upgrade Assistant Parameters

- 3.8.2 Upgrading Domain Component Configurations Using the Upgrade Assistant

- 3.8.3 Verifying the Domain-Specific-Component Configurations Upgrade

- 3.9 Performing Post-Upgrade Configuration Tasks

- 3.9.1 Starting and Stopping Administration Server

- 3.9.2 Starting and Stopping the Node Manager

- 3.9.3 Starting and Stopping the Managed Servers

- 3.9.4 Verifying the New Applications Work as Expected

4 Upgrading Oracle WebCenter Content

- 4.1 Understanding an Upgrade to Oracle WebCenter Content 12c

- 4.2 WebCenter Content Domain Upgrade Restrictions

- 4.3 Performing Pre-Upgrade Tasks for WebCenter Content

- 4.3.1 Upgrading the Metadata Schema (_MDS) Before Upgrading WebCenter Content Web UI 11g Domain

- 4.4 Performing Pre-Upgrade Tasks for Oracle WebCenter Enterprise Capture

- 4.4.1 Verify the Batch Processing has Completed and Capture JMS Queues are Empty

- 4.5 Performing an Upgrade of Oracle WebCenter Content Imaging

- 4.6 Performing an Upgrade of Oracle WebCenter Content

- 4.7 Performing Post Upgrade Tasks for WebCenter Content

- 4.7.1 Configuring the Oracle WebCenter Content Server Domain to Include WebCenter Content - Web UI

- 4.7.2 Configuring E-Business Suite AXF Schema After an Upgrade

- 4.7.3 Removing IPM/Viewer JMS Servers for Oracle WebCenter Content: Imaging

- 4.7.4 Removing the IPM Server for Oracle WebCenter Content: Imaging

- 4.7.5 Updating the WccAdf.ear File (Optional)

- 4.7.6 Migrating Custom Skins for WebCenter Content Web UI

- 4.7.7 Upgrading Oracle Application Adapters for Oracle WebCenter Content

- 4.7.8 Configuring the Report Library for Records Management in Content Server

- 4.7.9 Using Fusion Middleware Control to Monitor IBR

- 4.7.10 Starting Oracle WebCenter Content Server with SOA or BAM

5 Upgrading Oracle WebCenter Portal to 12c

- 5.1 Performing Pre-Upgrade Tasks for Oracle WebCenter Portal

- 5.1.1 Reassociating to a Database-Based Policy Store

- 5.1.2 Exporting Metadata for Portlet Producer Applications

- 5.1.3 Saving OmniPortlet and Web Clipping Configuration

- 5.1.4 Migrating Portal Framework Applications

- 5.2 Upgrading Oracle WebCenter Portal 11g Installations

- 5.2.1 Running the upgradeWebCenterPortal WLST Command

- 5.2.1.1 Output Generated by the upgradeWebCenterPortal WLST Command

- 5.2.2 Running the Upgrade Audit Tool

- 5.2.3 Accessing Upgrade Metrics

- 5.3 Performing Post-Upgrade Tasks for Oracle WebCenter Portal

- 5.3.1 Upgrading 11g Portlet Producers

- 5.3.1.1 Migrating a Portlet Producer Application

- 5.3.1.2 Redeploying a Portlet Producer Application

- 5.3.1.3 Migrating Customizations

- 5.3.2 Restoring OmniPortlet and Web Clipping Configuration

- 5.3.3 Removing Duplicate Portal Pages

- 5.3.4 Verify the Content Server Connection is Upgraded

- 5.3.5 Upgrading WebCenter Portal 11g Assets to 12c

- 5.4 Understanding the Impact of Upgrade on Deprecated Features

- 5.4.1 Portal-Level Device Settings

- 5.4.2 Hierarchical Portals

- 5.4.3 Deprecated Portlets

- 5.5 Troubleshooting Oracle WebCenter Portal Upgrade Issues

- 5.5.1 Extra Entries Appear for the ACTIVITIES Schema

- 5.5.2 Floating Toolbar Not Available for Custom Page Templates

- 5.5.3 Running the Predeployment Tool does not Update 11g Portlet Producers

- 5.5.4 Handling Errors While Upgrading Oracle WebCenter Portal

- 5.5.5 Errors on Accessing Documents/Blogs/Wiki Pages in an Upgraded Portal

- 5.5.6 Portal Upgrade Fails

6 Upgrading Oracle WebCenter Sites to 12c

- 6.1 Upgrading WebCenter Sites from 11g to 12c

- 6.1.1 About the WebCenter Sites Upgrade Process from 11g to 12c

- 6.1.2 Installing the Product Distribution

- 6.1.3 Creating the Required 12c Schemas with the RCU

- 6.1.4 Configuring the WebCenter Sites Domain

- 6.1.5 Configuring WebCenter Sites Instance

- 6.1.5.1 Prerequisites for Configuring WebCenter Sites Instance

- 6.1.5.2 Configuring WebCenter Sites with the Configurator

- 6.1.6 Post-Configuration Tasks

- 6.1.6.1 Switching to Authentication Against an LDAP Directory

- 6.1.6.2 Switching to Authentication Against Oracle Access Manager

- 6.1.7 Before Running the Upgrade Assistant

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

- 6.1.7.2 Copying 11.1.1.8 Schema from a DB2 Source to a New Target Database

- 6.1.8 Upgrading Product Schemas

- 6.1.8.1 Starting the Upgrade Assistant

- 6.1.8.1.1 Upgrade Assistant Parameters

- 6.1.8.2 Upgrading Product Schemas Using the Upgrade Assistant

- 6.1.8.3 Verifying the Schema Upgrade

- 6.1.9 Upgrading Domain Component Configurations

- 6.1.9.1 Starting the Upgrade Assistant

- 6.1.9.1.1 Upgrade Assistant Parameters

- 6.1.9.2 Upgrading Sites Configuration Using the Upgrade Assistant

- 6.1.9.3 Verifying the Domain-Specific-Component Configurations Upgrade

- 6.1.10 Post-Upgrade Validation Tasks

- 6.1.11 Post-Upgrade Tasks

- 6.1.11.1 Starting Servers and Processes

- 6.1.11.2 If the Existing Instance is a Delivery Instance...

- 6.2 Upgrading WebCenter Sites from a Previous 12c Release

- 6.2.1 About the WebCenter Sites Upgrade Process from a Previous 12c Release

- 6.2.2 Installing the Product Distribution

- 6.2.3 If you have installed Sites with Insights...

- 6.2.4 Running a Pre-Upgrade Readiness Check

- 6.2.4.1 About Running a Pre-Upgrade Readiness Check

- 6.2.4.2 Starting the Upgrade Assistant in Readiness Mode

- 6.2.4.2.1 Upgrade Assistant Parameters

- 6.2.4.3 Performing a Readiness Check with the Upgrade Assistant

- 6.2.4.4 Understanding the Readiness Report

- 6.2.5 Stopping Servers and Processes

- 6.2.6 About Reconfiguring the Domain

- 6.2.6.1 Backing Up the Domain

- 6.2.6.2 Starting the Reconfiguration Wizard

- 6.2.6.3 Reconfiguring the WebCenter Sites Domain with the Reconfiguration Wizard

- 6.2.7 Before Running the Upgrade Assistant

- 6.2.8 Upgrading Product Schemas

- 6.2.8.1 Starting the Upgrade Assistant

- 6.2.8.1.1 Upgrade Assistant Parameters

- 6.2.8.2 Upgrading Product Schemas Using the Upgrade Assistant

- 6.2.8.3 Verifying the Schema Upgrade

- 6.2.9 Upgrading Domain Component Configurations

- 6.2.9.1 Starting the Upgrade Assistant

- 6.2.9.1.1 Upgrade Assistant Parameters

- 6.2.9.2 Upgrading Domain Components Using the Upgrade Assistant

- 6.2.9.3 Verifying the Domain-Specific-Component Configurations Upgrade

- 6.2.10 Post-Upgrade Validation Tasks

- 6.2.11 Post-Upgrade Tasks

- 6.2.11.1 Starting Servers and Processes

- 6.3 Migrating Custom Java Libraries or Static Web Resources

7 Upgrading WebCenter in a Clustered Topology

- 7.1 Troubleshooting a WebCenter Cluster Upgrade

- 7.1.1 Accessing WebCenter Content URLs Post Upgrade

Preface

Oracle Fusion Middleware Upgrading Oracle WebCenter describes the tools and procedures required for you to upgrade your existing Oracle WebCenter environment.

Topics:

- Intended Audience

- Related Documents
Upgrade documentation is organized by tasks in the 12c documentation library. The task-specific pages provide direct links to common upgrade procedures and related documentation.

- Conventions

Intended Audience

This guide is intended for existing Oracle Fusion Middleware users who are upgrading their Oracle Fusion Middleware products to a more recent version or to the latest version. To follow the instructions provided in this document, the reader should be comfortable running system administration operations, such as creating users and groups, adding users to groups, and installing operating system patches on the computer where the products are going to be installed. Users on UNIX systems who are upgrading their Oracle Fusion Middleware software may need root access to run some scripts.

Related Documents

Upgrade documentation is organized by tasks in the 12c documentation library. The task-specific pages provide direct links to common upgrade procedures and related documentation.

You can refer the Oracle Fusion Middleware Library for additional information.

- For installation information, see Fusion Middleware Installation Documentation.

- For upgrade information, see Fusion Middleware 12c Upgrade Documentation.

- For administration-related information, see Fusion Middleware 12c Administration Documentation.

- For release-related information, see Fusion Middleware 12c Release Notes.

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

1 Introduction to the Oracle WebCenter 12c Upgrade

Upgrading Oracle WebCenter to 12c (12.2.1.2) is a multi-step process. The procedures you perform to upgrade and reconfigure your existing 11g or previous 12c deployment will depend on the configuration of your domain and the components you will be upgrading. Having a complete understanding of this process before you begin the upgrade can help you limit unnecessary downtime.

Topics:

- Understanding the Oracle WebCenter Upgrade to 12c
When upgrading your Oracle WebCenter environment to 12c (12.2.1.2), you should understand how your pre-upgrade environment will be affected by the upgrade. Also, you must understand the difference between in place and out of place upgrades.

- Understanding the Starting Points for an Oracle WebCenter 12c Upgrade
Before you begin your upgrade, verify that your components are eligible for an upgrade to this release. If a component is not at a supported starting point, then you must upgrade it to a supported starting point before you can start an upgrade to 12c (12.2.1.2).

- Understanding the Interoperability and Compatibility Restrictions
Before you begin the upgrade process, you should understand how all of the components within your existing domain will be impacted by the upgrade. Verify that components in your pre-upgrade environment will not have compatibility or interoperability issues post-upgrade.

1.1 Understanding the Oracle WebCenter Upgrade to 12c

When upgrading your Oracle WebCenter environment to 12c (12.2.1.2), you should understand how your pre-upgrade environment will be affected by the upgrade. Also, you must understand the difference between in place and out of place upgrades.

For example, schemas and domain directory upgrades are performed in place which updates the existing 11g files during the upgrade. The 12c (12.2.1.2) Oracle Home binaries are upgraded out of place as the binaries are installed in a new directory.

The upgrade to 12c (12.2.1.2) includes the midtier and the schemas. You cannot perform a midtier-only or schema-only upgrade.

- Oracle WebLogic Server, JRF and WebCenter Oracle Home Binaries - Upgraded Out of Place
You will install the Oracle Infrastructure 12c (12.2.1.2) (which includes WebLogic Server and JRF) and the Oracle WebCenter distribution binaries in a new Oracle home. The upgrade of binaries is considered out of place as the existing binaries are not overwritten.

- Schemas - Upgraded In Place
The existing schemas are upgraded to 12c in place which means that the Upgrade Assistant updates and overwrites the schemas during the upgrade process. The servers must be down during this process.

Exception: The Oracle WebCenter Sites schemas are upgraded out of place.

- Domain Directory Reconfiguration - Upgraded In Place
The existing domain is upgraded in place. During the upgrade you will identify the location of the existing 11g or 12c domain that will be reconfigured to point to the new 12c (12.2.1.2) home directory.

- Domain Component Configuration - Upgraded In Place
After the reconfiguration of the existing domain, the Upgrade Assistant is used again to upgrade any remaining domain component configurations to point to the new 12c (12.2.1.2) home directory.

1.2 Understanding the Starting Points for an Oracle WebCenter 12c Upgrade

Before you begin your upgrade, verify that your components are eligible for an upgrade to this release. If a component is not at a supported starting point, then you must upgrade it to a supported starting point before you can start an upgrade to 12c (12.2.1.2).

The supported starting points for Oracle WebCenter vary by component. Review the table to determine which versions are supported for an upgrade to Oracle WebCenter 12c (12.2.1.2).

Component Name

Supported Starting Points for Upgrade

Oracle WebCenter Enterprise CaptureFoot 1

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

Oracle WebCenter Content

11.1.1.7

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

Oracle WebCenter Portal

11.1.1.7

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

Oracle WebCenter Sites

11.1.1.8

12.2.1.0

12.2.1.1

Footnote 1

If you installed WebCenter Capture 11.1.1.9.0, then the schema version will still be 11.1.1.8.0 as there were no schema changes in 11.1.1.9.0.

1.3 Understanding the Interoperability and Compatibility Restrictions

Before you begin the upgrade process, you should understand how all of the components within your existing domain will be impacted by the upgrade. Verify that components in your pre-upgrade environment will not have compatibility or interoperability issues post-upgrade.

In general, you cannot upgrade a domain that contains components that are not yet available or have been deprecated in Oracle Fusion Middleware 12c (12.2.1.2). There are other restrictions on the components that can be upgraded to 12c (12.2.1.2) and you need to be sure that you have reviewed this information carefully before you proceed with the upgrade.

WebCenter Web UI 12c is not compatible with WebCenter Content or Application Development Framework 11g.

WebCenter Web UI 12c (12.2.1.2) cannot be used with WebCenter Content 11g or Application Development Framework 11g. Web UI can only be used with 12c (12.2.1.2).

2 Pre-Upgrade Tasks for Oracle WebCenter Components

You can use the pre-upgrade checklists to determine which tasks must be completed before you start the upgrade. The tasks that you perform will vary depending on your existing deployment and the components and configurations that are being upgraded. Do not start an upgrade until you have reviewed the list and completed all required tasks.

Note:
Before you start any upgrade, make sure that you have created a complete backup of your pre-upgrade environment. If the upgrade fails, you will have to restore from backup and restart the upgrade.

Topics:

- 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.

- 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.

- 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.

- 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.

- Performing the Oracle WebCenter Pre-Upgrade Tasks
Before upgrading to Oracle WebCenter products 12c (12.2.1.2), perform pre-upgrade tasks that apply to your environment.

2.1 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 can 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.

Table 2-1 Tasks to Perform Before You Upgrade to Oracle Fusion Middleware 12c

Task

Description

Required

Create a complete backup of your existing environment.

Back up all system-critical files and database(s) 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.

- Make sure that your backup includes the schema version registry table. See Backing Up the Schema Version Registry Table.

- If you modified any of the startup scripts in your existing domain, you will need to copy them to temporary directory location (outside of the existing domain) during the upgrade and redeploy them after the upgrade. See Maintaining Customized Domain and Environment Settings.

Optional

Clone your production environment to use as an upgrade testing platform.

In addition to creating a complete backup of your system files, Oracle strongly recommends that you clone your production environment. This environment can be used to test the upgrade.

See Cloning Your Production Environment for Testing.

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.

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

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.

See Verifying Certification and System Requirements.

Required for 32–bit Operating Systems Only

Migrate to a 64-bit operating system before you can upgrade.

This is required only if you are currently running an unsupported 32–bit operating system.

See Migrating from a 32-Bit to a 64-Bit Operating System.

Optional

Update security policy files if you are using enhanced encryption (AES 256).

Some of the security algorithms used in Fusion Middleware 12c require additional policy files for the JDK.

If you plan to use enhanced encryption, such as AES 256, Oracle recommends that you apply the latest required policy files to the JDK before you upgrade.

See Updating Policy Files when Using Enhanced Encryption (AES 256).

Optional

Purge any outdated or unused data before you upgrade.

To optimize performance, Oracle strongly recommends that you purge data and objects that will not be used in the upgraded environment.

See Purging Unused Data.

Required for Oracle Database Users Only
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.2).

If you are using an Edition-Based Redefinition (EBR) database, you must create the edition before starting the upgrade.

See Creating an Edition on the Server for Edition-Based Redefinition.

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

2.2 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.

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.

The Upgrade Assistant Prerequisites screen prompts you to acknowledge that backups have been performed before you proceed with the actual upgrade. However, note that the Upgrade Assistant does not verify that a backup has been created.

See:

- Backing Up Your Environment in Oracle Fusion Middleware Administering Oracle Fusion Middleware

- Upgrading and Preparing Your Oracle Databases for 12c in Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware

Topics:

- Backing Up the Schema Version Registry Table
Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table or the FMWREGISTRY.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, domain upgrade, and reconfiguration operations. Save your customized files to a shared library location so that you can continue to use them after the upgrade.

2.2.1 Backing Up the Schema Version Registry Table

Your system backup must include the SYSTEM.SCHEMA_VERSION_REGISTRY$ table or the FMWREGISTRY.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.

2.2.2 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, domain upgrade, and reconfiguration operations. Save your customized files to a shared library location so that you can continue to use them after the upgrade.

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. To maintain your custom domain-level environment settings, Oracle recommends that you create a separate file to store the custom domain information before you upgrade, instead of modifying the scripts directly.

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 EXISTING_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 Oracle Fusion Middleware Upgrading Oracle WebLogic Server.

2.3 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.

2.4 Verifying Certification and System Requirements

Review the certification matrix and system requirements documents to verify that your environment meets the necessary requirements for installation.

Note:
When checking the certification, system requirements, and interoperability information, be sure to check specifically for any 32-bit or 64-bit system requirements. It is important for you to download software specifically designed for the 32-bit or 64-bit 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.

Topics:

- 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 or software configuration.

- Verify System Requirements and Specifications
It is important 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.

- 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 12c.

- Verify That the JDK Is Certified for This Release of Oracle Fusion Middleware
At the time this document was published, the certified JDK for 12c (12.2.1.2) was 1.8.0_101.

2.4.1 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 or 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 Technology Network. See the Certification Matrix for 12c (12.2.1.2).

2.4.2 Verify System Requirements and Specifications

It is important 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 certification are met. For example, if the Certification Matrix for 12c (12.2.1.2) indicates that your product is certified for installation on 64-Bit Oracle Linux 7, the System Requirements and Specifications document should be used to verify that your Oracle Linux 7 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:
When you install the Oracle Fusion Middleware Release 12c software in preparation for upgrade, you should use the same user account that you used to install and configure the existing, pre-upgrade Oracle Fusion Middleware software. On UNIX operating systems, this ensures that the proper owner and group is applied to new Oracle Fusion Middleware 12c files and directories.

If you are running a 32–bit environment, you will need to perform an additional set of steps:

Topics:

- Migrating from a 32-Bit to a 64-Bit Operating System
If you have a 32–bit operating system, then you must migrate your 32-bit environment to a 64-bit software environment before you upgrade.

2.4.2.1 Migrating from a 32-Bit to a 64-Bit Operating System

If you have a 32–bit operating system, then you must migrate your 32-bit environment to a 64-bit software environment before you upgrade.

Make sure to validate the migration to ensure all your Oracle Fusion Middleware 11g software is working properly on the 64-bit machine, and only then perform the upgrade to Oracle Fusion Middleware 12c.

In these tasks, host refers to the 32-bit source machine and target refers to the new 64-bit target machine.

Note:
These steps assume that your database is located on a separate host and will not be moved.

Upgrading an operating system typically involves the following:

Caution:
These steps are provided as an example of the operating system upgrade process and may or may not include all of the procedures you must perform to update your specific operating system. Consult your operating system's upgrade documentation for more information.

Topics:

- Procure the Hardware That Supports the Upgrade's 64-bit Software Requirement
Make sure that you have supported target hardware in place before you begin the upgrade process.

- Stop All Processes
Before upgrading, you must stop all processes, including Managed Servers, the Administration Server, and Node Manager, if they are started on the host.

- Back Up All Files from the 32-bit Host Machine
Make sure that you have created a complete backup of your entire 11g deployment before you begin the upgrade process. These files can be used if there is an issue during the migration and you have to restart the process.

- Set Up the Target 64-bit Machine with the 11g Host Name and IP Address
The host name and IP address of the target machine must be made identical to the host. This requires you to change the IP address and name of the source machine or decommission the source machine to avoid conflicts in the network.

- Restore the 11g Backup from 32-bit Host to 64-bit Host
Restore the files you backed from the 32-bit host using the same directory structure that was used in 11g. The directory structure on the target machine must be identical to the structure of the host machine.

- Install the 12c Product Distributions on the Target Machine
Oracle recommends an Out-of-Place approach for upgrade. Therefore, you must install the 12c product distributions in a new Oracle home on the target machine.

- Upgrade the Target 64-bit Environment Using the Standard Upgrade Procedure
After installing the product on the target machine, you must upgrade each product component individually using an Upgrade Utility specified in the component-specific upgrade guide and complete any post-upgrade tasks.

2.4.2.1.1 Procure the Hardware That Supports the Upgrade's 64-bit Software Requirement

Make sure that you have supported target hardware in place before you begin the upgrade process.

2.4.2.1.2 Stop All Processes

Before upgrading, you must stop all processes, including Managed Servers, the Administration Server, and Node Manager, if they are started on the host.

Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Stop the Administration Server

When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To stop the Administration Server, use the stopWebLogic script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Stop Node Manager

To stop Node Manager, close the command shell in which it is running.

Alternatively, after having set the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down. See stopNodeManager in Oracle Fusion Middleware WLST Command Reference for WebLogic Server.

2.4.2.1.3 Back Up All Files from the 32-bit Host Machine

Make sure that you have created a complete backup of your entire 11g deployment before you begin the upgrade process. These files can be used if there is an issue during the migration and you have to restart the process.

Note:
If the upgrade from 32-bit to 64-bit takes place on the same machine, there is a risk of corrupting the source environment if the upgrade fails.

See Backing Up Your Environment in Oracle Fusion Middleware Administrator's Guide.

During the upgrade you must have access to the contents of the following:

- 11g_DOMAIN_HOME

- 11g/nodemanager directory located in 11g_ORACLE_HOME/wlserver/common/

Some of the backup and recovery procedures described in Backing Up Your Environment in Oracle Fusion Middleware Administrator's Guide are product-specific. Do not proceed with the upgrade until you have a complete backup.

2.4.2.1.4 Set Up the Target 64-bit Machine with the 11g Host Name and IP Address

The host name and IP address of the target machine must be made identical to the host. This requires you to change the IP address and name of the source machine or decommission the source machine to avoid conflicts in the network.

The process of changing an IP address and host name vary by operating system. Consult your operating system's administration documentation for more information.

2.4.2.1.5 Restore the 11g Backup from 32-bit Host to 64-bit Host

Restore the files you backed from the 32-bit host using the same directory structure that was used in 11g. The directory structure on the target machine must be identical to the structure of the host machine.

See Recovering Your Environment in Oracle Fusion Middleware Administrator's Guide.

2.4.2.1.6 Install the 12c Product Distributions on the Target Machine

Oracle recommends an Out-of-Place approach for upgrade. Therefore, you must install the 12c product distributions in a new Oracle home on the target machine.

Refer to the component-specific installation guides for the component(s) you are installing.

2.4.2.1.7 Upgrade the Target 64-bit Environment Using the Standard Upgrade Procedure

After installing the product on the target machine, you must upgrade each product component individually using an Upgrade Utility specified in the component-specific upgrade guide and complete any post-upgrade tasks.

If you are upgrading additional components, see the component-specific upgrade guide.

Note:
The Node Manager upgrade procedure requires access to the original Node Manager files. Use the 11g Node Manger files that you backed up from the 32-bit source machine as part of Back Up All Files from the 32-bit Host Machine.

2.4.3 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 12c.

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 12c (12.2.1.2).

Note:
If your database version is no longer supported, you must upgrade to a supported version before starting an upgrade. See Upgrading and Preparing Your Oracle Databases for 12c in Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

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

At the time this document was published, the certified JDK for 12c (12.2.1.2) was 1.8.0_101.

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.

For more information on the difference between generic and platform-specific installers, see Understanding the Difference Between Generic and Platform-Specific Distributions in the Oracle Fusion Middleware Download, Installation, and Configuration Readme Files.

2.5 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.

The Java platform defines a set of APIs spanning major security areas, including cryptography, public key infrastructure, authentication, secure communication, and access control. These APIs allow developers to easily integrate security mechanisms into their application code.

Some of the security algorithms used in Fusion Middleware 12c require additional policy files for the JDK. See Java Cryptography Architecture Oracle Providers Documentation.

Note:
If you attempt to use enhanced encryption without applying these policy files to the JDK before you begin the upgrade, the upgrade can fail and you must restore the entire pre-upgrade environment and start the upgrade from the beginning.

2.6 Purging Unused Data

Purging unused data and maintaining a purging methodology before an upgrade can optimize the upgrade process.

Some components have automated purge scripts. If you are using purge scripts, wait until the purge is complete before starting the upgrade process. The upgrade may fail if the purge scripts are running while using the Upgrade Assistant to upgrade your schemas.

2.7 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.

Edition-based redefinition enables you to upgrade an application's database objects while the application is in use, thus minimizing or eliminating downtime. This is accomplished by changing (redefining) database objects in a private environment known as an edition. Only when all the changes have been made and tested, you make the new version of the application available to users.

Note:
This task must be completed by an Oracle Database User with DBA privileges.

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. The new edition for 12c must be a child of your existing 11g or 12c edition.

To create an edition on the database server, sign in as an SYS user (or another Oracle user that has DBA privileges) and enter the following command:

create edition Oracle_FMW_12_2_1_1 as child of Oracle_FMW_11_1_1_7_0;

where Oracle_FMW_11_1_1_7_0 is an example of the edition name you specified in RCU 11.1.1.7 when the 11.1.1.7 schemas were created. Be sure to provide the actual name used when creating the edition.

The following message notifies you that the edition is created successfully:

Edition created.

During the upgrade, you are prompted to launch the Reconfiguration Wizard to reconfigure your existing domain. Before running the Reconfiguration Wizard, you must specify the database default edition. Use the following SQL command to manually set up the default edition name for the database, for example:

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1_1;

2.8 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:
If you created the non-SYSDBA user FMW in a previous release, you must drop and recreate this user before starting the upgrade. Running the Upgrade Assistant with an older FMW user may lead to a failed upgrade as new privileges may have been added. Oracle recommends that you drop and recreate the user instead of modifying the existing FMW user.

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 thev$xatrans$ table is required only by Oracle Identity Manager. If you do not require Oracle Identity Manager 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, welcome1 is the password. When granting privileges, make sure that you specify your actual password.

create user FMW identified by welcome1;
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;

Note:

Oracle Database 11.2.0.3 Database Users ONLY: You must apply Oracle Patch 13036331 before you begin the upgrade. Go to My Oracle Support to download the patch.

If you do not apply this patch, you must grant additional privileges for some schemas.

2.9 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 acount 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.

3. Note the schema prefix name that was used for your existing schemas. You will use the same prefix when you create new 12c schemas.

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.2) upgrade procedures. Refer to your pre-upgrade version documentation for more information.

- Some components, such as Oracle Enterprise Data Quality, Oracle GoldenGate Monitor, and Oracle GoldenGate Veridata, support an upgrade from versions other than the standard Oracle Fusion Middleware supported versions.

- If you used an OID-based policy store in 11g, 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.2). Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 12c (12.2.1.2).

2.10 Performing the Oracle WebCenter Pre-Upgrade Tasks

Before upgrading to Oracle WebCenter products 12c (12.2.1.2), perform pre-upgrade tasks that apply to your environment.

The pre-upgrade tasks for Oracle WebCenter include the following:

Pre-Upgrade Task

More Information

Disable all deprecated or obsolete components before upgrade.

Disabling Obsolete Components Before Upgrade

Complete the pre-upgrade tasks for Oracle WebCenter Content (if you will be upgrading Content or WebCenter Content Web UI).

Performing Pre-Upgrade Tasks for WebCenter Content

Complete the pre-upgrade tasks for Oracle WebCenter Enterprise Capture (if you will be upgrading Enterprise Capture).

Performing Pre-Upgrade Tasks for Oracle WebCenter Enterprise Capture

Complete the pre-upgrade tasks for Oracle WebCenter Portal (if you will be upgrading WebCenter Portal).

Performing Pre-Upgrade Tasks for Oracle WebCenter Portal

Topics:

- Disabling Obsolete Components Before Upgrade

- Determining Which Schemas Can be Upgraded for WebCenter

2.10.1 Disabling Obsolete Components Before Upgrade

The following components should be disabled before the upgrade because they are obsolete or disabled.

Note:
Failure to disable these components may cause the upgrade to fail and content servers will not be able to start.

- AppAdapterUniversal

- CIS_Helper

- ContentTrackerReports

- SiteStudioExternalApplications

- FormEditor (which uses the now deprecated FCKEditor)l

- proxyconnections8

- UrmAgent

- PDFExportConverter (IBR)

For more information about disabling components, see Enabling or Disabling a Component Using the Component Manager in Oracle Fusion Middleware Administering Oracle WebCenter Content.

2.10.2 Determining Which Schemas Can be Upgraded for WebCenter

This table describes the WebCenter schemas that can be upgraded to 12c.Your environment may or may not use all of these schemas.

Table 2-2 WebCenter Schemas that can be upgraded

Component Name

Schema(s)

Schema Version Before Upgrade

Schema Version After Upgrade

Dependencies

Oracle Enterprise Capture

prefix_CAPTURE

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

12.2.1.1

Metadata Services (_MDS_

Capture is an ADF application and therefore requires the MDS schema be upgraded before the WebCenter servers are started.

Oracle Platform Security Services (_OPSS)

Capture does not use the OPSS schema directly, but requires that the OPSS schema be upgraded as part of the upgrade process.

Oracle Portal

prefix_PORTAL

11.1.1.6

12.2.1.0

12.2.1.1

12.2.1.1

None.

WebCenter Portal (previously WebCenter Spaces)

prefix_WEBCENTER

11.1.1.6

11.1.1.7

12.2.1.0

12.2.1.1

12.2.1.1

The prefix_MDS schema must be upgraded first.

Discussions (WebCenter Suite)

prefix_DISCUSSIONS

11.1.1.7

12.2.1.0

12.2.1.1

12.2.1.1

None.

Discussions Crawler

prefix_DISCUSSIONS_CRAWLER

11.1.1.8

12.2.1.0

12.2.1.1

The prefix_DISCUSSIONS schema must be upgraded first.

Note: You need to specify the password for the DISCUSSION_CRAWLER schema manually. However, the password for other schemas is automatically populated.

Activity Graph and Analytics

prefix_ACTIVITIES

11.1.1.7

12.2.1.0

12.2.1.1

None.

Portlets

prefix_PORTLET

11.1.1.2

12.2.1.0

12.2.1.1

None.

Oracle Content Server 11g - Complete

prefix_OCS

11.1.1.6

11.1.1.7

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

None.

Oracle WebCenter Sites

prefix_WCSITES

11.1.1.8.0

12.2.1.0

12.2.1.1

None.

3 Upgrading an Oracle WebCenter Domain

It is important to understand the general upgrade procedures for Oracle WebCenter and WebCenter Content. Also, in order to Upgrade Oracle WebCenter Domain, some additional component-specific tasks may be required.

The procedures outlined in the following sections describe the high-level process of upgrading a basic WebCenter domain to 12c (12.2.1.2). Most upgrades follow these general procedures, but the actual upgrade procedures you will perform depend on which components are being upgraded. There may be additional pre- or post- upgrade procedures associated with your components. Therefore, you will need to locate the upgrade procedures for each component in your pre-upgrade environment to complete the domain upgrade.

For example, if your Oracle WebCenter domain includes Oracle WebCenter Content and WebCenter Portal, you would need to follow the procedures described in Upgrading Oracle WebCenter Content and Upgrading Oracle WebCenter Portal 11g Installations.

Topics:

- About the Oracle WebCenter Upgrade Process to 12c (12.2.1.2)
Review the process flow for upgrading WebCenter products to 12c to get a better understanding of the procedures you will perform and when you will preform them.

- Installing a Product Distribution
Before beginning your upgrade, download Oracle Fusion Middleware Infrastructure and the WebCenter Content distributions on the target system and install them using Oracle Universal Installer.

- Creating the Required 12c Schemas with the RCU
When upgrading from 11g, you must create the required 12c schemas. You can use the Repository Creation Utility (RCU) to create customized schemas or, optionally, you can use the Upgrade Assistant to create schemas using the default schema settings. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures.

- Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. 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.

- Stopping Servers and Processes
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.

- 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.

- About Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

- Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Performing Post-Upgrade Configuration Tasks
You may have to perform additional configuration tasks after an upgrade depending on which components are in your deployment.

3.1 About the Oracle WebCenter Upgrade Process to 12c (12.2.1.2)

Review the process flow for upgrading WebCenter products to 12c to get a better understanding of the procedures you will perform and when you will preform them.

This process flow shows the high-level procedures for upgrading a WebCenter domain to 12c (12.2.1.2). The actual procedures you will perform depends on your pre-upgrade environment and the components you will be upgrading.

Figure 3-1 Upgrading Oracle WebCenter to 12c (12.2.1.2)

Task

Description

Required

Complete all of the Oracle Fusion Middleware standard pre-upgrade tasks, as well as any additional component-specific tasks you may be required to perform.

Pre-Upgrade Tasks for Oracle WebCenter Components

Required

Install the product distributions for all the products that are part of the domain.

Note that in 12c, the WebLogic Server and JRF are part of the Infrastructure distribution and must be installed first.

The binaries should be installed into a new Oracle home on the same host as the existing deployment.

For 11g to 12c Upgrade Only:

Run the 12c Repository Creation Utility (RCU) to create the required 12c schemas (_STB and _OPSS).

The Service Table (_STB) schema is required in 12c.

The OPSS (_OPSS) schema is required if an OID-based policy store was used in 11g.

If you are upgrading from a previous 12c release, then you will already have these schemas in your repository.

Optional

Run a pre-upgrade readiness check with the Upgrade Assistant.

When run in -readiness mode, the Upgrade Assistant performs a read-only check to determine if there might be problems in the starting point environment that would prevent a successful upgrade.

The checks vary by component and a complete report is generated to help troubleshoot any potential issues.

Required

Stop the Administration Server, Managed Servers and any other running applications in your existing deployment.

Failure to shut down the existing environment during the upgrade can corrupt your schemas and/or component configurations.

Required

Run the Upgrade Assistant to upgrade individually selected schemas or all schemas used by the domain.

Oracle recommends that you allow the Upgrade Assistant to upgrade all schemas within the selected domain whenever possible.

Required

Run the Reconfiguration Wizard to reconfigure the domain. The Reconfiguration Wizard is a new tool in Oracle Fusion Middleware 12c.

WebCenter Portal and Sites Users Only: Run the Upgrade Assistant (again) to upgrade any remaining component configurations.

WebCenter Content Users Only: You will not run the Upgrade Assistant as the necessary configuration changes are performed automatically at server startup (post upgrade) without user intervention.

Upgrading Domain Component Configurations

WebCenter Portal Users Only: You must complete a set of additional procedures to upgrade Oracle WebCenter Portal to 12c.

Upgrading Oracle WebCenter Portal 11g Installations

Required

Complete all of the required post-upgrade tasks described in your component-specific documentation.

Some components will not work correctly if these tasks are not performed after the upgrade.

Performing Post-Upgrade Configuration Tasks

Required

Restart the administration server and the managed servers.

Required

Verify the upgrade was successful (applications function as expected, etc.)

Verifying the New Applications Work as Expected

Optional

Upgrade WebCenter for a cluster topology, if applicable

Upgrading WebCenter in a Clustered Topology

3.2 Installing a Product Distribution

Before beginning your upgrade, download Oracle Fusion Middleware Infrastructure and the WebCenter Content distributions on the target system and install them using Oracle Universal Installer.

Note:
When Infrastructure is required for the upgrade, you must install the Oracle Fusion Middleware distribution first before you install other Fusion Middleware products.

To install the 12c (12.2.1.2) distributions:

1. Sign in to the target system.

2. Download the following from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle WebCenter Content (fmw_12.2.1.2.0_wccontent_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

After your Infrastructure installation is complete, you will install the remaining distributions the same way using the correct distribution names. For example, to start the installation program for Oracle WebCenter Content, use fmw_12.2.1.2.0_wccontent_generic.jar as the distribution name

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location, and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select an option:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the products to install.
Click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that are verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options that you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed Oracle Fusion Middleware Infrastructure, repeat the steps above to install the other product distributions.

3.3 Creating the Required 12c Schemas with the RCU

When upgrading from 11g, you must create the required 12c schemas. You can use the Repository Creation Utility (RCU) to create customized schemas or, optionally, you can use the Upgrade Assistant to create schemas using the default schema settings. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures.

Note:
If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.

The following schemas must exist before you upgrade to 12c. If you are upgrading from 11g, and you are not sure which schemas you currently have, refer to the steps below to identify the existing schemas in your domain. You do not need to re-create these schemas if they already exist.

- Service Table schema (prefix_STB). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas.

Note:

If the Service Table schema does not exist, you may encounter the error message UPGAST-00328 : The schema version registry table does not exist on this database. If that happens it is necessary to create the service table schema in order to run Upgrade Assistant

- Oracle Platform Security Services (OPSS) schema (prefix_OPSS). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can select the OPSS schema. The Upgrade Assistant upgrades the OID-based security store automatically.

Note:

The 12c OPSS database schema is required so that you can reference the 12c schema during the reconfiguration of the domain. Your domain continues to use the OID-based security store after the upgrade is complete.

- Audit schemas (OPSS_AUDIT_VIEWER). If you have used an XML-based OPSS_AUDIT schema, or the Portal or Services schema in 11g, you will need to create a new 12c OPSS_AUDIT_VIEWER schema by using the RCU. Otherwise, the domain reconfiguration will fail.

To create the 12c schemas with the RCU:

1. (Optional) If you are upgrading from 11g, and you wish to confirm the schemas which are present in your existing domain, then connect to the database as a user with DBA privileges, and run the following code 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. Verify that a certified JDK already exists on your system by running java -version from the command line. For 12c (12.2.1.2), the certified JDK is 1.8.0_101 and later.
Ensure that the JAVA_HOME environment variable is set to the location of the certified JDK. For example:

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

Add $JAVA_HOME/bin to $PATH.

3. Go to the oracle_common/bin directory.
On UNIX operating systems:

NEW_ORACLE_HOME/oracle_common/bin

On Windows operating systems:

NEW_ORACLE_HOME\oracle_common\bin

where NEW_ORACLE_HOME is your 12c (12.2.1.2) Oracle home.

4. Start the RCU:

- (UNIX) ./rcu

- (Windows) rcu.bat

5. On the Welcome screen, click Next.

6. On the Create Repository screen, select Create Repository and then select System Load and Product Load.
If you do not have DBA privileges, select Prepare Scripts for System Load. This will generate a SQL script containing all the same SQL statements and blocks that would have been called if the RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.
Click Next.

7. On the Database Connection Details screen, select the Database Type and enter the connection information for the database that hosts the 11g schemas. See the pertinent table below.

Table 3-1 Connection Credentials for Oracle Databases and Oracle Databases with Edition-Based Redefinition

Option

Description and Example

Host Name

Specify the name of the server where your database is running in the following format:

examplehost.exampledomain.com

For Oracle RAC databases, specify the VIP name or one of the node names in this field.

Port

Specify the port number for your database. The default port number for Oracle databases is 1521.

Service Name

Specify the service name for the database. Typically, the service name is the same as the global database name.

For Oracle RAC databases, specify the service name of one of the nodes in this field. For example:

examplehost.exampledomain.com

Username

Enter the user name for your database. The default user name is SYS.

Password

Enter the password for your database user.

Role

Select the database user's role from the drop-down list:

Normal or SYSDBA

Table 3-2 Connection Credentials for MySQL Databases

Option

Description and Example

Host Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 3-3 Connection Credentials for Microsoft SQL Server Databases

Option

Description and Example

Unicode Support

Select Yes or No from the drop-down list.

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.
MSSQL named instances: A named instance is identified by the network name of the computer and the instance name that you specify during installation. The client must specify both the server name and the instance name when connecting.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 3-4 Connection Credentials for IBM DB2 Databases

Option

Description and Example

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with DB Owner privileges. The default user name for IBM DB2 databases is db2admin.

Password

Enter the password for your database user.

If the prerequisite check is successful, click OK to continue to the next screen. If the check fails, review the details you entered and try again.

8. On the Select Components screen, select Select existing prefix and select the prefix that was used to create the existing 11g schemas from the drop-down menu (for example, DEV11G). This prefix is used to logically group schemas together for use in this domain.

Note:

The Common Infrastructure Services (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.

Make a note of the prefix and schema names for the components you are installing as you will need this information when you configure the installation. Click Next.

9. In the Checking Prerequisites dialog, verify that the prerequisites check is successful, then click OK.

10. On the Schema Passwords screen, specify the passwords for your schema owners.
Make a note of the passwords you enter on this screen as you will need this information while configuring your product installation.

11. On the Map Tablespaces screen, configure the required tablespace mapping for the schemas you want to create.
Click Next, then click OK in the confirmation dialog. When the progress dialog shows the tablespace creation is complete, click OK.

You see the Encrypt Tablespace check box only if you have enabled Transparent Data Encryption (TDE) in the database (Oracle or Oracle EBR) when you start the RCU. Select the Encrypt Tablespace check box on the Map Tablespaces screen to encrypt all new tablespaces that the RCU creates.

12. Verify the information on the Summary screen and click Create to begin schema creation.
This screen contains information about the log files that were created from this RCU operation. Click on the name of a particular log file to view the contents of that file.

13. Review the information on the Completion Summary screen to verify that the operation is completed successfully. Click Close to complete the schema creation.

3.4 Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. 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.

Topics:

- 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.

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

- Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the 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.

3.4.1 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.

3.4.2 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) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

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, set the DISPLAY environment variable to the system name or IP address of your local workstation, and rerun Upgrade Assistant.

If you continue to receive these errors after setting DISPLAY, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may still not be set correctly.

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

Topics:

- Upgrade Assistant Parameters

3.4.2.1 Upgrade Assistant Parameters

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

Table 3-5 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

3.4.3 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:

- Individually Selected Schemas allows you to select individual schemas for review before upgrade. The readiness check reports whether a schema is supported for an upgrade or where an upgrade is needed.
When you select this option, the screen name changes to Selected Schemas.

- Domain Based allows 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.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components that have a schema available to upgrade for which you want to perform a readiness check.
If you selected Domain Based: On the Component List screen, review the list of components that are present in your domain for which you want to perform a readiness check.

If you select a component that has dependent components, those components are automatically selected. For example, if you select Oracle Platform Security Services, Oracle Audit Services is automatically selected.

Depending on the components you select, additional screens may display. For example, you may need to:

- Specify the domain directory.

- Specify schema credentials to connect to the selected schema: Database Type, DBA User Name, and DBA Password. 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.

Click Next to start the readiness check.

4. 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.

5. 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.

6. 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.

3.4.4 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 3-6 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

NEW_ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated log file.

No action required.

Readiness report location

NEW_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.

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: NEW_ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: NEW_ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.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
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
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
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ 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_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ 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 MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
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_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 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.3.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: FAILURE.

If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from 11g (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

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.

3.5 Stopping Servers and Processes

Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.

An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components such as Identity Management components, and a database used as a repository for metadata. The components may be dependent on each other, so they must be stopped in the correct order.

Note:
The procedures in this section describe how to stop the existing, pre-upgrade servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager.

To stop your pre-upgrade Fusion Middleware environment, navigate to the pre-upgrade domain and follow the steps below:

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: Stop the Administration Server

When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To stop the Administration Server, use the stopWebLogic script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Step 5: Stop Node Manager

To stop Node Manager, close the command shell in which it is running.

Alternatively, after setting the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down. See stopNodeManager in Oracle Fusion Middleware WLST Command Reference for WebLogic Server.

3.6 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.

Topics:

- 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.

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Oracle WebCenter Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the 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.

3.6.1 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 acount 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.

3. Note the schema prefix name that was used for your existing schemas. You will use the same prefix when you create new 12c schemas.

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.2) upgrade procedures. Refer to your pre-upgrade version documentation for more information.

- Some components, such as Oracle Enterprise Data Quality, Oracle GoldenGate Monitor, and Oracle GoldenGate Veridata, support an upgrade from versions other than the standard Oracle Fusion Middleware supported versions.

- If you used an OID-based policy store in 11g, 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.2). Do not attempt to upgrade a domain that includes components that are not yet available for upgrade to 12c (12.2.1.2).

3.6.2 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure 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, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. 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:

Topics:

- Upgrade Assistant Parameters

3.6.2.1 Upgrade Assistant Parameters

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

Table 3-7 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

3.6.3 Upgrading Oracle WebCenter Schemas Using the Upgrade Assistant

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

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 Selected Schemas screen, select the schema upgrade operation that you want to perform:

- Individually Selected Schemas if you want to select individual schemas for upgrade and you do not want to upgrade all of the schemas used by the domain.

Caution:
Upgrade only those schemas that are used to support your 12c (12.2.1.2) components. Do not upgrade schemas that are currently being used to support components that are not included in Oracle Fusion Middleware 12c (12.2.1.2).

- All Schemas Used by a Domain to allow 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.

Note:
Oracle recommends that you select All Schemas Used by a Domain for most upgrades to ensure all of the required schemas are included in the upgrade.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. When you select a component, the schemas and any dependencies are automatically selected.

4. 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.

5. On the Schema Credentials screen(s), specify the database connection details for each schema you are upgrading (the screen name changes based on the schema selected):

- Select the database type from the Database Type drop-down menu.

- Enter the database connection details, and click Connect.

- Select the schema you want to upgrade from the Schema User Name drop-down menu, and then enter the password for the schema. Be sure to use the correct schema prefix for the schemas you are upgrading.

Note:
The component ID or schema name is changed for UCSUMS schema as of release 12.1.2, which means the Upgrade Assistant does not automatically recognize the possible schemas and display them in a drop-down list. You must manually enter the name in a text field. The name can be either prefix_ORASDPM or prefix_UMS, depending on the starting point for the upgrade.
11g to 12c Upgrades Only: The UCSUMS schema is not auto-populated. Enter prefix_ORASDPM as the user. The upgrade environment uses _ORASDPM as the schema name, whereas in the 12c environment it is referred to as _UMS.

6. 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 Oracle Fusion Middleware Upgrading with the Upgrade Assistant Upgrade Guide 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.

7. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
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 Upgrade to start the upgrade process.

8. 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.

9. If the upgrade is successful: On the Upgrade Success screen, 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.

3.6.4 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.2.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.

3.7 About Reconfiguring the Domain

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

When you reconfigure a WebLogic Server domain, the following items are automatically updated, depending on the applications in the domain:

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

Specifically, when you reconfigure a domain, the following occurs:

- The domain version number in the config.xml file for the domain is updated to the Administration Server's installed WebLogic Server version.

- Reconfiguration templates for all installed Oracle products are automatically selected and applied to the domain. These templates define any reconfiguration tasks that are required to make the WebLogic domain compatible with the current WebLogic Server version.

- Start scripts are updated.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
When the domain reconfiguration process starts, you can’t undo the changes that it makes. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. If an error or other interruption occurs while running the Reconfiguration Wizard, you must restore the domain by copying the files and directories from the backup location to the original domain directory. This is the only way to ensure that the domain has been returned to its original state before reconfiguration.

Follow these instructions to reconfigure the existing domain using the Reconfiguration Wizard. See Reconfiguring WebLogic Domains in Oracle Fusion Middleware Upgrading Oracle WebLogic Server.

Topics:

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the Domain with the Reconfiguration Wizard
Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing domain.

3.7.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup of the domain directory:

1. Copy the source domain to a separate location to preserve the contents.
(Windows) copy C:\domains\mydomain to C:\domains\mydomain_backup.

(UNIX) cp mydomain /domains/mydomain_backup

2. Before updating the domain on each remote Managed Server, create a backup copy of the domain directory on each remote machine.

3. Verify that the backed up versions of the domain are complete.

If domain reconfiguration fails for any reason, you must copy all files and directories from the backup directory into the original domain directory to ensure that the domain is returned entirely to its original state before reconfiguration.

3.7.2 Starting the Reconfiguration Wizard

Note:
Shut down the administration server and all collocated managed servers before starting the reconfiguration process. See Stopping Servers and Processes.

To start the Reconfiguration Wizard in graphical mode:

1. Sign in to the system on which the domain resides.

2. Open the command shell (on UNIX operating systems) or open a command prompt window (on Windows operating systems).

3. Edition Based Database Users Only: If your schemas are configured with EBR database, a default edition name must be manually supplied before you run the Reconfiguration Wizard.
Run the following SQL command to set the default edition:
ALTER DATABASE DEFAULT EDITION = edition_name;

where edition_name is the child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

where log_file is the absolute path of the log file you'd like to create for the domain reconfiguration session. This can be helpful if you need to troubleshoot the reconfiguration process.

The parameter -log_priority=ALL ensures that logs are logged in fine mode.

Note:

When you run this command, the following error message might appear to indicate that the default cache directory is not valid:

*sys-package-mgr*: can't create package cache dir

You can change the cache directory by setting the environment variable CONFIG_JVM_ARGS. For example:

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

3.7.3 Reconfiguring the Domain with the Reconfiguration Wizard

Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing domain.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain with the Reconfiguration Wizard:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.

Note:
By default Oracle’s Driver (Thin) for Service connections; Versions: Any is the selected driver. If you specified an instance name in your connection details — instead of the service name — you must select Oracle’s Driver (Thin) for pooled instance connections; Versions: Any If you do not change the driver type, then the connection will fail.

Note:
For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the RCU, the default connection data will be retrieved from the _STB schema. If no connection data for a given schema is found in the _STB schema, then the default connection data is used.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

Note:
If you are upgrading from 11g, and your database has _OPSS or _IAU 11g database schemas, you must manually enter database connection details for those schemas. These schemas were not required in 11g and had to be created manually. Users could assign any name to these schemas, therefore the Reconfiguration Wizard does not recognize them. When providing connection information for _IAU, use the IAU_APPEND user information.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

7. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain.

For this upgrade, select none of the options and click Next.

8. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

9. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

10. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

3.8 Upgrading Domain Component Configurations

After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

Topics:

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Domain Component Configurations Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

- Verifying the Domain-Specific-Component Configurations Upgrade
To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.

3.8.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure 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, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. 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:

Topics:

- Upgrade Assistant Parameters

3.8.1.1 Upgrade Assistant Parameters

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

Table 3-8 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

3.8.2 Upgrading Domain Component Configurations Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.

To upgrade domain component configurations 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 next screen:

- Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

- In the Domain Directory field, enter the WebLogic domain directory path.

Click Next.

3. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

4. 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.

5. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration 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 Oracle Fusion Middleware Upgrading with the Upgrade Assistant Upgrade Guide 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 configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

6. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

7. 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 components 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.

8. If the upgrade is successful: On the Upgrade Success screen, click Close to complete the upgrade and close the wizard. The Post-Upgrade Actions window describes the manual tasks you must perform to make components functional in the new installation. This window appears only if a component has post-upgrade steps.

If the upgrade fails: On the Upgrade Failure screen, click View Log to view and troubleshoot the errors. The logs are available at NEW_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.

3.8.3 Verifying the Domain-Specific-Component Configurations Upgrade

To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.

To sign in to the Administration Console, go to: http://administration_server_host:administration_server_port/console

To sign in to Oracle Enterprise Manager Fusion Middleware Control Console, go to: http://administration_server_host:administration_server_port/em

Note:

After upgrade, make sure you run the administration tools from the new 12c Oracle home directory and not from the previous Oracle home directory.

During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.

3.9 Performing Post-Upgrade Configuration Tasks

You may have to perform additional configuration tasks after an upgrade depending on which components are in your deployment.

Note:

You may have additional post-upgrade tasks if your deployment contains the following:

Performing Post Upgrade Tasks for WebCenter Content

Performing Post-Upgrade Tasks for Oracle WebCenter Portal

Topics:

- Starting and Stopping Administration Server

- Starting and Stopping the Node Manager

- Starting and Stopping the Managed Servers

- Verifying the New Applications Work as Expected

3.9.1 Starting and Stopping Administration Server

You can start and stop the Oracle WebLogic Server Administration Server using the WLST command line or a script. When you start or stop the Administration Server, you also start or stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

For example, to start an Administration Server, use the following script:

DOMAIN_HOME/bin/startWebLogic.sh

To stop an Administration Server, use the following script:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

3.9.2 Starting and Stopping the Node Manager

You can start Node Manager using the WLST command line or a script.

To start Node Manager, use the following script:

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

To stop Node Manager, close the command shell in which it is running.

3.9.3 Starting and Stopping the Managed Servers

To start or stop a WebLogic Server Managed Server using Fusion Middleware Control:

1. From the navigation pane, expand the domain.

2. Select the Managed Server.

3. From the WebLogic Server menu, choose Control, then Start Up or Shut Down.

Alternatively, you can right-click the server, then choose Control, then Start Up or Shut Down.

You can use a script or WLST to start and stop a WebLogic Server Managed Server.

For example, to start a WebLogic Server Managed Server, use the following script:

(UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh
managed_server_name admin_url
(Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd
managed_server_name admin_url

When prompted, enter your user name and password.

To stop a WebLogic Server Managed Server, use the following script:

(UNIX) NEW_DOMAIN_HOME/bin/stopManagedWebLogic.sh
managed_server_name admin_url username password
(Windows) NEW_DOMAIN_HOME\bin\stopManagedWebLogic.cmd
managed_server_name admin_url username password

3.9.4 Verifying the New Applications Work as Expected

Once all of the servers have been successfully started and stopped, open your component applications and make sure that everything is working as expected. Use your component-specific Administration and Developers guides to help you navigate the new features of your upgraded environment.

4 Upgrading Oracle WebCenter Content

The process of upgrading Oracle WebCenter Content from a supported 11g or previous 12c environment to an Oracle WebCenter Content 12c (12.2.1.2) environment includes some restrictions, prerequisites, and post upgrade tasks to be performed.

Topics:

- Understanding an Upgrade to Oracle WebCenter Content 12c
An upgrade of Oracle WebCenter Content domain to 12c can include WebCenter Content, WebCenter Enterprise Capture, WebCenter Content Imaging, and WebCenter Content Web UI.

- WebCenter Content Domain Upgrade Restrictions
Certain components cannot be upgraded to 12c (12.2.1.2)

- Performing Pre-Upgrade Tasks for WebCenter Content
You may need perform additional Content-specific pre-upgrade tasks before you can upgrade WebCenter Content to 12c (12.2.1.2)

- Performing Pre-Upgrade Tasks for Oracle WebCenter Enterprise Capture
You must perform pre-upgrade tasks in order to upgrade WebCenter Enterprise Capture.

- Performing an Upgrade of Oracle WebCenter Content Imaging
It is not recommended to upgrade WebCenter Content Imaging for 11g users.

- Performing an Upgrade of Oracle WebCenter Content
WebCenter Content can be upgraded after performing the required pre-configuration tasks.

- Performing Post Upgrade Tasks for WebCenter Content
There are a few post upgrade tasks to be performed in order to successfully complete the WebCenter Content.

4.1 Understanding an Upgrade to Oracle WebCenter Content 12c

An upgrade of Oracle WebCenter Content domain to 12c can include WebCenter Content, WebCenter Enterprise Capture, WebCenter Content Imaging, and WebCenter Content Web UI.

What’s New in WebCenter Content 12c

WebCenter Content 12c now supports a single WebLogic Server domain for all WebCenter Content and Capture components. It does not, however, support a direct upgrade of the domain hosting the Oracle WebCenter Content - Web UI from Release 11g to 12c. You will need to decommission the existing 11g Web UI domain and then extend the target upgraded WebCenter Content 12c domain with the Web UI component.

4.2 WebCenter Content Domain Upgrade Restrictions

Certain components cannot be upgraded to 12c (12.2.1.2)

Oracle WebCenter Content users who are upgrading from 11g cannot upgrade to 12c (12.2.1.2)if Oracle Universal Records Management (URM) is enabled in the 11g domain. To upgrade, you must first reconfigure the domain to exclude URM. If you attempt an upgrade to 12c (12.2.1.2) with URM enabled, the upgrade will fail.

4.3 Performing Pre-Upgrade Tasks for WebCenter Content

You may need perform additional Content-specific pre-upgrade tasks before you can upgrade WebCenter Content to 12c (12.2.1.2)

The following tasks must be completed before you can upgrade your existing Oracle WebCenter Content and Content server environment:

Note:

You must complete all of the required Oracle WebCenter pre-upgrade tasks before performing the WebCenter Content-specific tasks. See Performing the Oracle WebCenter Pre-Upgrade Tasks

Topics:

- Upgrading the Metadata Schema (_MDS) Before Upgrading WebCenter Content Web UI 11g Domain
If you are upgrading an Oracle WebCenter Content Web UI 11g domain to 12c (12.2.1.2), then you must upgrade the _MDS schema before starting the domain upgrade.

4.3.1 Upgrading the Metadata Schema (_MDS) Before Upgrading WebCenter Content Web UI 11g Domain

If you are upgrading an Oracle WebCenter Content Web UI 11g domain to 12c (12.2.1.2), then you must upgrade the _MDS schema before starting the domain upgrade.

Note:

This step is required ONLY if you are upgrading a WebCenter Content Web UI domain Release 11g to Release 12c.

If you are only upgrading a WebCenter Content server domain, see Upgrading an Oracle WebCenter Domain.

The 12c (12.2.1.2)Web UI is not compatible with WebCenter Content 11g. You must use an Oracle WebCenter Content12c (12.2.1.2) and Application Developer Framework (ADF) 12c (12.2.1.2) container with Web UI 12c (12.2.1.2).

The MDS schema upgrade must be completed before upgrading WebCenter Content Web UI 11g because during the upgrade, the Upgrade Assistant will attempt to upgrade all schemas that are referenced from the domain. Because the MDS schema (which is not used by WebCenter Content proper) is only referenced in the 11g (decommissioned) domain, the upgrade process will not see it (nor upgrade it). By upgrading the MDS schema before starting the WebCenter Content domain upgrade, the Upgrade Assistant will upgrade that content as well.

Note:

After the _MDS schema is upgraded, proceed to the standard 12c upgrade process: Upgrading an Oracle WebCenter Domain. After the upgrade you may have to update the WccAdf.ear file as described in Updating the WccAdf.ear File (Optional) and extend the domain to include the Web UI as described in Configuring the Oracle WebCenter Content Server Domain to Include WebCenter Content - Web UI

Change directory to NEW_ORACLE_HOME/oracle_common/upgrade/bin on UNIX operating systems or NEW_ORACLE_HOME\oracle_common\upgrade\bin on Windows operating systems.

Enter the following command to start the Upgrade Assistant.

- (UNIX) ./ua

- (Windows) ua.bat

To upgrade the MDS schema, perform the following steps:

1. Start the Upgrade Assistant and select Individually Selected Schemas.

2. Provide the database credentials and the 11g schema owner name and password.

3. Choose Oracle Metadata Services from the component list.

4. During the Examine phase, make sure that the correct source version is being upgraded. If the correct source version is displayed, continue with the upgrade.

4.4 Performing Pre-Upgrade Tasks for Oracle WebCenter Enterprise Capture

You must perform pre-upgrade tasks in order to upgrade WebCenter Enterprise Capture.

Before upgrading Oracle WebCenter Enterprise Capture, review the following and complete all applicable tasks.

Once you have completed the Oracle WebCenter Enterprise Capture pre-upgrade tasks, go to section Upgrading an Oracle WebCenter Domain.

- Upgrade only standard (non Fusion Application) environments already running Oracle WebCenter Enterprise Capture.

- Upgrade all Oracle WebCenter Enterprise Capture systems within a clustered environment simultaneously.You can upgrade independent Oracle WebCenter Enterprise Capture systems separately.

- Identify a time to perform the updates that will not interfere with operations.
The services will be unavailable while the update is being performed.

- Stop the Oracle WebCenter Enterprise Capture server before upgrading.

Topics:

- Verify the Batch Processing has Completed and Capture JMS Queues are Empty

4.4.1 Verify the Batch Processing has Completed and Capture JMS Queues are Empty

Verify all batch processing completes and ensure that the Capture JMS queues are empty.

1. Open the Administration Console for this domain.

http://<AdminServerName>:7001/console

Where:

<AdminServerName> = is the name or IP address of the administration server associated with the Capture domain

7001 = the communication port associated with the administration server

2. In the "Domain Structure" navigation panel on the left, expand "Services".

3. Expand the "Messaging" node.

4. Select the "JMS Servers" item in the tree list.

5. Select the "capture-jms-server" item in the "JMS Servers" list in the main panel.

6. Select the "Monitoring" tab.

7. Select the "Monitoring" sub-tab.

8. Verify that the "Messages Current" and "Messages Pending" values in the table are both "0".

If either of these values is greater than zero, indicating pending jobs, wait until all jobs have been processed and these counters show "0" before proceeding.

4.5 Performing an Upgrade of Oracle WebCenter Content Imaging

It is not recommended to upgrade WebCenter Content Imaging for 11g users.

Note:

Oracle recommends that Oracle WebCenter Content Imaging 11g users should not upgrade to this release of Imaging. The full functionality of Imaging will not be available until a future release.

The WebCenter Content Imaging feature set is being merged from an independent component into the primary WebCenter Content server. This is part of an effort to simplify and consolidate the WebCenter product footprint. Users have the option to continue to run the 11g Imaging component independently while upgrading their other WebCenter and SOA components to 12c.

Note:

An in depth explanation of the these changes is provided in the My Oracle Support document WebCenter Imaging & Enterprise Capture 12c Upgrade Guidance To Customers (Doc ID 2064485.1).

Users who want to transition to 12c now, while maintaining their 11g Imaging environment, will upgrade their core 12c domain and reconstruct a new 11g domain to host the Imaging components. That process is outlined below.

1. Create a complete backup copy of your existing 11g environment.

2. Create a new, reconstructed 11g Imaging (IPM) instance in a new Oracle Home. Install only Imaging (IPM) into this new home (C).

For more information about installing WebCenter Content Imaging, see 11g WebCenter Content Imaging installation documentation.

This new instance is created from the original 11g product distribution and should be patched equivalently to the existing instance (A). The Opatch inventory command can provide a list of existing patches applied to the system.

Operation of this new, reconstructed domain (C) can be confirmed by connecting it to the existing Imaging and Process Management (IPM) database (C) and the 11g Universal Content Manager (UCM) and 11g SOA managed servers (A).

3. Upgrade in-place the original IPM, UCM, and SOA 11g domain (B) to create the new upgraded 12c domain (D). See Upgrading an Oracle WebCenter Domain.

Imaging Process Management is deprecated in 12.2.1, so IPM configurations will be removed as part of the 12c domain upgrade and reconfiguration process (D). You may need to manually remove IPM/Viewer JMS servers and the original IPM server.

See Performing Post Upgrade Tasks for WebCenter Content

4. The existing IPM database will not be affected by the upgrade, so the connection will still be in place (D). Connect the reconstructed 11g Imaging domain (C) to the new 12c managed servers (E).

4.6 Performing an Upgrade of Oracle WebCenter Content

WebCenter Content can be upgraded after performing the required pre-configuration tasks.

Once all of the pre-upgrade configuration tasks are complete, you can upgrade the WebCenter Content domain using the standard Fusion Middleware procedures described in Upgrading an Oracle WebCenter Domain.

After the upgrade you will need to perform additional post-upgrade configuration tasks as described in Performing Post Upgrade Tasks for WebCenter Content

4.7 Performing Post Upgrade Tasks for WebCenter Content

There are a few post upgrade tasks to be performed in order to successfully complete the WebCenter Content.

Complete these tasks after you have upgraded Oracle WebCenter Content.

Note:

These post-upgrade tasks should be done in addition to the general WebCenter post-upgrade tasks in Performing Post-Upgrade Configuration Tasks.

Topics:

- Configuring the Oracle WebCenter Content Server Domain to Include WebCenter Content - Web UI

- Configuring E-Business Suite AXF Schema After an Upgrade
After the upgrade you will need to run a script to update the endpoint configuration of the AXF schema.

- Removing IPM/Viewer JMS Servers for Oracle WebCenter Content: Imaging

- Removing the IPM Server for Oracle WebCenter Content: Imaging

- Updating the WccAdf.ear File (Optional)

- Migrating Custom Skins for WebCenter Content Web UI

- Upgrading Oracle Application Adapters for Oracle WebCenter Content

- Configuring the Report Library for Records Management in Content Server

- Using Fusion Middleware Control to Monitor IBR

- Starting Oracle WebCenter Content Server with SOA or BAM

4.7.1 Configuring the Oracle WebCenter Content Server Domain to Include WebCenter Content - Web UI

Extending the upgraded WebCenter Content Server domain to include the WebCenter Content Web UI components follows the standard WebLogic Server configuration procedures.

See Extending WebLogic Domains for detailed information about extending the domain with the Fusion Middleware Configuration Wizard.

To launch the Configuration Wizard:

On UNIX Operating Systems:

cd /12c_Oracle_Home/oracle_common/common/bin

./config.sh

On Windows Operating Systems:

cd \12c_Oracle_Home\oracle_common\common\bin

When prompted, select the WebCenter Content - Web UI - 12.2.1.2.0 template.

4.7.2 Configuring E-Business Suite AXF Schema After an Upgrade

After the upgrade you will need to run a script to update the endpoint configuration of the AXF schema.

After the upgrade, Oracle E-Business Suite (EBS) users can run the following script to update the Endpoint in the E-Business Suite Application Extension Framework (AXF) schema.

1. Navigate to the Universal Content Management (Oracle UCM) 12c (12.2.1.2) installation directory:
cd /12cOracle_HOME/wccontent/ucm/Distribution/EBSIntegration/R12

2. Copy the following files to the /bin directory of the database hosting the EBS AXF schema
EbsUpdateScript.sh and EbsUpdateTables.sql

3. Run the script from the /bin directory and when prompted provide the following information:
"Enter AXF User name on EBS Schema "

"Enter AXF Password on EBS Schema "

"Enter HostName where UCM is running "

"Enter Port where UCM is running "

Once you have provided this information, the EBS AXF schema will be updated.

4.7.3 Removing IPM/Viewer JMS Servers for Oracle WebCenter Content: Imaging

After the domain reconfiguration is complete, you may still have old servers displayed in your console. These JMS servers must be manually deleted after an upgrade.

To remove the IPM/Viewer JMS Servers:

1. Sign in to the console of the newly upgraded Administration Server:

http://host:port/console

2. From the console's navigation panel, click Messaging and select JMS Servers.

3. Select all JMS servers starting with IpmJmsServer and ViewerJmsServer and click Delete.

4.7.4 Removing the IPM Server for Oracle WebCenter Content: Imaging

After the domain reconfiguration is complete, you may still have old IPM servers displayed in your console. These servers must be manually deleted after an upgrade.

To remove the IPM Server:

1. Sign in to the console of the newly upgraded Administration Server:

http://host:port/console

2. From the console's navigation panel, click Environment and select Servers.

3. Select the IPM server(s) (IPM_server1) and click Delete.

4.7.5 Updating the WccAdf.ear File (Optional)

After the domain has been upgraded, you can manually modify the wccadf.ear file with the correct MDS partition details (those provided during the 11g installation.)

To update the wccadf.ear file, navigate to the following 11g directory and launch WLST in OFFLINE mode:

cd /<11g_MW_HOME>/oracle_common/common/bin/wlst.sh

wls:/offline> archive = getMDSArchiveConfig ('/ <12.2.1 wccadf.ear location>')

wls:/offline> archive.setAppMetadataRepository(repository='mds-<mds_repo_name>', partition='<11g_partition_name>', type='DB', jndi='jdbc/mds/<mds_repo_name>')

wls:/offline> archive.save()

For example:

archive = getMDSArchiveConfig('/12.2.1_Oracle_Home/wccontent/wccadf/WccAdf.ear')
archive.setAppMetadataRepository(repository='mds-WCCUIMDSREPO', partition='11.1.1.9.0_MDS_PARTITION', type='DB', jndi='jdbc/mds/WCCUIMDSREPO')
archive.save()

4.7.6 Migrating Custom Skins for WebCenter Content Web UI

If you applied a custom skin to the WebCenter Content - Web UI in 11g, then you will need to migrate to the new 12c deployment, the custom skins JAR file after the upgrade.

1. Uninstall the Oracle WebCenter Content -Web UI application from the 12.2.1 deployment. Use the Oracle Universal Installer (OUI) in -deinstall mode.

2. Delete the 12.2.1 oracle.wcc.adf.skin.custom library.

3. Deploy the 11g custom skin JAR file, oracle.wcc.adf.skin.custom (11.1, 11.1.1.8.1), to the 12.2.1 environment.

4. Reinstall the Oracle WebCenter Content - Web UI 12c application to pick up the new custom skin JAR file contents.

4.7.7 Upgrading Oracle Application Adapters for Oracle WebCenter Content

The Oracle WebCenter Content application adapters as described in Oracle Fusion Middleware Administering the Application Adapters for Oracle WebCenter contain manual steps for installing the adapters to their respective ERP system (EBS and PeopleSoft). In order to upgrade to from any previous release, these adapters must be reinstalled.

To reinstall the EBS adapter:

1. Follow the instructions in Compiling Oracle E-Business Suite Forms in Oracle Fusion Middleware Administering the Application Adapters for Oracle WebCenter to upgrade the AXF_CUSTOM.PLL module.

2. If you are configured for SSL, follow the instructions in Configuring the Integration for SSL in Oracle Fusion Middleware Administering the Application Adapters for Oracle WebCenter.

To reimport the PeopleSoft project, follow the instructions (steps 1-6) in Importing the Oracle PeopleSoft Project in Oracle Fusion Middleware Administering the Application Adapters for Oracle WebCenter.

4.7.8 Configuring the Report Library for Records Management in Content Server

If you plan to configure the Records Management feature in Content Server, you need to configure the report library for Records Management after creating the domain that includes the WebCenter Content Managed Server, before starting it for the first time. Without this library, you cannot check in any templates to Content Server.

For more information on configuring the report library for Records Management, see Configuring the Report Library for Records Management in Content Server in the Oracle Fusion Middleware Installing and Configuring Oracle WebCenter Content.

4.7.9 Using Fusion Middleware Control to Monitor IBR

If Inbound Refinery (IBR) is used, then the domain must be expanded to use the Oracle Enterprise Manager Plug-in for IBR template with Enterprise Manager Fusion Middleware Control to monitor IBR.

Note:
Inbound Refinery (IBR) 11g cannot be upgraded to 12c. You must install a new IBR to be used with your 12c environment.

The steps below describe how to expand the domain to include the Oracle Enterprise Manager Plug-in for IBR template.

1. Navigate to ECM_Home/common/bin/

2. Execute config.sh

./config.sh

3. Select Extend an existing Weblogic domain

4. Select the domain to be extended.

5. In the next screen, select Oracle Enterprise Manager Plugin for IBR

6. Click Extend to extend the domain with the IBR template.

4.7.10 Starting Oracle WebCenter Content Server with SOA or BAM

When WebCenter Content is integrated with Oracle SOA or Oracle Business Activity Monitoring (BAM), you must start SOA and BAM before starting Oracle WebCenter Content or Oracle Inbound Refinery (IBR).

For more information on launching WebCenter Content server from Fusion Middleware Control, see Getting Started with Administering Oracle WebCenter Content in Oracle Fusion Middleware Administering Oracle WebCenter Content

If you attempt to start the WebCenter Content server or IBR before starting Oracle SOA or BAM servers, then you may see the following error:

oracle.wsm.policymanager.PolicyManagerException:
WSM-02120 : Unable to connect to the policy access service.

5 Upgrading Oracle WebCenter Portal to 12c

You can upgrade your existing Oracle WebCenter Portal 11.1.1.7.0, 11.1.1.8.0, 11.1.1.9.0 installations to 12c (12.2.1.2).

Note:

To patch previous releases of Oracle WebCenter Portal 12c to release 12c (12.2.1.2), follow the generic upgrade procedure described in About the Oracle WebCenter Upgrade Process to 12c (12.2.1.2). There are no WebCenter Portal-specific pre- or post-upgrade tasks for moving to 12c (12.2.1.2).

This chapter describes the WebCenter Portal 11g-specific upgrade steps. Ensure that you follow the sequence of steps listed in About the Oracle WebCenter Upgrade Process to 12c (12.2.1.2), and have performed the required generic steps before you perform the upgrade tasks listed in this chapter.

This chapter includes the following topics:

Topics:

- Performing Pre-Upgrade Tasks for Oracle WebCenter Portal

- Upgrading Oracle WebCenter Portal 11g Installations

- Performing Post-Upgrade Tasks for Oracle WebCenter Portal

- Understanding the Impact of Upgrade on Deprecated Features

- Troubleshooting Oracle WebCenter Portal Upgrade Issues

5.1 Performing Pre-Upgrade Tasks for Oracle WebCenter Portal

Before you upgrade your existing Oracle WebCenter Portal environment, complete the following tasks:

Topics:

- Reassociating to a Database-Based Policy Store

- Exporting Metadata for Portlet Producer Applications

- Saving OmniPortlet and Web Clipping Configuration

- Migrating Portal Framework Applications

5.1.1 Reassociating to a Database-Based Policy Store

If your WebCenter Portal 11g environment uses a file-based policy store or Oracle Internet Directory (OID) as the policy store, you must reassociate the policy store to a database-based policy store before upgrading to Oracle WebCenter Portal 12c.

5.1.2 Exporting Metadata for Portlet Producer Applications

Oracle WebCenter Portal 11g provides various preconfigured portlet producers, which include OmniPortlet, Web Clipping, WSRP Parameter Form Portlet, sample WSRP portlet producers, and sample PDK-Java portlet producers. To migrate customizations or metadata of your 11g portlet producer applications, you must export the data from your 11g application before upgrading Oracle WebCenter Portal. In the upgraded instance, you can then import these customizations back into portlet producer applications.

You can export producer metadata to an EAR file by using the exportPortletClientMetadata WLST command. For information, see exportPortletClientMetadata in WebCenter WLST Command Reference.

5.1.3 Saving OmniPortlet and Web Clipping Configuration

If your 11g Oracle WebCenter Portal instance contains Web Clipping and OmniPortlets portlets, keep a copy of their HTTP proxy entries before you upgrade your WebCenter Portal instance.

1. Navigate to the provider.xml file in the 11g domain at the following location:

Web Clipping: 11g_DOMAIN_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools_11.1.1.x.0/randomly_generated_directory/war/WEB-INF/providers/webClipping/provider.xml

OmniPortlet: 11g_DOMAIN_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools_11.1.1.x.0/randomly_generated_directory/war/WEB-INF/providers/omniPortlet/provider.xml

2. Copy the HTTP proxy entries for Web Clipping and omniPortlet from the 11g provider.xml. For example:

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy.example.com</httpProxyHost>
<httpProxyPort>80</httpProxyPort>
<dontProxyFor>*.example.com</dontProxyFor>
</proxyInfo>

You will need to add these entries to the provider.xml files in your upgraded WebCenter Portal instance.

5.1.4 Migrating Portal Framework Applications

Note:
This pre-upgrade task is applicable if you want to migrate your 11.1.1.6.0, 11.1.1.7.0, 11.1.1.8.x, or 11.1.1.9.x Portal Framework application to WebCenter Portal 12c.

Oracle WebCenter Portal 11g supports the Portal Framework technology for creating and deploying Portal Framework applications (previously referred as custom portal applications) in JDeveloper. The Portal Framework technology is not available in WebCenter Portal 12c release. Oracle provides support for migrating a Portal Framework applications to WebCenter Portal. This support is available for migrating applications from release 11.1.1.6.0, 11.1.1.7.0, 11.1.1.8.x, or 11.1.1.9.x. The migrated application is available as a portal in WebCenter Portal 12c.

To migrate your Portal Framework application to WebCenter Portal 12c, you must first patch your existing environment to the latest patch available for Oracle WebCenter Portal 11.1.1.9.0 and then migrate the application to release 11.1.1.9.x. For information, see Migrating a Portal Framework Application to WebCenter Portal in Administering Oracle WebCenter Portal. After patching to WebCenter Portal release 11.1.1.9.x, you can upgrade to release 12c as described in About the Oracle WebCenter Upgrade Process to 12c (12.2.1.2).

5.2 Upgrading Oracle WebCenter Portal 11g Installations

The following table describes the tasks required to upgrade Oracle WebCenter Portal 11g to 12c.

Note:
In Oracle WebCenter Portal 11g, the default names of managed servers are WC_Spaces, WC_Portlet, WC_Collaboration, and WC_Utilities. In a fresh Oracle WebCenter Portal 12c installation, WC_Utilities, which hosted Analytics, is deprecated, and WC_Spaces is replaced by WC_Portal and hosts Analytics. When you upgrade from Oracle WebCenter Portal 11g to 12c, the default managed server names are not changed. Further, Analytics remains deployed on the WC_Utilities managed server.

Table 5-1 Upgrading from Oracle WebCenter Portal 11g

Step

Description

More Information

Run the upgradeWebCenterPortal WLST command if the node manager is set up and managed servers can been started from the Admin console

Run the upgradeWebCenterPortal WLST command to move the metadata from MDS to DB and upgrade security permissions.

Running the upgradeWebCenterPortal WLST Command

If the node manager is not set up:

- If upgrading from release 11.1.1.7.0 or 11.1.1.8.0 configured to use Folders_g-based Content Server: Migrate to FrameworkFolders and then run the upgradeWebCenterPortal WLST command

- If upgrading from 11.1.1.7.0 or 11.1.1.8.0 with no Content Server configured, or if upgrading from release 11.1.1.8.3+ using FrameworkFolders-based Content Server: Run the upgradeWebCenterPortal WLST command

Ensure that you migrate WebCenter Portal from Folders_g to FrameworkFolders and then run the upgradeWebCenterPortal WLST command.

- Migrating Folders_g to FrameworkFolders in Oracle Fusion Middleware Administering Oracle WebCenter Portal

- Running the upgradeWebCenterPortal WLST Command

Access the upgrade metrics

Optional.

Access the upgrade metrics for Oracle WebCenter Portal to analyze the upgrade performance. This must be done before you restart the servers.

Accessing Upgrade Metrics

Enable additional components on Content Server and restart the server

On Content Server, enable additional components like AutoSuggestConfig, DynamicConverter, and Imaging. Enable PortalVCRHelper if Site studio is configured. Then, restart Content Server.

Enabling or Disabling a Component Using the Component Manager

Restart the Administration Server and all the managed servers

Start your Oracle Fusion Middleware environment. This involves starting your Oracle WebLogic Server, Node Manager, Administration Server, managed servers, OPMN, and all system components.

Performing Post-Upgrade Configuration Tasks

Run the upgrade audit tool by running the listDeprecatedFeaturesUsage WLST command

Run the listDeprecatedFeaturesUsage WLST command to run the upgrade audit tool to view the list of deprecated features in your upgraded WebCenter Portal 12c installation.

Running the Upgrade Audit Tool

Topics:

- Running the upgradeWebCenterPortal WLST Command

- Running the Upgrade Audit Tool

- Accessing Upgrade Metrics

5.2.1 Running the upgradeWebCenterPortal WLST Command

Run the upgradeWebCenterPortal WLST command to move metadata from MDS to database and upgrade security permissions in your upgraded Oracle WebCenter Portal 11g installation.

To run the upgradeWebCenterPortal WLST command:

1. Navigate to your WebCenter Portal Oracle home directory and invoke the WLST script:

(UNIX) ORACLE_HOME/common/bin/wlst.sh

(Windows) ORACLE_HOME\common\bin\wlst.cmd

2. At the WLST command prompt, enter the following command to connect to the Administration Server for Oracle WebCenter Portal:

wls:/offline>connect('user_name','password', 'host_name:port_number')

where

- user_name is the username of the operator who is connecting to the Administration Server

- password is the password of the operator who is connecting to the Administration Server

- host_name is the host name of the Administration Server

- port_number is the port number of the Administration Server

For example:

connect(username='weblogic', password='mypassword', url='myhost.example.com:7001')

For help with this command, type help('connect') at the WLST command prompt.

3. Run the upgradeWebCenterPortal WLST command. For information about the command syntax, see upgradeWebCenterPortal in Oracle Fusion Middleware WebCenter WLST Command Reference. For information about the messages displayed and reports generated, see Output Generated by the upgradeWebCenterPortal WLST Command.

Topics:

- Output Generated by the upgradeWebCenterPortal WLST Command

5.2.1.1 Output Generated by the upgradeWebCenterPortal WLST Command

The upgradeWebCenterPortal WLST command generates the following reports:

- UpgradeSummary.txt: Lists the total number of portals or portal templates for which upgrade was attempted, succeeded, and failed.

- UpgradeDetails.txt: Shows detailed upgrade information for each portal, listing the details such as the number of pages, resource catalogs, navigations upgraded. Also shows the details of any upgrade errors reported for a portal.

- UpgradeDiagnostic.log: Shows the diagnostic information for the upgradeWebCenterPortal WLST command.

Each time you run the upgradeWebCenterPortal command, the reports get updated with the additional details from the last run. If there are upgrade errors reported at any step, fix the errors and run upgradeWebCenterPortal again. The upgrade process is considered complete when upgradeWebCenterPortal does not report any more failed attempts to upgrade any portals or portal templates, and its last output shows the message WebCenter Portal application upgrade is complete.

For information about troubleshooting the upgrade issues, see Troubleshooting Oracle WebCenter Portal Upgrade Issues.

Sample Command 1

When running the upgradeWebCenterPortal WLST command, you can specify the parameters depending on your requirements.

For example, the following command moves the metadata from MDS to DB and upgrades security permissions:

upgradeWebCenterPortal(appName='webcenter', server='WC_Spaces', migrationDirectory='/scratch/upgrade_log')

The following is the sample message displayed when you run this command:

Starting WebCenter Portal application upgrade.
Already in Domain Runtime Tree

To effect connection changes, you must restart the managed server on which the WebCenter application is deployed.
If you have set adminPassword, keystorePassword, or privateKeyPassword in your content server connection, then set the values again in the underlying RIDC connection. Do this by running setContentServerConnection and specifying the values, if applicable.

Starting data migration from MDS to database...

[TRACE]: Upgrade may take some time to complete depending on the number of portals and pages in your Oracle WebCenter Portal installation. To monitor the upgrade progress, refer to the diagnostic log file WC_Portal-diagnostic.log at the location "/scratch/software/user_projects/domains/base_domain/servers/WC_Spaces/logs".

#######################################################
Upgrade Run: 1
#######################################################
Upgrade of 44 Portals/Portal Templates attempted.
Upgrade of 44 Portals/Portal Templates succeeded.
Upgrade of 0 Portals/Portal Templates failed.

Data migration from MDS to database is successfully completed.

Policy URI For Authenticated Access: oracle/wss10_saml_token_service_policy

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04207: Matching Grantee not found: [GranteeEntry: codeSource=file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar principals=[]].

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04201: Cannot grant permission(s). Grant already exists for grantee [GranteeEntry: codeSource=null principals=[[AppRole: appID=webcenter name=s5f9c65ed_c93c_4467_96cf_06a82f3dad22#-#Spaces-User displayName=null description=null category=null uniquename=cn=s5f9c65ed_c93c_4467_96cf_06a82f3dad22\#-\#Spaces-User,cn=Roles,cn=webcenter,cn=opssSecurityStore,cn=JPSContext,cn=opssRoot guid=108CDE506D8A11E5BFE5CF1BB12B2942 members=[] classname=oracle.security.jps.service.policystore.ApplicationRole type=JPS_APPLICATION_ROLE]]].

Starting upgrade for portal roles...
Upgrade of the portal roles is complete.

Permissions upgrade completed with warnings

WebCenter Portal application upgrade is complete.

Note:

Running the upgradeWebCenterPermissions WLST command displays certain error messages that permissions already exist. For example:

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04201: Cannot grant permission(s). Grant already exists for grantee [GranteeEntry: codeSource=null principals=[[AppRole: appID=webcenter name=s5f9c65ed_c93c_4467_96cf_06a82f3dad22#-#Spaces-User displayName=null description=null category=null uniquename=cn=s5f9c65ed_c93c_4467_96cf_06a82f3dad22\#-\#Spaces-User,cn=Roles,cn=webcenter,cn=opssSecurityStore,cn=JPSContext,cn=opssRoot guid=108CDE506D8A11E5BFE5CF1BB12B2942 members=[] classname=oracle.security.jps.service.policystore.ApplicationRole type=JPS_APPLICATION_ROLE]]].

Such error messages do not affect any functionality. You can safely ignore the error messages and proceed with upgrading your WebCenter Portal instance.

Sample Command 2

The following sample command upgrades WebCenter Portal configured to use Content Server:

upgradeWebCenterPortal(appName='webcenter', server='WC_Spaces', migrationDirectory='/scratch/upgrade_log', contentServerName='UCM_server1', contentDbConnectionUrl='wccdbhost:wccdbport:wccdbsid',contentDbUserName='DEV_OCS')

The following is the sample message displayed when you run this command:

Starting WebCenter Portal application upgrade.

Restarting Content Server to verify whether the Node Manager is configured properly.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
.
Starting server UCM_server1 .............................................................................
Server with name UCM_server1 started successfully

Already in Domain Runtime Tree

Enter the password for OCS Schema owner : XXXXX

Starting migration to FrameworkFolders.

Starting export of Folders_g data.
Already in Domain Runtime Tree

Export of Folders_g data is complete.

Starting migration of WebCenter Content Server to FrameworkFolders.

Enabling 'FrameworkFolders' server components.
Already in Domain Runtime Tree

Enabling 'FrameworkFolders' server components is complete.

Starting update of Content Server general configuration.
Already in Domain Runtime Tree

Updating Content Server general configuration is complete.

Restarting Content Server.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
..
Starting server UCM_server1 .............................................................................................
Server with name UCM_server1 started successfully

Restarting Content Server is complete.

Migration of 'PersonalSpaces' folder and content from Folders_g to the FrameworkFolders data structure started.
Already in Domain Runtime Tree

Migration of 'PersonalSpaces' folder and content from Folders_g to the FrameworkFolders data structure is complete.
Already in Domain Runtime Tree

Migration of 'WebCenterSpaces-Root' folder and content from Folders_g to the FrameworkFolders data structure started.
Already in Domain Runtime Tree

Migration of 'WebCenterSpaces-Root' folder and content from Folders_g to the FrameworkFolders data structure is complete.

Starting update of Content Server general configuration.
Already in Domain Runtime Tree

Updating Content Server general configuration is complete.

Restarting Content Server.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
..
Starting server UCM_server1 ..................................................................
Server with name UCM_server1 started successfully

WebCenter Content Server migration to FrameworkFolders is complete.

Starting migration of WebCenter Portal data to FrameworkFolders.
Already in Domain Runtime Tree

Migration of WebCenter Portal data to FrameworkFolders is complete.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
...
Starting server UCM_server1 ........................................................................................
Server with name UCM_server1 started successfully

Already in Domain Runtime Tree

Shutting down the server WC_Portal with force=true while connected to AdminServer ...
.....
Starting server WC_Spaces .........................................................................................................................................................................................................
Server with name WC_Spaces started successfully

Migration to FrameworkFolders is complete.

Starting WebCenter Portal application upgrade.
Already in Domain Runtime Tree

To effect connection changes, you must restart the managed server on which the WebCenter application is deployed.
If you have set adminPassword, keystorePassword, or privateKeyPassword in your content server connection, then set the values again in the underlying RIDC connection. Do this by running setContentServerConnection and specifying the values, if applicable.

Starting data migration from MDS to database...

[TRACE]: Upgrade may take some time to complete depending on the number of portals and pages in your Oracle WebCenter Portal installation. To monitor the upgrade progress, refer to the diagnostic log file WC_Portal-diagnostic.log at the location "/scratch/software/user_projects/domains/base_domain/servers/WC_Spaces/logs".

#######################################################
Upgrade Run: 1
#######################################################
Upgrade of 44 Portals/Portal Templates attempted.
Upgrade of 44 Portals/Portal Templates succeeded.
Upgrade of 0 Portals/Portal Templates failed.

Data migration from MDS to database is successfully completed.

Policy URI For Authenticated Access: oracle/wss10_saml_token_service_policy

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04207: Matching Grantee not found: [GranteeEntry: codeSource=file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar principals=[]].

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04201: Cannot grant permission(s). Grant already exists for grantee [GranteeEntry: codeSource=null principals=[[AppRole: appID=webcenter name=s5f9c65ed_c93c_4467_96cf_06a82f3dad22#-#Spaces-User displayName=null description=null category=null uniquename=cn=s5f9c65ed_c93c_4467_96cf_06a82f3dad22\#-\#Spaces-User,cn=Roles,cn=webcenter,cn=opssSecurityStore,cn=JPSContext,cn=opssRoot guid=108CDE506D8A11E5BFE5CF1BB12B2942 members=[] classname=oracle.security.jps.service.policystore.ApplicationRole type=JPS_APPLICATION_ROLE]]].

Starting upgrade for portal roles...
Upgrade of the portal roles is complete.

Permissions upgrade completed with warnings

WebCenter Portal application upgrade is complete.

5.2.2 Running the Upgrade Audit Tool

In Oracle WebCenter Portal 12c, certain features such as polls and document task flows have been deprecated. Post upgrade, you can run the upgrade audit tool to list down the usage of all deprecated features in your upgraded WebCenter Portal installation.

Run the listDeprecatedFeaturesUsage WLST command to list the usage of deprecated features in your upgraded Oracle WebCenter Portal installation:

listDeprecatedFeaturesUsage(appName='webcenter', server='WC_Spaces', reportDirectory='/scratch/audit', portal='portal1, portal2')

where:

- appName is the WebCenter Portal application where deprecated features need to be audited.

- server is the managed server on which WebCenter Portal is deployed.

- reportDirectory is the path to the writable directory where audit report will be generated.

- portal is the list of specific portals that you want to audit. You can pass comma separated list of portal names. It is an optional parameter. If you do not specify this parameter, report is generated for the entire WebCenter Portal application.

For example, the following command generates the audit report for the WebCenter Portal application deployed on the WC_Spaces managed server and stores the report in the /scratch/audit folder:

listDeprecatedFeaturesUsage(appName='webcenter', server='WC_Spaces', reportDirectory='/scratch/audit')

When you generate the upgrade audit report for the entire WebCenter Portal application, the following files are generated in the auditReport subdirectory under the directory specified for the reportDirectory parameter in the WLST command:

- summary.txt: Lists the portals and portal templates that contain deprecated features and specifies the number of artifacts that contain deprecated features, as shown in Figure 5-1.

- connections.txt: Lists the deprecated connections in WebCenter Portal.

Note:

You must remove the deprecated connections otherwise there might be some functionality issues.

- A .txt file for each portal and portal template containing deprecated features: Lists the artifacts (such as pages, page templates, and resource catalogs) that contain deprecated features and specifies name of the deprecated feature. Figure 5-3 shows the audit report for a specific portal.

Figure 5-1 Upgrade Audit Report - summary.txt

Figure 5-2 Upgrade Audit Report - connections.txt

Figure 5-3 Upgrade Audit Report for a Portal

The following example generates the audit report only for a portal named MyPortal. This will generate only the MyPortal.txt file. The connections and summary files are not generated for a portal.

listDeprecatedFeaturesUsage(appName='webcenter', server='WC_Spaces', reportDirectory='/scratch/audit', portal='MyPortal')

In your upgraded WebCenter Portal, if a portal page contains a deprecated feature, the feature appears blank in the page view mode. In the page edit mode, a message displays that the feature is deprecated and lists the action required. For example, Figure 5-4 shows deprecated Polls tasks flows listed in the page editor. Note that the message specifies that you should remove the deprecated task flows.

Figure 5-4 Deprecated Task Flows in Page Editor in the Upgraded WebCenter Portal Instance

5.2.3 Accessing Upgrade Metrics

You can use Oracle Dynamic Monitoring Service (DMS) to view upgrade metrics and analyze how much time was taken for the overall upgrade process and for each portal and its WebCenter Service handlers.

To access upgrade metrics:

1. Access DMS Spy Servlet using the following URL format:

http://host:port/dms/Spy

Where host:port refer to the location where Oracle WebCenter Portal is installed.

2. Sign in as an administrator.

3. Locate the webcenter_upgrade metric in the left pane.

The upgrade metrics for each portal are displayed in milliseconds.

4. View the upgrade processing time for your portal. For each portal, the following metrics are relevant: upgradeProcessingTime and cleanupProcessingTime.

The metrics also display the total processing time taken for the entire upgrade of Portal Server

If required, you can save this report as a PDF for future reference. The upgrade metrics are lost when you restart the servers.

5. Locate webcenter_upgrade_portal metric in the left column.

The upgrade metrics shows how long each WebCenter Service handler took for upgrade processing per portal. It shows the breakdown of the time taken for upgrading each portal.

5.3 Performing Post-Upgrade Tasks for Oracle WebCenter Portal

Complete the post-upgrade tasks after you have upgraded Oracle WebCenter Portal.

Topics:

- Upgrading 11g Portlet Producers

- Restoring OmniPortlet and Web Clipping Configuration

- Removing Duplicate Portal Pages

- Verify the Content Server Connection is Upgraded

- Upgrading WebCenter Portal 11g Assets to 12c

5.3.1 Upgrading 11g Portlet Producers

In an upgraded Oracle WebCenter Portal instance, 11g portlets are not accessible. To ensure that portlets are available, you must migrate the required portlet producer applications to release 12c. You must also import portlet producer customizations and redeploy your portlet producer applications.

This topic includes the following:

Topics:

- Migrating a Portlet Producer Application

- Redeploying a Portlet Producer Application

- Migrating Customizations

5.3.1.1 Migrating a Portlet Producer Application

To migrate an 11g portlet producer application to release 12c:

1. Install Oracle JDeveloper 12c.

Oracle JDeveloper provides an integrated development environment (IDE) for developing portals and custom portal components. For information on obtaining and installing Oracle JDeveloper, see the Oracle JDeveloper page on OTN at:

http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

2. Install the Oracle WebCenter Portal extension bundle. For information, see Installing the WebCenter Portal Extensions for JDeveloper in Oracle Fusion Middleware Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.

3. Start JDeveloper 12c.

4. Open your 11g portlet producer application.

This invokes the migration wizard, which is displayed every time an 11g application is opened in JDeveloper 12c.

5. On the Confirmation page, the Yes option is selected by default. Click Next to confirm that you want to migrate your application.

6. On the Java Web Projects page, click Next to specify that you want to migrate projects created using JavaServer Pages JSTL to the latest versions.

7. Click Finish to begin upgrading your application.

A progress dialog displays while the upgrade process executes.

8. When the application upgrade is complete, the Migration Status dialog displays the list of projects that have been upgraded. Click OK.

The upgraded application is opened and its projects are listed in the Application Navigator. If there are any errors during application upgrade, they are listed in the Message - Log window.

5.3.1.2 Redeploying a Portlet Producer Application

You can deploy your upgraded portlet producer application to any Oracle WebLogic Server managed server configured to support Oracle WebCenter Portal's portlet producers. For deployment, you can use Oracle Enterprise Manager Fusion Middleware Control, Oracle WebLogic Server Administration Console, or Oracle WebLogic Scripting Tool (WLST). For information, see Deploying Portlet Producer Applications in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

You can also deploy portlet producer applications to an Oracle WebLogic Server instance directly from a development environment by using JDeveloper, provided you have the required credentials to access the WebLogic server. For information, see Deploying the Preconfigured Portlet Producers in Oracle Fusion Middleware Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.

5.3.1.3 Migrating Customizations

After upgrading portlet producers, you must import their customizations if the customizations are not shared or accessible to the upgraded portlet producers. You import customizations from the EAR that you exported as described in Performing Pre-Upgrade Tasks for Oracle WebCenter Portal.

To import customizations, use the importPortletClientMetadata WLST command. For information, see importPortletClientMetadata in WebCenter WLST Command Reference.

5.3.2 Restoring OmniPortlet and Web Clipping Configuration

After you saved your OmniPortlet and Web Clipping configuration (as described in Saving OmniPortlet and Web Clipping Configuration) and successfully upgraded Oracle WebCenter Portal instance, you must restore them.

1. Navigate to the provider.xml file in the upgraded domain at the following location:

Web Clipping: ORACLE_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools/randomly_generated_directory/war/WEB-INF/providers/webClipping/provider.xml

OmniPortlet: ORACLE_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools/randomly_generated_directory/war/WEB-INF/providers/omniPortlet/provider.xml

2. Paste the HTTP proxy entries for Web Clipping and omniPortlet from the 11g provider.xml file. For example:

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy.example.com</httpProxyHost>
<httpProxyPort>80</httpProxyPort>
<dontProxyFor>*.example.com</dontProxyFor>
</proxyInfo>

3. Save the files.

5.3.3 Removing Duplicate Portal Pages

In Release 11.1.1.7.0, pages in the navigation of a portal (previously referred as a space) are from a page query. When you upgrade to 12c, each of those pages is added to the navigation, which leads to duplicate pages getting created in your portal. You can delete the duplicate pages as described in Deleting a Page in Building Portals with Oracle WebCenter Portal.

5.3.4 Verify the Content Server Connection is Upgraded

After you have run the upgradeWebCenterPortal command successfully, verify that the Content Server connection has been upgraded by running the listContentServerConnections WLST command. For information, see listContentServerConnections in Oracle Fusion Middleware WebCenter WLST Command Reference.

If the output of the listContentServerConnections WLST command shows the following message, run upgradeWebCenterPortal again to upgrade the Content Server connection.

The underlying RIDC connection is missing.

5.3.5 Upgrading WebCenter Portal 11g Assets to 12c

To use WebCenter Portal 11g assets in your upgraded WebCenter Portal 12c instance, you must upgrade the assets. For example, you can upgrade your 11g skins, page templates, or page styles to use them in your upgraded 12c portals.

To upgrade an 11g WebCenter Portal asset to 12c:

1. In Oracle JDeveloper 11g, open the application that contains the asset you want to upgrade.

2. Copy the source code of the required asset. For example, copy the source code of a skin from its CSS file.

3. In Oracle JDeveloper 12c, create a WebCenter Portal asset application, specifying the required asset type. For example, if you want to upgrade a skin asset, create an asset application specifying Skin as the Asset Type.

For information, see Creating a WebCenter Portal Asset Application in Oracle Fusion Middleware Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.

4. Remove the source code from the newly created asset application, and paste the 11g source code of the asset, which you copied in step 2. For example, in your skin asset application, remove the source code and paste the source code that you copied from the 11g CSS file.

5. Save the asset application.

6. Deploy the asset application to WebCenter Portal 12c as a shared asset or to a specific portal. For information, see Publishing WebCenter Portal Assets in Oracle Fusion Middleware Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.

5.4 Understanding the Impact of Upgrade on Deprecated Features

This topic describes the upgrade impact on 11g features that have been deprecated in release 12c.

It includes the following topics:

Topics:

- Portal-Level Device Settings

- Hierarchical Portals

- Deprecated Portlets

5.4.1 Portal-Level Device Settings

Device settings control how portals render on different kinds of devices including desktop browsers, smart phones, and tablets. In release 12c, device settings can be configured only at the WebCenter Portal application level, and not for individual portals. When you upgrade to release 12c, any portal-level customization done for device settings are lost. Only application-level device settings are applied to the upgraded WebCenter Portal instance.

5.4.2 Hierarchical Portals

Release 11g supported portal hierarchy consisting of a parent portal and its subportals, where by default subportals inherited security defined in the parent portal. When you upgrade WebCenter Portal to release 12c, subportals are moved as top-level portals. During upgrade, for each such upgraded portal, the following two attributes are added:

- 11g.upgraded.portal.parent.guid - Specifies the ID of the parent portal.

- 11g.upgraded.portal.parent.security.id - If present, specifies the portal from which security was inherited. If the value is null, it indicates that the subportal did not inherit the security from a parent portal and the subportal managed its own security.

5.4.3 Deprecated Portlets

In 12c, Web Clipping portlets and the rich text portlets have been deprecated. If an upgraded portal page includes a deprecated portlet, the page displays the Remote Portlet Error. You must either remove the deprecated portlets from the page or replace them with their 12c equivalent.

In 12c, Pagelet Producer replaces the functionality of Web Clipping portlets available in earlier releases of WebCenter Portal. Content contribution and publishing components replace the functionality of rich text portlets.

5.5 Troubleshooting Oracle WebCenter Portal Upgrade Issues

This topic describes the solutions to the issues you might encounter while upgrading WebCenter Portal to the latest release.

Topics:

- Extra Entries Appear for the ACTIVITIES Schema

- Floating Toolbar Not Available for Custom Page Templates

- Running the Predeployment Tool does not Update 11g Portlet Producers

- Handling Errors While Upgrading Oracle WebCenter Portal

- Errors on Accessing Documents/Blogs/Wiki Pages in an Upgraded Portal

- Portal Upgrade Fails

5.5.1 Extra Entries Appear for the ACTIVITIES Schema

Problem

In the upgraded WebCenter Portal 12c instance, extra entries are shown for the ACTIVITIES schema.

Solution

In release 12c, Activity Graph is deprecated. When you upgrade from an 11g release, the existing Activity Graph entries are not removed. However, these entries are not present in the ACTIVITIES schemas when you install a fresh instance of Oracle WebCenter Portal 12c.

5.5.2 Floating Toolbar Not Available for Custom Page Templates

In your upgraded WebCenter Portal instance, for upgraded portals that include pages supporting content contribution and use a custom page template developed in a prior release, the floating toolbar is not available. To enable the floating toolbar, add it to the custom page template. For information, see Adding a Floating Toolbar to a Page Template in Oracle Fusion Middleware Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.

5.5.3 Running the Predeployment Tool does not Update 11g Portlet Producers

WebCenter Portal provides a predeployment tool that adds the required configuration to a portlet producer application's EAR file to expose the portlets over WSRP. You cannot directly run the predeployment tool on portlet EARs from 11g versions. You need to migrate the portlet producer application in Oracle JDeveloper, regenerate the EAR, and then run the predeployment tool. For information about migrating portlet producers, see Upgrading 11g Portlet Producers. For information about running the predeployment tool, see Managing Portlet Producers in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

5.5.4 Handling Errors While Upgrading Oracle WebCenter Portal

While upgrading Oracle WebCenter Portal, you might encounter error messages. The following are some of the error messages displayed when you run the upgradeWebCenterPortal WLST Command.

Error Message 1

Upgrade ends with one of the following messages:

- Migration of Content Server from Folders_g to FrameworkFolders failed, Check MigrationDiagnostic.log for further details.
- An error occurred during migration, Check MigrationDiagnostic.log for further details.

Error Message 2

Upgrade ends with following message:

- Export of Folders_g data failed.
- Updating Content Server general configuration failed.
- Migration of <folder name> folder and content from Folders_g to the FrameworkFolders data structure failed.
- Migration of WebCenter Portal data to FrameworkFolders failed.
- Enabling <component name> server components failed.
- Disabling <component name> server components failed.
- Migration to FrameworkFolders failed.

Error Message 3

Upgrade ends with following message:

- WebCenter Content Server foldering service is not supported. Supported foldering service is FrameworkFolders version 2.1 and above.

Solution

To fix the issues, you need to:

1. Restore WebCenter Content Server.

2. Migrate from Folders_g to FrameworkFolders manually, as described in "Migrating Folders_g to FrameworkFolders" in Oracle Fusion Middleware Administering Oracle WebCenter Portal.

3. Run the following command:

upgradeWebCenterPortal(appName='webcenter', server='WC_Spaces', migrationDirectory='/tmp/upgrade',contentServerName='UCM_server1')

For more information about the command, see upgradeWebCenterPortal in Oracle Fusion Middleware WebCenter WLST Command Reference.

5.5.5 Errors on Accessing Documents/Blogs/Wiki Pages in an Upgraded Portal

After upgrade, on accessing the Documents, Blogs, or Wiki pages of an upgraded portal, if there are any errors, check the Content Server whether the upgrade has completed properly using the following steps:

1. Sign in to Content Server using the following URL format: host:port/cs

2. Navigate to Enterprise Libraries, and identify the portal's folder name.

3. Access the following URL format:
host:port/cs/idcplg?IdcService=FLD_INFO&path=/Enterprise Libraries/portal-folder-name&IsSoap=1

4. In the resulting output, search for fApplicationGUID. If it contains uppercase GUID, contact Oracle Support.

5.5.6 Portal Upgrade Fails

While upgrading Oracle WebCenter Portal if the upgrade of a portal fails, review the logs to identify the issue. In UpgradeDetails.txt, search for issue keywords like NAMESPACE or DOCUMENT_DEF to find the related exception stack for more details. This topic describes the scenarios for troubleshooting portal upgrade failure.

Error Message 1

In UpgradeDetails.txt, when you search for DOCUMENT_REF for the portal that failed to be upgraded, the following entry is displayed:

- java.sql.SQLException: ORA-12899: value too large for column "DEV_WEBCENTER"."WC_PORTAL_ENTITY"."DOCUMENT_REF"

Solution

One of the possible causes of portal upgrade failure can be that space.xml contains the binary or encoded content for the logo and icon attributes, and the value of these attributes exceeds the character limit. Modify the value for both the attributes by replacing the binary content with the MDS path for the logo and icon files. After you have successfully upgraded the portal, you can again change the portal logo and icon as required.

To fix the issue:

1. Export space.xml from MDS for the target portal using the importMetadata WLST command.
For example, the following command exports spaces.xml for a portal named MyPortal to the specified location:

exportMetadata(application='webcenter', server='WC_Spaces', toLocation='/scratch/export', docs='/oracle/webcenter/space/metadata/spaces/MyPortal/space.xml')

For information about the exportMetadata WLST command syntax, see exportMetadata in Oracle Fusion Middleware WLST Command Reference for Infrastructure Components.

2. Verify the value of the Icon and Logo attributes in the exported space.xml file. If the value of these attributes begins with data:image, edit the attributes with the following values and save the file.

- Icon: /oracle/webcenter/siteresources/scopedMD/shared/images/portalnew_icon.png

- Logo: /oracle/webcenter/siteresources/scopedMD/shared/images/portalnew_logo.png

3. Import the modified space.xml file using the importMetadata WLST command.
For example, the following command exports spaces.xml for MyPortal from the specified location:

importMetadata(application='webcenter',server='WC_Spaces',fromLocation='/scrat ch/export',docs='/oracle/webcenter/space/metadata/spaces/MyPortal/space.xml')

For information about the importMetadata WLST command syntax, see importMetadata in Oracle Fusion Middleware WLST Command Reference for Infrastructure Components.

4. Upgrade your Portal Framework application again.

5. Once your portal is upgraded successfully, log on to WebCenter Portal, navigate to your portal, and modify the logo and icon of the portal as per your requirement. For information, see Administering Look and Feel Settings for a Portal in Oracle Fusion Middleware Building Portals with Oracle WebCenter Portal.

Error Message 2

In UpgradeDetails.txt, when you search for NAMESPACE for the portal that failed to be upgraded, the following entry is displayed:

java.sql.SQLException: ORA-12899: value too large for column "DEV_WEBCENTER"."WC_PORTAL_ENTITY"."NAMESPACE"

Solution

One of the possible causes of this issue can be that the value of a portal resource’s title attribute exceeds the limit of 200 characters. Modify the value not to exceed the character limit.

1. Review the UpgradeDetails.txt file to identify the portal resource that is causing the issue.
For example, suppose the title of a page definition file named Page20PageDef.xml exceeds 200 characters.

2. Export the portal resource using the exportMetadata WLST command.
The following code exports shows that the Page20PageDef.xml file is exported to the specified location:

exportMetadata(application='webcenter', server='WC_Spaces', toLocation='/scratch/export', docs='/pageDefs/oracle/webcenter/page/scopedMD/sfe492158_7b1a_421c_a242_37897a 2529e7/Page20PageDef.xml')

For information about the exportMetadata WLST command syntax, see exportMetadata in Oracle Fusion Middleware WLST Command Reference for Infrastructure Components.

3. Edit the value of exported resource’s page_title and page_info attributes to be less than 200 characters.

4. Import the portal resource using the importMetadata WLST command. For example, the following command imports the updated Page20PageDef.xml from the specified location:

importMetadata(application='webcenter',server='WC_Spaces',fromLocation='/scrat ch/export', docs='/pageDefs/oracle/webcenter/page/scopedMD/sfe492158_7b1a_421ca242_37897a 2529e7/Page20PageDef.xml')

For information about the importMetadata WLST command syntax, see importMetadata in Oracle Fusion Middleware WLST Command Reference for Infrastructure Components.

5. Upgrade your Portal Framework application again.

6 Upgrading Oracle WebCenter Sites to 12c

You can upgrade your existing Oracle WebCenter Sites installations to 12c (12.2.1.2).

Upgrading from 11g to 12c is an out-of-place migration. This includes using the Upgrade Assistant to migrate data tables and platform configuration.

Upgrading from a previous 12c release (12.2.1.0, 12.2.1.0 Patch 1, 12.2.1.0 Patch 2, and 12.2.1.1) to 12.2.1.2 is an in-place upgrade.

Note:

There are two approaches that you can consider while upgrading depending on your requirement:

1. You can upgrade the delivery environment and clone it after the upgrade to create development and management environments.
If you consider this approach, synchronization is required. You must publish the contents from your development and management environments in to the delivery environment before the upgrade. You can then clone your upgraded delivery environment to create development and management environments.

2. Alternatively, you can upgrade each environments individually.
If you consider this approach, synchronization is not required.

This chapter includes the following topics:

Topics:

- Upgrading WebCenter Sites from 11g to 12c
Upgrading from 11g to 12c is an out-of-place migration. This includes using the Upgrade Assistant to migrate data tables and platform configuration.

- Upgrading WebCenter Sites from a Previous 12c Release
The valid 12c starting point for upgrading WebCenter Sites to 12.2.1.2 are WebCenter Sites releases 12.2.1.0, 12.2.1.0 Patch 1, 12.2.1.0 Patch 2, and 12.2.1.1. This is an in-place upgrade.

- Migrating Custom Java Libraries or Static Web Resources
Perform this optional step only if custom Java libraries or static web resources were added to the web application in your pre-upgrade environment and you want to continue to use them in the upgraded environment.

6.1 Upgrading WebCenter Sites from 11g to 12c

Upgrading from 11g to 12c is an out-of-place migration. This includes using the Upgrade Assistant to migrate data tables and platform configuration.

The valid 11g starting point for upgrading WebCenter Sites to 12.2.1.2 is WebCenter Sites 11.1.1.8.0 and 11.1.1.8.0 Patch 12+. This is an out-of-place migration.

Note:

There are two approaches that you can consider while upgrading depending on your requirement:

1. You can upgrade the delivery environment and clone it after the upgrade to create development and management environments.
If you consider this approach, synchronization is required. You must publish the contents from your development and management environments in to the delivery environment before the upgrade. You can then clone your upgraded delivery environment to create development and management environments.

2. Alternatively, you can upgrade each environments individually.
If you consider this approach, synchronization is not required.

Note:
If you are upgrading from 11.1.1.6.x, you must upgrade to release 11.1.1.8 using WebCenter Sites 11g upgrade procedure documented in About the WebCenter Sites Upgrade Process, Fusion Middleware WebCenter Sites Upgrade Guide.

To upgrade WebCenter Sites from 11g to 12c, complete the following tasks:

Topics:

- About the WebCenter Sites Upgrade Process from 11g to 12c
Review the flowchart and the roadmap for an overview of the upgrade process for Oracle WebCenter Sites.

- Installing the Product Distribution
Before beginning your upgrade, download the 12c (12.2.1.2) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions on the target system and install them using Oracle Universal Installer.

- Creating the Required 12c Schemas with the RCU
When upgrading from 11g, you must create the required 12c schemas. You can use the Repository Creation Utility (RCU) to create customized schemas or, optionally, you can use the Upgrade Assistant to create schemas using the default schema settings. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures.

- Configuring the WebCenter Sites Domain
If you are upgrading from WebCenter Sites 11g to 12c, then you must configure the WebCenter Sites domain using the Configuration Wizard.

- Configuring WebCenter Sites Instance
After you configure the Oracle WebCenter Sites domain, you can configure a WebCenter Sites instance by completing the browser-based WebCenter SitesConfigurator. WebCenter Sites runtime consists of WebCenter Sites and CAS web applications (WAR files) and the following components shared across cluster members: a config directory, a data directory, and a database instance.

- Post-Configuration Tasks
After configuring the WebCenter Sites 12c, complete the tasks listed in this topic.

- Before Running the Upgrade Assistant
Before running the Upgrade Assistant to upgrade from 11.1.1.8, complete the tasks listed in this topic.

- 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.

- Upgrading Domain Component Configurations
After you upgrade the product schemas, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Post-Upgrade Validation Tasks
Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

- Post-Upgrade Tasks
The post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in this topic.

6.1.1 About the WebCenter Sites Upgrade Process from 11g to 12c

Review the flowchart and the roadmap for an overview of the upgrade process for Oracle WebCenter Sites.

Figure 6-1 Upgrade Process Flowchart for WebCenter Sites from 11g to 12c Release

Table 6-1 provides a roadmap for tasks that you must perform to upgrade WebCenter Sites from 11g to 12c.

Table 6-1 Tasks for Upgrading WebCenter Sites from 11g to 12c Release

Task

Description

Required

If you have not done so already, review the introductory topics in this guide and complete the required pre-upgrade tasks.

The pre-upgrade tasks include cloning your production environment, verifying system requirements and certifications, purging unused data, and creating non-SYSDBA user.

For a complete list of pre-upgrade tasks, see Pre-Upgrade Tasks for Oracle WebCenter Components.

Required

Download and install the 12c (12.2.1.2) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions.

The Infrastructure distribution packs the WebLogic Server and the Java Required Files (JRF) that are required to set up the foundation to install other Fusion Middleware products.

As per the upgrade topology defined in this guide, you must install the Infrastructure in a new Oracle home.

You must install the Oracle WebCenter Sites distribution in the Oracle home that is created when you install the 12.2.1.2 Infrastructure. To install the product distributions, follow the procedure described in Installing the Product Distribution.

Required

Create the required schemas.

If you are upgrading from WebCenter Sites 11g, you must create the required 12c schemas before you begin the upgrade. The schemas required for WebCenter Sites are: Oracle Platform Security Services (OPSS), Audit Services (IAU), and WebCenter Sites.

Create the schemas with the Repository Creation Utility (RCU) as described in Creating the Required 12c Schemas with the RCU.

Required

Configure the WebCenter Sites domain.

Upgrade from 11g to 12c is an out-of-place upgrade. Therefore, configure the WebCenter Sites 12c (12.2.1.2) domain by following the procedure described in Configuring the WebCenter Sites Domain

Required

Configure the WebCenter Sites instance.

Configure a WebCenter Sites instance by completing the browser-based WebCenter Sites Configurator by following the procedure described in Configuring WebCenter Sites Instance.

Required

Complete the post-configuration tasks.

The post-configuration tasks include configuring the 12c (12.2.1.2) domain with LDAP-based or OAM-based authentication, verifying the directory structure, signing in and accessing the Sites UI, and restarting the managed servers.

These tasks are listed in Post-Configuration Tasks.

Required

Complete the required tasks before running the Upgrade Assistant.

The pre-upgrade tasks are a set of tasks that you must complete before starting the upgrade process with the Upgrade Assistant.

These tasks are listed in Before Running the Upgrade Assistant.

Required

Upgrade the schemas.

Upgrade the schemas components that are available for upgrade with the Upgrade Assistant by following the procedure described in Upgrading Product Schemas.

Required

Upgrade the Sites configuration.

Upgrade the Sites configurations contained in your 11g (11.1.1.8) domain with the Upgrade Assistant by following the procedure described in Upgrading Sites Configuration Using the Upgrade Assistant.

Required

Complete the post-upgrade validation tasks.

Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

To use the validation script, see Post-Upgrade Validation Tasks.

Required

Complete the other post-upgrade tasks.

Other post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in Post-Upgrade Tasks.

6.1.2 Installing the Product Distribution

Before beginning your upgrade, download the 12c (12.2.1.2) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions on the target system and install them using Oracle Universal Installer.

Note:
When Infrastructure is required for the upgrade, you must install the Oracle Fusion Middleware distribution first before you install other Fusion Middleware products.

Make sure that you download and install all the Oracle products that are part of your domain, for example Oracle HTTP Server. You must install the 12.2.1.2 binaries into a new Oracle home. It should be on the same host as the existing Oracle home.

To install the 12c (12.2.1.2) distributions:

1. Sign in to the target system.

2. Download the following from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle WebCenter Sites (fmw_12.2.1.2.0_wcsites_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location, and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select an option:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the following:

- For Infrastructure, select Fusion Middleware Infrastructure

- For Oracle WebCenter Sites, select WebCenter Sites

Note:

Ensure that you select WebCenter Sites and not WebCenter Sites with Examples.

Click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that are verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options that you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed Oracle Fusion Middleware Infrastructure, enter the following command to start the installer for your product distribution and repeat the steps above to navigate through the installer screens:
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_wcsites_generic.jar

(Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_wcsites_generic.jar

6.1.3 Creating the Required 12c Schemas with the RCU

When upgrading from 11g, you must create the required 12c schemas. You can use the Repository Creation Utility (RCU) to create customized schemas or, optionally, you can use the Upgrade Assistant to create schemas using the default schema settings. This procedure describes how to create schemas using the RCU. Information about using the Upgrade Assistant to create schemas is covered in the upgrade procedures.

Note:
If you are upgrading from a previous 12c release of Oracle Fusion Middleware, you do not need to re-create these schemas if they already exist. Refer to the steps below to identify the existing schemas in your domain.

The following schemas must exist before you upgrade to 12c. If you are upgrading from 11g, and you are not sure which schemas you currently have, refer to the steps below to identify the existing schemas in your domain. You do not need to re-create these schemas if they already exist.

- Service Table schema (prefix_STB). This schema is new in 12c and is required for domain-based upgrades. It stores basic schema configuration information (for example, schema prefixes and passwords) that can be accessed and used by other Oracle Fusion Middleware components during the domain creation. This schema is automatically created when you run the Repository Creation Utility (RCU), where you specify the existing schema owner prefix that you used for your other 11g schemas.

Note:

If the Service Table schema does not exist, you may encounter the error message UPGAST-00328 : The schema version registry table does not exist on this database. If that happens it is necessary to create the service table schema in order to run Upgrade Assistant

- Oracle Platform Security Services (OPSS) schema (prefix_OPSS). This schema is required if you are using an OID-based security store in 11g. This schema is automatically created when you run the Repository Creation Utility (RCU). The only supported LDAP-based OPSS security store is Oracle Internet Directory (OID). An LDAP-based policy store is typically used in production environments. You do not need to reassociate an OID-based security store before upgrade. While the Upgrade Assistant is running, you can select the OPSS schema. The Upgrade Assistant upgrades the OID-based security store automatically.

Note:

The 12c OPSS database schema is required so that you can reference the 12c schema during the reconfiguration of the domain. Your domain continues to use the OID-based security store after the upgrade is complete.

- Audit Services (IAU)

- WebCenter Sites

To create the 12c schemas with the RCU:

1. (Optional) If you are upgrading from 11g, and you wish to confirm the schemas which are present in your existing domain, then connect to the database as a user with DBA privileges, and run the following code 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. Verify that a certified JDK already exists on your system by running java -version from the command line. For 12c (12.2.1.2), the certified JDK is 1.8.0_101 and later.
Ensure that the JAVA_HOME environment variable is set to the location of the certified JDK. For example:

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

Add $JAVA_HOME/bin to $PATH.

3. Go to the oracle_common/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\bin

4. Start the RCU:

- (UNIX) ./rcu

- (Windows) rcu.bat

5. On the Welcome screen, click Next.

6. On the Create Repository screen, select Create Repository and then select System Load and Product Load.
If you do not have DBA privileges, select Prepare Scripts for System Load. This will generate a SQL script containing all the same SQL statements and blocks that would have been called if the RCU were to execute the actions for the selected components. After the script is generated, a user with the necessary SYS or SYSDBA privileges can execute the script to complete the system load phase.
Click Next.

7. On the Database Connection Details screen, select the Database Type and enter the connection information for the database that hosts the 11g schemas. See the pertinent table below.

Table 6-2 Connection Credentials for Oracle Databases and Oracle Databases with Edition-Based Redefinition

Option

Description and Example

Host Name

Specify the name of the server where your database is running in the following format:

examplehost.exampledomain.com

For Oracle RAC databases, specify the VIP name or one of the node names in this field.

Port

Specify the port number for your database. The default port number for Oracle databases is 1521.

Service Name

Specify the service name for the database. Typically, the service name is the same as the global database name.

For Oracle RAC databases, specify the service name of one of the nodes in this field. For example:

examplehost.exampledomain.com

Username

Enter the user name for your database. The default user name is SYS.

Password

Enter the password for your database user.

Role

Select the database user's role from the drop-down list:

Normal or SYSDBA

Table 6-3 Connection Credentials for MySQL Databases

Option

Description and Example

Host Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 6-4 Connection Credentials for Microsoft SQL Server Databases

Option

Description and Example

Unicode Support

Select Yes or No from the drop-down list.

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.
MSSQL named instances: A named instance is identified by the network name of the computer and the instance name that you specify during installation. The client must specify both the server name and the instance name when connecting.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with administrator privileges.

Password

Enter the password for your database user.

Table 6-5 Connection Credentials for IBM DB2 Databases

Option

Description and Example

Server Name

Specify the host name, IP address, or complete server name in host\server format of the server where your database is running.

Port

Specify the port number for your database.

Database Name

Specify the name of your database.

Username

Specify the name of a user with DB Owner privileges. The default user name for IBM DB2 databases is db2admin.

Password

Enter the password for your database user.

If the prerequisite check is successful, click OK to continue to the next screen. If the check fails, review the details you entered and try again.

8. On the Select Components screen, select Select existing prefix and select the prefix that was used to create the existing 11g schemas from the drop-down menu (for example, DEV11G). This prefix is used to logically group schemas together for use in this domain.

Select the following schemas:

- Audit Services

- Audit Services Append

- Audit Services Viewers

- WebCenter Sites

- WebCenter Sites-Visitor Services

- Metadata Services (_MDS)

- User Messaging Service (_UMS)

- WebLogic Server (_WLS)

Note:

The Common Infrastructure Services (prefix_STB) and Oracle Platform Security Services (prefix_OPSS) schemas are selected by default if they have not yet been created.

Make a note of the prefix and schema names for the components you are installing as you will need this information when you configure the installation. Click Next.

9. In the Checking Prerequisites dialog, verify that the prerequisites check is successful, then click OK.

10. On the Schema Passwords screen, specify the passwords for your schema owners.
Make a note of the passwords you enter on this screen as you will need this information while configuring your product installation.

11. On the Map Tablespaces screen, configure the required tablespace mapping for the schemas you want to create.
Click Next, then click OK in the confirmation dialog. When the progress dialog shows the tablespace creation is complete, click OK.

You see the Encrypt Tablespace check box only if you have enabled Transparent Data Encryption (TDE) in the database (Oracle or Oracle EBR) when you start the RCU. Select the Encrypt Tablespace check box on the Map Tablespaces screen to encrypt all new tablespaces that the RCU creates.

12. Verify the information on the Summary screen and click Create to begin schema creation.
This screen contains information about the log files that were created from this RCU operation. Click on the name of a particular log file to view the contents of that file.

13. Review the information on the Completion Summary screen to verify that the operation is completed successfully. Click Close to complete the schema creation.

6.1.4 Configuring the WebCenter Sites Domain

If you are upgrading from WebCenter Sites 11g to 12c, then you must configure the WebCenter Sites domain using the Configuration Wizard.

To configure the WebCenter Sites domain:

1. Change directory to the following:
(UNIX) NEW_ORACLE_HOME/oracle_common/common/bin

(Windows) NEW_ORACLE_HOME\oracle_common\common\bin

2. Start the configuration wizard by entering the following command:
(UNIX) ./config.sh

(Windows) config.cmd

3. On the Configuration Type screen, select Create a new domain.
In the Domain Location field, specify the Domain home directory and click Next.

Oracle recommends you to select the domain directory location outside the Oracle home directory, which is where the Fusion Middleware products are installed. To learn more about the recommended directory structure, see What Are the Key Oracle Fusion Middleware Directories? in Oracle Fusion Middleware Understanding Oracle Fusion Middleware.

4. On the Templates screen, select Create Domain Using Product Templates:
Select the following from the Templates Category drop-down list:

- Oracle WebCenter Sites - 12.2.1.2.0 [wcsites]

- Oracle JRF - 12.2.1.2.0 [oracle_common]

- Oracle Enterprise Manager - 12.2.1.2.0 [em]

- WebLogic Coherence Cluster Extension - 12.2.1.2.0 [wlserver]

Note:

The list of Oracle WebCenter Sites templates available in this screen depends on your selection of template while installing the WebCenter Sites binaries. During the 11g to 12c upgrade process, Oracle recommends you to select only Oracle WebCenter Sites (with or without WebCenter Sites – With Examples).

Click Next.

5. On the Application Location screen, specify the Application Location to store applications associated with your domain by entering the path or by clicking Browse to use the navigation tree. The Application Location is also known as the Application home directory.
Oracle recommends you to select the application location outside the Oracle home directory, which is where the Fusion Middleware products are installed. To learn more about the recommended directory structure, see What Are the Key Oracle Fusion Middleware Directories? in Oracle Fusion Middleware Understanding Oracle Fusion Middleware.

Click Next.

6. On the Administrator Account screen, specify the user name and password you provided for the 11.1.1.8 WebCenter Sites domain click Next.
These account details are used to boot and connect to the WebCenter Sites domain’s Administrator Server.

7. On the Domain Mode and JDK screen, select Production and Oracle HotSpot JDK from the Domain Mode and JDK sections respectively and click Next.

8. On the Database Configuration Type screen, specify details about the database and database schema.
Select RCU Data. This option instructs the Configuration Wizard to connect to the database and Service Table (STB) schema to automatically retrieve schema information for schemas needed to configure the domain.

If you select Manual Configuration on this screen, you must manually fill in parameters for your schema on the JDBC Component Schema screen.

Specify the connection details in the following fields:

Note:
Make sure that the 11g schema and the 12c schema collocate on the same database.

Table 6-6 Field Descriptions for the Database Configuration Type Screen

Field

Description

DBMS/Service

Enter the database DBMS name, or service name if you selected a service type driver.

Example: orcl.exampledomain.com

Host Name

Enter the name of the server hosting the database.

Example: examplehost.exampledomain.com

Port

Enter the port number on which the database listens.

Example: 1521

Schema Owner and Schema Password

Enter the username and password for connecting to the database's Service Table schema that you specified when you created the schemas using the RCU.

The default username is prefix_STB, where prefix is the custom prefix that you defined in RCU.

Click Get RCU Configuration.

The following output in the Connection Result Log indicates that the operation succeeded. Click OK to go to the next screen.

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

9. On the JDBC Component Schema screen, verify or specify the details about the database schemas.
Verify that the values are correct for all schemas. If you selected RCU Data on the Database Configuration Type screen, the schema table should already be populated appropriately.

Click Next.

10. The JDBC Component Schema Test screen is used to test the data source connections.
A green check mark in the Status column indicates a successful test. If you encounter any issues, see the error message in the Connection Result Log section of the screen, fix the problem, then try to test the connection again by clicking Test Selected Connections.

By default, the schema password for each schema component is the password you specified while creating your schemas. If you want different passwords for different schema components, manually edit them on the previous screen (JDBC Component Schema) by entering the password you want in the Schema Password column, against each row. After specifying the passwords, select the check box corresponding to the schemas that you changed the password in and test the connection again.

Click Next.

11. The Advanced Configuration screen is used to complete the domain configuration. Select the options for which you want to perform advanced configuration and click Next:

Table 6-7 Advanced Configuration Screen Options

Option

Description

Administration Server

Required to properly configure the listen address of the Administration Server.

Node Manager

Required to configure Node Manager.

Topology

Required to configure the WebCenter Sites Managed Server.

12. On the Administration Server screen, specify a server name in the ServerName field.
Select the IP address of the host from the Listen Address drop-down list where you want the Administration Server to reside. Do not select All Local Addresses.

You can retain the default value in the Listen Port field or specify a number between 1 and 65535. The custom value must be different from SSL listen port and coherence port.

Do not specify any Server Groups for the Administration Server.

Click Next.

13. On the Node Manager screen, select the type of Node Manager you want to configure, along with the Node Manager credentials.
For the Node Manager Type, select Per Domain Default Location.

Specify the user name and the password in the Node Manager Credentials field.

14. On the Managed Servers screen, you can Add, Clone, or Delete the Managed Servers and also assign a server group (if available) to a Managed Server.

a. In the Listen Address drop-down list, select the IP address of the host you want the Managed Server to reside on. You can also specify the system name or DNS name that maps to a single IP address. Do not select All Local Addresses.

b. Click Enable SSL to enable security.

The Configuration Wizard automatically populated the default Server Groups for each Managed Server added by default. If you add additional servers, select WCSITES-MGD-SERVER from the Server Groups drop-down list.

Server Groups target Fusion Middleware applications and services to one or more servers by mapping defined application service groups to each defined server group. A given application service group can be mapped to multiple server groups if needed. Any application services that map to a given server group are automatically targeted to all servers that are assigned to that group.

Click Help to learn more about adding, cloning, or deleting a Managed Server.

When finished, click Next.

15. On the Clusters screen, click Add to create a new cluster.
A cluster is a group of WebLogic Server instances that work together to provide scalability and high-availability for applications. By creating clusters, you can group Managed Servers such that they operate as a single unit for hosting applications and resources.

Specify a name for your cluster in the Cluster Name field., such as wcs_cluster_1. Leave the Cluster Address field blank.

Repeat and add one more cluster, namely, wcs_cluster_2, and click Next.

For more information about this screen, click Help.

Note:
You can also create clusters using Enterprise Manager Fusion Middleware Control.

16. On the Assign Servers to Clusters screen, assign Managed Servers to the new cluster.

a. In the Clusters pane, select the cluster to which you want to assign the Managed Servers. For example, wcs_cluster_1.

b. In the Servers pane, assign a server to a cluster by doing one of the following:

- Single-click a server from the Servers pane and click the right-arrow button (>) to move it under the selected cluster.

- Double-click a server from the Servers pane to move it under the selected cluster.

c. Repeat this procedure to assign all the Servers to the Clusters.

Note:
Only Managed Servers are displayed under the Server pane. The Administration Server is not listed because you cannot assign it to a cluster.

Click Next.

17. The Coherence Clusters screen is displayed only if you have included Coherence during the Infrastructure installation.
Specify a name for the Coherence Cluster in the Cluster Name field. You can also retain the default name.

Leave the default port number 0 as the Cluster Listen Port and click Next. After configuration, the Coherence cluster is automatically added to the domain.

18. On the Machines screen, create new machines in the domain. A machine is required so that you can use the Node Manager to start and stop servers.
Select the Machine tab (for Windows) or the UNIX Machine tab (for UNIX), then click Add to create a new machine.

Specify a name for the machine in the Name field. For example, wcs_machine_1.

In the Node Manager Listen Address field, select the IP address of the machine in which you have configured the Managed Servers.

You must select a specific interface and not localhost. This allows Coherence cluster addresses to be dynamically calculated.

Note:
If you are extending an existing domain, you can assign servers to any existing machine. It is not necessary to create a new machine unless your situation requires it.

Click Next.

19. On the Assign Servers to Machines screen, assign the Administration Server and Managed Servers to the new machine you created on the Machines screen.

a. In the Machines pane, select the machine to which you want to assign the Administration Server and the Managed Servers. For example, wcs_machine_1.

b. In the Servers pane, assign each server to a machine by doing one of the following:

- Single-click a server from the Servers pane and click the right-arrow button (>) to move it under the selected machine.

- Double-click a server from the Servers pane to move it under the selected machine.

c. Repeat this procedure to assign all the Servers to the Machine.

Click Next.

20. On the Virtual Targets screen, click Next.

21. On the Partitions screen, click Next.

22. The Configuration Summary screen has detailed configuration information for the domain you are about to create.
Review each item on the screen and verify that the information is correct and click Create to create the domain.

You can limit the items that are displayed in the summary pane by selecting a filter option from the View drop-down list.

To make any changes, go back to a screen by clicking Back or by selecting the screen in the navigation pane. Domain creation does not start until you click Create.

23. The Configuration Progress screen displays the progress of the domain creation process.
If the domain creation is successful, click Next.

If the domain creation fails, review the errors and try again. If you cannot troubleshoot the errors, contact My Oracle Support for further assistance.

24. The End of Configuration screen displays the domain location and the Admin Server URL for the domain you created.
Note the values for further operations.

Note:
For IBM DB2, WebCenter Sites does not support the default data source created by the Fusion Middleware Configuration Wizard. To create new data source with a driver that DB2 supports:

1. Add the IBM DB2 Driver JAR files to the class path for the WebCenter Sites domain:

a. Stop the WebLogic Server Administration Server.

b. Copy the db2jcc.jar and db2jcc_license_cu.jar files from DB2 to a location that you can add to the domain class path.

c. Edit NEW_DOMAIN_HOME/bin/setDomainEnv.sh and add the following line after # ADD EXTENSIONS TO CLASSPATHS:
PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}"

d. Start the Administration Server.

2. Create a new data source using the preceding DB2 driver.

6.1.5 Configuring WebCenter Sites Instance

After you configure the Oracle WebCenter Sites domain, you can configure a WebCenter Sites instance by completing the browser-based WebCenter SitesConfigurator. WebCenter Sites runtime consists of WebCenter Sites and CAS web applications (WAR files) and the following components shared across cluster members: a config directory, a data directory, and a database instance.

The following topics describe how to configure WebCenter Sites:

Topics:

- Prerequisites for Configuring WebCenter Sites Instance
Several prerequisite tasks must be done before you use the WebCenter Sites Configurator. These tasks include granting permissions for OPSS access, modifying cache files, and setting property values for your environment.

- Configuring WebCenter Sites with the Configurator
The WebCenter Sites Configurator populates the database with tables and data necessary for WebCenter Sites to function. The Configurator also creates the necessary user accounts and sets the required permissions on the database objects.

6.1.5.1 Prerequisites for Configuring WebCenter Sites Instance

Several prerequisite tasks must be done before you use the WebCenter Sites Configurator. These tasks include granting permissions for OPSS access, modifying cache files, and setting property values for your environment.

Before configuring WebCenter Sites, ensure that you complete the following tasks:

1. Ensure that the Administration Server is running. Grant read, write, and delete permissions for accessing the Oracle Platform Security Services credential store to NEW_ORACLE_HOME/wcsites/wcsites_common/lib/sites-security.jar by executing the following script:
(UNIX) DOMAIN_HOME/wcsites/bin/grant-opss-permission.sh

(Windows) DOMAIN_HOME\wcsites\bin\grant-opss-permission.bat
Use the WebLogic Server Administrator user name and password, when prompted by the script.

If a domain home other than the default (ORACLE_HOME/user_projects/domains/domain_name) was specified in the Fusion Middleware Configuration Wizard, make sure grant-opss-permission.sh or grant-opss-permission.bat contains the specified domain name before running it. If necessary, edit the file and update the domain name.

2. In the WebCenter Sites config directory, modify the files cs-cache.xml, ss-cache.xml, linked-cache.xml, and cas-cache.xml as follows:

a. Locate the following section:
<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.0, multicastGroupPort=4444, timeToLive=0" />

b. Change the value of the peerDiscovery property to manual.

c. Save and close the file.

3. Start the Node Manager before you start the WebCenter Sites Managed Server.

6.1.5.2 Configuring WebCenter Sites with the Configurator

The WebCenter Sites Configurator populates the database with tables and data necessary for WebCenter Sites to function. The Configurator also creates the necessary user accounts and sets the required permissions on the database objects.

Note:

If you are configuring WebCenter Sites over a slow network, increase the setting of the StuckThreadMaxTime property to 1000 seconds per thread before starting the WebCenter Sites Configurator. The default value is 600 seconds.

In certain environments that potentially have network-related issues, the sample sites import process could take more than 600 seconds per thread during the WebCenter Sites configuration setup process. This can cause the import process or install to fail, and multiple exceptions in the log file. Oracle recommends increasing the setting to 1000 seconds to complete a successful installation of the sample sites.

To change the value of StuckThreadMaxTime, in the WebLogic Server Administration Console for the domain, go to Servers and click wcsites_server1. Under Configuration, click Tuning.

To run the browser-based WebCenter Sites Configurator after the corresponding WebLogic domain has been successfully set up:

1. To configure WebCenter Sites over a web server, increase the web server timeout value to 300 sec before starting the WebCenter Sites configuration.

a. (Optional) To run the Configurator in silent mode:

i. Edit the wcs_properties_bootstrap.ini file that is located in the NEW_DOMAIN_HOME/wcsites/wcsites/config directory and complete the online instructions.

ii. Start the WebCenter Sites Managed Server.

iii. Initiate the WebCenter Sites configuration process with the following command:

- On UNIX operating systems: xdg-open http://sites-host:sites-port/sites/sitesconfig

- On Windows operating systems: start http://sites-host:sites-port/sites/sitesconfig

b. (Optional) Set the values of the following properties as appropriate for your environment, using the Property Management Tool in the Admin interface. Set these properties for a cluster that uses the NIO database-based file system. If you would like files stored in locations other than the default (individual folders under NEW_DOMAIN_HOME/wcsites/wcsites/config), specify the locations as property values because they cannot be changed once WebCenter Sites is up and running.

Properties

Description

xcelerate.transformpath

Directory where Microsoft Word files are stored before WebCenter Sites transforms those files into assets.

cs.pgcachefolder

Deprecated. Only set if instructed to do so by Oracle Support.

cs.xmlfolder

Working directory for HTML rendering.

cs.pgexportfolder

Base export directory for the HTML files that are created when assets are published with the Export to Disk delivery type.

vis.path

Directory where WebCenter Sites is installed. You must include the trailing slash.

mwb.path

Directory where WebCenter Sites is installed. You must include the trailing slash.

contentserver.installation.folder

Directory where WebCenter Sites is installed. You must include the trailing slash. Applies to installations in which Satellite Server and WebCenter Sites are running in the same web application and must therefore share the user's session. Specifying this enables Satellite Server to access WebCenter Sites resources.

cs.csdtfolder

Directory where WebCenter Sites Developer Tools imports are stored.

For more information on the preceding properties, see Oracle Fusion Middleware Property Files Reference for Oracle WebCenter Sites.

2. Start the Managed Server for the WebCenter Sites primary cluster node.

3. In a web browser, access this URL: http://sites-host:sites-port/sites/sitesconfigsetup.

4. On the WebCenter Sites Configurator screen, click Begin.

5. On the Database Parameters screen, specify the JNDI Datasource name for the WebCenter Sites database repository This must be the repository you created using the Repository Creation Utility while setting up the WebLogic domain.

6. On the Web Application Parameters screen, select Yes if you are installing over a secure connection, leave all the parameters at their default (prepopulated) values, and click Next.

7. On the CAS Deployment Information screen, leave all parameters at their default (prepopulated) values and click Next. If using a cluster and a front-end web server for load balancing, adjust these values as appropriate for your environment.

8. On the WebCenter Sites Administrator Accounts screen, specify the credentials you want, and then click Next.

9. (Optional) If you chose the WebCenter Sites with Examples installation option when installing WebCenter Sites, the Sample Sites screen appears. On this screen, select the desired sample sites and click Next.

10. On the Configuration Summary screen, click Test and verify that all tests are successful. Then click Start and wait for the configuration process to complete.

11. Restart the Managed Server for the WebCenter Sites application.

12. Verify that WebCenter Sites is up and running by accessing the following URL in a web browser and logging in: http://sites-host:sites-port/sites.

Note:
The default location for cas.log is NEW_DOMAIN_HOME/servers/wcsites_server1/logs/.

To get XMLPost and Bulkloader up and running, set the following directories in the CLASSPATH environment variable:

NEW_ORACLE_HOME\wcsites\webcentersites\sites-home\lib\*
ORACLE_HOME\oracle_common\modules\clients\*

For information about how to configure additional cluster nodes, see Setting Up a Cluster.

For information about how to configure an external LDAP authentication provider, see Switching to Authentication Against an LDAP Directory.

For information about how to configure Oracle Access Manager integration, see Switching to Authentication Against Oracle Access Manager.

For information about how to use the WebCenter Sites Configuration Import/Export Utility, see Using the Property Management Tool in Oracle Fusion Middleware Property Files Reference for Oracle WebCenter Sites.

6.1.6 Post-Configuration Tasks

After configuring the WebCenter Sites 12c, complete the tasks listed in this topic.

1. If the existing Sites 11.1.1.8 environment is configured with LDAP-based or OAM-based authentication, configure the same for your 12.2.1.2 environment as well.
To switch to LDAP-based authentication, see Switching to Authentication Against an LDAP Directory.
To switch to LDAP-based authentication, see Switching to Authentication Against Oracle Access Manager.

2. Verify the directory structure. You must have Oracle Home (containing product binaries), Sites Home (domain and config data), and Sites Shared directories created after you configure WebCenter Sites.

3. Sign in to the Sites UI using your Administrator credentials.

4. Restart Managed Servers and access WebCenter Sites.

Topics:

- Switching to Authentication Against an LDAP Directory
This topic describes how to switch WebCenter Sites to authentication against an external LDAP authentication provider directory. This is a recommended solution for production environments if integration with Oracle Access Management is not viable.

- Switching to Authentication Against Oracle Access Manager
You can configure WebCenter Sites for authentication against Oracle Access Manager. This is a recommended solution for production environments.

6.1.6.1 Switching to Authentication Against an LDAP Directory

This topic describes how to switch WebCenter Sites to authentication against an external LDAP authentication provider directory. This is a recommended solution for production environments if integration with Oracle Access Management is not viable.

Before you change your authentication provider, install and configure WebCenter Sites.

To switch WebCenter Sites to authentication against an external LDAP directory:

1. (Optional) If your LDAP directory is case-sensitive, set the ldap.caseAware property in the DOMAIN_HOME/wcsites/wcsites/config/wcs_properties.json file to true.

2. Access the LDAP Configurator at http://sites-host:sites-port/sites-context/ldapconfig, follow the instructions on the screen, and enter the values for your environment.

3. For LDAP rollback, restart the WebCenter Sites Managed Server, and go to the same LDAP Configurator URL.

Now there is only manual LDAP integration. Nothing is written to your LDAP Server, only an LDIF file is created under the DOMAIN_HOME/wcsites/wcsites/config/ldap folder. The peopleparent, groupparent, username, and other fields are not prepopulated, as in the previous release.

4. Modify the LDIF file located in DOMAIN_HOME/wcsites/wcsites/config/ with values appropriate for your environment.

Because the fields are not prepopulated, follow this example for ORACLEDIR :

ldap server type -- ORACLEDIR
ldap DSN -- dc=oracle,dc=com
ldap host -- localhost
ldap port -- 389
ldap username -- cn=orcladmin
ldap password -- password
ldap peopleParent -- cn=Users,dc=oracle,dc=com
ldap groupparent -- cn=Groups,dc=oracle,dc=com

5. If the LDAP server you are using is case sensitive, edit the property file DOMAIN_HOME/wcsites/wcsites/config/wcs_properties.json, and change the ldap.caseAware property value to true.

By default the value of ldap.caseAware is set to false. Log in will fail if you are using a case-sensitive LDAP server and this property is set to false.

Note:
During the integration of Sites with LDAP, if the users data in LDAP is separated by a comma the data does not get fetched. for example: test,user. To retrieve the data, you need to change the syntax in the dir.ini file located at ..sites/install directory from "syntax.escape=\\ to syntax.escape=\#".

6. If you choose Oracle Virtual Directory as your LDAP authentication provider, WebCenter Sites generates an LDIF file, which you can import to your Oracle Internet Directory server and then create an adaptar in Oracle Virtual Directory to connect to the Oracle Internet Directory server.

You cannot import an LDIF file directly to an Oracle Virtual Directory LDAP server because it does not have a storage of its own.

7. Import the LDIF file into the external LDAP authentication provider.

8. Restart the WebLogic Managed Server running this WebCenter Sites instance.

6.1.6.2 Switching to Authentication Against Oracle Access Manager

You can configure WebCenter Sites for authentication against Oracle Access Manager. This is a recommended solution for production environments.

WebCenter Sites integration is supported for Oracle Access Manager 11.1.2.2.0 and 11.1.2.3.0.

To switch WebCenter Sites to authentication against Oracle Access Manager:

1. Deploy the oamlogin.war and oamtoken.war application files located under ORACLE_HOME/wcsites/webcentersites/sites-home on the WebLogic domain containing the target WebCenter Sites instance.

2. Create the following property file: DOMAIN_HOME/wcsites/wcsites/config/wemsites_settings.properties.

3. Populate the wemsites_settings.properties file as follows.

Elements

Properties

oamredirect

http://oam_server_host:oam_port/oam/server/auth_cred_submit

oamlogout

oamlogout=http://oam_server_host:oam_port/oam/server/logout

forgotpassword

helpdesk-email-address

4. Set following properties in DOMAIN_HOME/wcsites/wcsites/config/SSOConfig.xml.

Elements

Properties

serviceUrl

http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST

ticketUrl

http://{oamtoken_server_host}:{oamtoken_port}/oamtoken

signoutURL

http://{oam_server_host}:{oam_port}/oam/server/logout?end_url={end_url}

Use this URL when invoking WebCenter Sites logout. It includes the encoded URL where the browser will return after all logout processing has been completed by Oracle Access Manager.

end_url

For test (staging) environments: http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome

For production (delivery) environments: http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2FXcelerate%2FLoginPage.html

dbUsername

Name of the WebCenter Sites general Administrator user account.

dbPassword

Password for the WebCenter Sites general Administrator user account.

trustConfigured

Indicates to WebCenter Sites whether a trust relationship has been established between the WebCenter Sites Managed Server and the Oracle HTTP Server WebGate in Oracle Access Management. A trust relationship between the two eliminates the need to include an identity assertion in every request. Set to true if a trust relationship exists; otherwise, set to false.

5. Copy the obAccsessClient.xml and cwallet.sso files from your Oracle Access Manager instance into the DOMAIN_HOME/wcsites/wcsites/config/oblix/lib/ directory on the target WebCenter Sites instance.

6. Edit the oamtoken.xml file in the sites-config directory by setting the compatibility mode and oblix path. The compatibility mode should be set to 11G and the oblix path to the sites-config folder under which you have the oblix/lib folder.

7. In the Oracle Access Manager configuration for WebCenter Sites, update the protected, public, and excluded resources for as follows:

###########################
protected_uris
###########################
/oamlogin/test
/sites/Xcelerate/LoginPage.html
/sites/Satellite/.../*
/sites/faces/jspx/.../*
/sites/wem/fatwire/.../*
/sites/ContentServer/.../*
/sites/wem/fatwire/wem/Welcome
/console

###########################
Exclusion Scheme    OraDefaultExclusionAuthNScheme
/sites/REST
/index.html
/oamlogin/oamsso/.../*
/sites/wem/fatwire/home
/sites/**

For more information, see Updating the Protected, Public, and Excluded Resources for an Enterprise Deployment.

8. To integrate the OAMSDK Client with Weblogic Server as the oamtoken.war application, edit the jps-config.xml file for the WebCenter Sites domain. By default, the WebLogic domain runs with this file, which is part of the WebLogic Server 12 c startup script:

-Doracle.security.jps.config=ORACLE_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/jps-config.xml

a. Add a service instance, as the following example shows, next to existing service instances in the existing jsp-config.xml file:
<serviceInstance name="credstore.oamtoken" provider="credstoressp" location="./oamtoken">

<description>File Based Credential Store Service Instance</description>

<property name="location" value="./oamtoken"/>

</serviceInstance>

location is the path to the directory that contains the cwallet.sso file. The preceding example sets this path with reference to the current jsp-config.xml file. Make sure the omtoken folder is created with respect to the current directory and the cwallet.sso file is placed there. The location value can also be an absolute path to where the cwallet.sso file is placed

b. Add <serviceInstanceRef ref="credstore.oamtoken"/> under <jpsContext name="default">.

c. Add following <jpsContext> element under <jpsContexts default="default">:
<jpsContext name="OAMASDK">

<serviceInstanceRef ref="credstore.oamtoken"/>

</jpsContext>

9. Add permissions so that code in oamtoken.war can be used.
The WebGate instance created in Oracle Access Manager is accessed by the client. You need to add the credential to the WebCenter Sites domain so that the security restriction can be taken care of.

a. Launch the WebLogic Scripting Tool with the wlst.sh script:
cd ORACLE_HOME/oracle_common/common/bin/./wlst.sh

b. Connect to the Administration Server for the WebCenter Sites domain:
connect('user-name','password','sites-host:admin-port')

c. Grant the permissions:
grantPermission(codeBaseURL="file:/scratch/idc/newoam/rend/Oracle_Home/user_projects/domains/renddomain/servers/wcsites_server1/tmp/_WL_user/oamtoken/-", permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",permTarget="context=SYSTEM,mapName=OAMAgent,keyName=*",permActions="*")

The preceding path is basically the path where WebLogic Server has deployed the oamtoken.war application.

d. Restart the target WebCenter Sites Managed Server.

10. (Optional) If trust between WebCenter Sites and Oracle Access Manager has not been established, modify the configuration of the WebCenter Sites web tier as follows:

a. Log in to the Oracle Access Manager Console.

b. In the WebGate authorization policy (under the protected resource policy), go to the Responses tab.

c. Enable (select) the Identity Assertion check box.

d. Click Apply to save your changes.

11. (Optional) If WebCenterSites is deployed on a cluster is using OAM Integration. Following steps are required to be replicated on oamticketcache cache.

a. In the config directory, we have cas-cache.xml where oamticketcache is configured by default.

b. Uncomment the commented section in the cache named oamticketcache the section appear as:

<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicateAsynchronously=true, replicatePuts=true,
replicateUpdates=true,
replicateUpdatesViaCopy=false, replicateRemovals=true"/>
<bootstrapCacheLoaderFactory
class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory"
properties="bootstrapAsynchronously=false,
maximumChunkSizeBytes=5000000"
propertySeparator="," />

c. Change the cacheManagerPeerProviderFactory as follows, make sure port is unique.

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic,
multicastGroupAddress=230.0.0.8,
multicastGroupPort=40002, timeToLive=1" />

d. The port should be different for cacheManagerPeerProviderFactory and cacheManagerPeerListenerFactory as specified in the earlier steps.

e. All the cluster nodes should have same port for both the properties.

12. Restart the WebLogic Managed Server hosting this WebCenter Sites instance.

6.1.6.2.1 Integrating Site-Capture with Oracle Access Manager

To ingrate Site-Capite with OAM perform the following steps:

1. Configure the Protected Resource Policy:

a. Click Application Domains and click Open.

b. Click Search>WCSitesWebGate, and Authentication Policies tab.

c. Click Protected Resource Policy.
For Authentication Scheme, select LDAPWemScheme. Make sure that the authentication scheme is created previously .

d. Click Responses tab.

e. Select Identity Assertion option.

f. When an Authentication policy is accepted, it creates the responses. The responses are required by the WebCenter Sites HTTP filter to recognize LDAP attributes and provide information about the authenticated user. To create responses perform the following steps:

a. Click Add .

b. In the Name field, enter enter FATGATE_CSTIMEOUT.

c. For Type, select Header.

d. Enter 30 as Header Value.

2. To add Resources:

a. Click Application Domains.

b. Click Open.

c. Click Search.

d. Select WCSitesWebGate>Resources>Search and Create.

e. For Type, enter HTTP Host.

f. For Host Identifier enter WCSitesWebGate.

g. For Resource URL, enter /__admin/** .

h. For Protection Level, set it as Protected.

i. For Authentication Policy and Authorization Policy, select Protected Resource Policy.

6.1.7 Before Running the Upgrade Assistant

Before running the Upgrade Assistant to upgrade from 11.1.1.8, complete the tasks listed in this topic.

Before running the Upgrade Assistant:

1. If your existing Sites 11.1.1.8 environment is a clustered configuration, you can either upgrade the primary node to 12.2.1.2 and reconfigure the cluster setup on target, or you can upgrade all cluster members.
To upgrade all cluster members, register the cluster nodes by completing the following steps:

a. Sign in to Sites Admin Server URL.

b. Go to Admin and click Cluster Node Management under System Tools.

c. Configure node names for each cluster as per the source environment.
The nodes configured in this step are eventually mapped to the corresponding 11.1.1.8 nodes during the upgrade process.

2. Shut down the source (11.1.1.8) and the target (12.2.1.2) Admin Server and Managed Server instances.

3. If the source (11.1.1.8) and target (12.2.1.2) are on different physical machines, then Oracle recommends that you migrate the following source install directories on to the target machine before starting the upgrade process.
Migrating the source install directories on to the target machine helps to reduce the process time during upgrade.

- Sites 11.1.1.8.0 Sites Install/Home

- Sites 11.1.1.8.0 Sites Shared

- Sites 11.1.1.8.0 web apps path of deployed Sites war

4. If your existing Sites 11.1.1.8 environment is a clustered environment, migrate the nodes from source machine to target machine.
You can migrate the source instance directories in any order. Following is a sample example:

If the source environment is a two-node cluster setup, create two directories with name which you gave while registering the nodes during Cluster Node Management. For example, if node names given while registering the nodes are NodeA and NodeB, then create two directories: NodeA and NodeB on target machine.

Copy the source data on the target machine in the following format:

NodeA (Primary node)
Sites-install/Home
Sites-Shared
Location of deployed sites war
NodeB (Secondary node)
Sites-install/Home
Location of deployed sites war

Note:
You don’t need to copy Sites-Shared per node.

5. Ensure that the source schema (11g) and target schema (12c) collocate on the same database server.

Oracle
<Single DB Instance>
11g schema
12c schema

MS SQL Server
<Single DB Instance>
11g schema
12c schema

DB2
<Single DB Instance>
11g schema
12c schema

6. If you are an Oracle user, you must create a Non-SYSDBA user for performing the upgrade. To create a Non-SYSDBA user, see Creating a Non-SYSDBA User to Run the Upgrade Assistant.

7. If you are a DB2 user, consider the following before starting the upgrade:

- Import the Sites 11.1.1.8.0 schema from source database to target database (where 12.2.1.2 Sites schema is setup) before initiating schema upgrade. For a detailed procedure, see Copying 11.1.1.8 Schema from a DB2 Source to a New Target Database.

- Import the DB2 database on the same machine to make sure that your existing Sites 11.1.1.8 runtime is not affected during upgrade process.

- Because the source schema and target schema reside on single DB instance, specify the target database instance details along with the schema details during the schema upgrade process.

8. Ensure that the 12.2.1.2 target schema tablespace size has enough capacity to complete the successful data migration from the 11g source schema. The default target schema size is set to 5 GB by the RCU. You can adjust the tablespace size according to the size of the source schema.

9. Typically, Sites uses the time zone setting of the WebLogic JVM. However, if you want to use a different time zone, ensure that you change it immediately after you install Sites, that is, before you create any data in the target (12.2.1.2) environment.

Topics:

- 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.

- Copying 11.1.1.8 Schema from a DB2 Source to a New Target Database
You must import the Sites 11.1.1.8 schema from source DB2 database to target database (where 12.2.1.2 Sites schema is setup) before upgrading the schemas.

6.1.7.1 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:
If you created the non-SYSDBA user FMW in a previous release, you must drop and recreate this user before starting the upgrade. Running the Upgrade Assistant with an older FMW user may lead to a failed upgrade as new privileges may have been added. Oracle recommends that you drop and recreate the user instead of modifying the existing FMW user.

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 thev$xatrans$ table is required only by Oracle Identity Manager. If you do not require Oracle Identity Manager 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, welcome1 is the password. When granting privileges, make sure that you specify your actual password.

create user FMW identified by welcome1;
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;

Note:

Oracle Database 11.2.0.3 Database Users ONLY: You must apply Oracle Patch 13036331 before you begin the upgrade. Go to My Oracle Support to download the patch.

If you do not apply this patch, you must grant additional privileges for some schemas.

6.1.7.2 Copying 11.1.1.8 Schema from a DB2 Source to a New Target Database

You must import the Sites 11.1.1.8 schema from source DB2 database to target database (where 12.2.1.2 Sites schema is setup) before upgrading the schemas.

Consider the following criteria to make sure that the import operation is successful:

Note:

This task is applicable only if your database is on DB2. You can skip this task for Oracle or MS SQL Server databases.

- Ensure the user performing the database import has the required privileges on the target database.

- Set the APPLHEAPSZ of the target database to an appropriate value depending on your schema size.

To copy the Sites 11.1.1.8 schema from source database to target database:

1. Enter the following command from the location where you created the database directories:
db2move <old_db> COPY -sn <schemaname> -co TARGET_DB <targetDB> user <username> using <password>

Table 6-8 DatabaseMovement Command Parameters

Parameter

Description

db2move

Database movement tool command. It is used to move the tables within the DB2 database from the source system to the target system.

old_db

Specify the name of the database existing on the source system.

COPY

Indicates the database movement tool to perform a copy operation.

schemaname

Specify the schema name for the database existing on the source system.

targetDB

Specify the name of the target database.

username

Specify the user name.

password

Specify the password.

For example:

db2move dot8db COPY -sn dot8schema -co TARGET_DB 12cdb user dot8user using test1234

2. Verify that the copy operation is successful by performing the following steps:

a. Sign in to the DB2 console.

b. Connect to the new (target) database.

c. List and query the tables to make sure that data is copied properly.

3. Grant the necessary privileges for the DB_SITE (RCU 12c Sites user) before upgrading.

6.1.8 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.

Topics:

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Product Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the 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.

6.1.8.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure 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, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. 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:

Topics:

- Upgrade Assistant Parameters

6.1.8.1.1 Upgrade Assistant Parameters

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

Table 6-9 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

6.1.8.2 Upgrading Product Schemas Using the Upgrade Assistant

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

To upgrade the 11g schemas:

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 Selected Schemas screen, select Individually Selected Schemas and click Next.
The Upgrade Assistant identifies the components that are available for a schema upgrade thus allowing you to select the schemas you want to include in the upgrade.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components for which you want to upgrade schemas. When you select a component, the schemas and any dependencies are automatically selected.

4. 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.

5. On the WebCenter Sites Source Version screen, select 11.1.1.8.0 and click Next. This is the starting point of your upgrade.

6. On the WebCenter Sites Location screen, specify the complete location of the existing Sites home and Sites shared directory, and location of the 12c configuration file: wcs_properties.json.
Click Next.

7. On the WebCenter Sites Source Schema screen, select the database type from the Database Type drop-down list.
Specify the database connect string in the Database Connect String field in the following format:

- (Oracle Database) host:port/service or host:port:SID or TNS connect string

- (Microsoft SQL Server) //host:port;DatabaseName=dbname

- (IBM DB2) //host:port;DatabaseName=dbname

Specify the user name with DBA privileges in the DBA User Name field. For example, non-SYSDBA user ‘fmw’. See Creating a Non-SYSDBA User to Run the Upgrade Assistant.

Specify the DBA password in the DBA Password field.

Specify the user name and password for the schema in the Schema User Name and Schema Password fields respectively.

If you are using Oracle database:

a. Enter the details of the 12c Schema for WCSITES Schema page.

b. Select the Schema user name from the drop-down list.

c. Enter password and proceed.

d. Enter the details of the Sites 11.1.1.8.0 schema for "WCSITES_SOURCE Schema" page.

e. Update Schema user name and password for the Schema having 11.1.1.8.0 tables.

If you are using SQL Server:

a. Enter the details of the 12c Schema for "WCSITES Schema" page.

b. Select the Schema user name in the drop-down list. Only the RCU created WebCenter Sites Schemas will be listed in the drop-down list.

c. Enter password and proceed.

d. Enter the details of the Sites 11.1.1.8.0 schema for "WCSITES_SOURCE Schema" page. You need to provide a dba user and the Sites User.

e. Enter the default prefix being used for the Schemas in Sites 11.1.1.8.0 in the "WCSITES SourceSchema prefix" page. For example, use "dbo" if that is the prefix.

8. 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 Oracle Fusion Middleware Upgrading with the Upgrade Assistant Upgrade Guide 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.

9. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
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 Upgrade to start the upgrade process.

10. 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.

11. If the schema upgrade is successful, a summary file is generated at the following location:
NEW_ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/schema/Source Version/Database Type/summary.txt

Where, Source Version is 11.1.1.8.0 in this case and Database Type is the database which you are using.

If the schema upgrade fails, you can review the logs for possible errors. The log file is generated at the following location:

NEW_ORACLE_HOME/oracle_common/upgrade/logs

Click Close to close the Upgrade Assistant.

6.1.8.3 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.2.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.

6.1.9 Upgrading Domain Component Configurations

After you upgrade the product schemas, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

Topics:

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Sites Configuration Using the Upgrade Assistant
You must upgrade the Sites configuration using the Upgrade Assistant.

- Verifying the Domain-Specific-Component Configurations Upgrade
To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.

6.1.9.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure 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, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. 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:

Topics:

- Upgrade Assistant Parameters

6.1.9.1.1 Upgrade Assistant Parameters

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

Table 6-10 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

6.1.9.2 Upgrading Sites Configuration Using the Upgrade Assistant

You must upgrade the Sites configuration using the Upgrade Assistant.

Configuration upgrade is supported for Apache Tomcat and IBM WebSphere servers as well for 11g starting point.

Following are the supported databases for the 11g starting point:

- Oracle

- Microsoft SQL

- DB2

Following are the supported application servers for the 11g starting point:

- Oracle WebLogic Server

- Apache Tomcat

- IBM WebSphere

Note:
Readiness Check for the Configuration upgrade is not available for 11g starting point.

To upgrade the 11g domain:

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. Start the Upgrade Assistant:

- (UNIX) ./ua

- (Windows) ua.bat

3. 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.

4. On the All Configurations screen, select All Configurations Used by a Domain and specify the 12.2.1.2 domain location in the Domain Directory field by entering it directly or by clicking Browse to use a navigation tree to select a valid domain directory. Click Next.

5. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

6. 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.

7. On the WebCenter Sites Source Version screen, select 11.1.1.8.0. This is the starting point of your upgrade.

In addition, specify the path of the 12c config directory, the complete path of the 12c wcs_properties.json file, and the 11.1.1.8.0 shared directory.

Click Next.

8. Depending on the source type (whether a single-server environment or a clustered environment), specify the required details:

a. (Single-server environment) The WebCenter Sites Source Details screen is displayed if your source is a single-server environment.
On the WebCenter Sites Source Cluster Details screen, specify the complete path of the Source 11.1.1.8.0 Sites install directory and Source 11.1.1.8.0 Sites deployment directory location and click Upgrade.

Following are examples of the Sites Deployment Directory:

- (Tomcat) TOMCAT_HOME/webapps/sites

- (WebSphere) WAS_HOME/installableApps/sites

- (WebLogic) DOMAIN_HOME/manual/sites

You can also click Browse to select a particular directory using the navigation tree.

b. (Clustered environment) The WebCenter Sites Source Details screen is displayed if your source is a clustered environment.

Note:

Ensure that you run the Upgrade Assistant on the machine where the Admin Server is deployed.

Specify the Sites Install and Sites deployment directory for each node in the Source 11.1.1.8.0 Sites install directory and Source 11.1.1.8.0 Sites deployment directory fields, respectively.

You can also click Browse to select a particular directory using the navigation tree.

After specifying the 11.1.1.8.0 directories, click Upgrade.

Note:
The node names listed in the Upgrade Assistant are the names that you provided while registering the nodes in the Cluster Node Management screen.

9. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration 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 Oracle Fusion Middleware Upgrading with the Upgrade Assistant Upgrade Guide 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 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 options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

11. 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 components 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.

12. If the configuration upgrade is successful, summary files are generated at the following location:
NEW_ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config<timestamp>/11.1.1.8.0/

If the source (11.1.1.8.0) is a clustered environment, the summary details are generated for each cluster as follows:

NEW_ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config<timestamp>/11.1.1.8.0/

If the source (11.1.1.8.0) is a single-server environment, the following three summary files are generated:

- PropertyMigration_Summary.txt for Property Migration Summary

- HomeMigration_Summary.txt for Site Home Migration Summary

- SharedMigration_Summary.txt for Sites Shared Migration Summary

If the schema upgrade fails, you can review the logs for possible errors. The log file is generated at the following location:

NEW_ORACLE_HOME/oracle_common/upgrade/logs

Click Close to close the Upgrade Assistant.

6.1.9.3 Verifying the Domain-Specific-Component Configurations Upgrade

To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.

To sign in to the Administration Console, go to: http://administration_server_host:administration_server_port/console

To sign in to Oracle Enterprise Manager Fusion Middleware Control Console, go to: http://administration_server_host:administration_server_port/em

Note:

After upgrade, make sure you run the administration tools from the new 12c Oracle home directory and not from the previous Oracle home directory.

During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.

6.1.10 Post-Upgrade Validation Tasks

Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

To run the validation script:

1. The validation script is available at the following location:
(UNIX) NEW_Oracle_Home/wcsites/plugins/upgrade/

(UNIX) ./validation.sh

(Windows) NEW_Oracle_Home\wcsites\plugins\upgrade\

(Windows) validation.bat

2. When the validation check is complete, validation summary report: Validation.txt is generated. Save it at any location on your system.

3. Review the validation summary report to check if there is any inconsistency in the data between your existing domain and the newly configured 12.2.1.2 domain.

Note:
If your source (11.1.1.8) environment is using Patch 12 or above, comparison report for web.xml displays differences that are available on the target (12.2.1.2) environment. You can ignore any changes mentioned in summary report that are available on the target (12.2.1.2) environment.

6.1.11 Post-Upgrade Tasks

The post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in this topic.

After upgrading to WebCenter Sites 12.2.1.2:

1. Restore or re-deploy the custom settings from your existing environment to your 12.2.1.2 environment.
These include custom changes made to Java libraries, static web resources, or element changes.

To restore changes made to the Java libraries or static web pages, see Migrating Custom Java Libraries or Static Web Resources.

Note:

- WebCenter Sites 12c uses ODL logging framework and any custom Log4j log levels set on 11g environment are not migrated to ODL logging. You can reset these levels after the upgrade.

- Any customizations (example : WURFL services) done on 11g MobilityService.xml has to be ported manually to 12.2.1.2 xml.

2. Start Administration Server and Managed Servers. See Starting Servers and Processes.

Note:

Before you start the Administration Server and Managed Servers, clear the cached images and files in the browser.

3. Reconfigure passwords for the publishing process.

a. Sign in to the Administration Server URL as the Administrator.

b. Go to Admin menu and click Destinations under Publishing.

c. Update the publishing destination URL, Port, Username, and Password.

4. If external WebRoots are configured, update WebRoots from Sites Admin user interface.

5. If your source was a clustered environment, copy the config directory xml file settings from your source environment on which you run the Upgrade Assistant, to all other nodes on your upgraded environment.
These include the following:

- cs-cahe.xml

- cas-cache.xml

- ss-cache.xml

- linked-cache.xml

- MobilityServices.xml

- Custom/RestResources.xml

- wcs_properties_bootstrap.ini

Note:
Lucene search indexes are re-enabled during the upgrade process. Search results in Contributor UI will likely be delayed until the indexes are completely rebuilt post upgrade process.

6. (Applicable only if you are using SQL server) Fusion Middleware Infrastructure Release 12c requires the SQL Server database to be configured in a case sensitive mode. As a result, ics:sql jsp tag provided by WebCenter Sites require the table value to be in the same case as stated in the database.
Following is the syntax of the ics:sql statement:

<ics:sql
sql="sql commands"
listname="list name"
table="name of table"
[limit="max number of results"]/>

You must provide the name of the table in the same case as specified in the SQL Server database.

7. The following properties are reset to the application Admin user account values provided during Sites Configuration Setup process:

- xcelerate.batchuser and password

- cs.emailpassword

You must update these properties with their appropriate values using the Property Management Tool.

8. After WCC integration, reset the wcc.server.password in WCC Configuration to view all the mapped rules.

9. If the instance is delivery and has any of the Sample Sites published, then you must republish the Sample Sites to the delivery instance from upgraded development instance.

10. (If you are upgrading from a previous 12c release only and if Sites is installed with RSS and Site Capture on same domain)

a. If you are upgrading Sites with RSS and Site Capture to 12c (12.2.1.2) from 12.2.1.0 or a later release, you must create a new domain and install RSS and Site Capture again.

b. If you are not installing Site Capture on the same port, perform the following:

i. Change the Site Capture port in the FW_View and FW_Application tables for Site Capture in Sites

ii. Change the port number in the valid.urls property

iii. Change the port number in other properties under the SiteCapture category

c. After installing RSS, change the RSS port in the SystemSatellite table, unless RSS is installed on same port.

Topics:

- Starting Servers and Processes
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

- If the Existing Instance is a Delivery Instance...
If you are upgrading from 11g to the latest 12c release, and if your existing instance is a delivery instance, then you must manually reassign Apps for the User Published Sites.

6.1.11.1 Starting Servers and Processes

After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

The components may be dependent on each other so they must be started in the correct order.

Note:
The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To start your Fusion Middleware environment, follow the steps below:

Step 1: Start the Administration Server

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To start the Administration Server, use the startWebLogic script:

- (UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Step 2: Start Node Manager

To start Node Manager, use the startNodeManager script:

- (UNIX) NEW_DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

Step 3: Start Oracle Identity Management ComponentsStart any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

Step 4: Start the Managed Servers

To start a WebLogic Server Managed Server, use the startManagedWebLogic script:

- (UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

Step 5: Start System Components

To start system components, such as Oracle HTTP Server, use the startComponent script:

- (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

You can start system components in any order.

6.1.11.2 If the Existing Instance is a Delivery Instance...

If you are upgrading from 11g to the latest 12c release, and if your existing instance is a delivery instance, then you must manually reassign Apps for the User Published Sites.

To reassign Apps for User Published Sites:

1. Sign in to the AdminSite as an Administrator.

2. To add Admin App to User Published Sites:

a. Go to WEM Admin under AdminSite.

b. Click Apps. Then click Manage App under Admin App.

c. Click Assign to Sites. Click Select Sites and then click Continue.

d. Select Advanced User role and save the change.

3. To add Contributor App to User Published Sites:

a. Go to WEM Admin under AdminSite.

b. Click Apps. Then click Manage App under Admin App.

c. Click Assign to Sites. Click Select Sites and then click Continue.

d. Select Sites User role and save the change.

4. To add Other Apps, follow the similar path and assign required roles.

6.2 Upgrading WebCenter Sites from a Previous 12c Release

The valid 12c starting point for upgrading WebCenter Sites to 12.2.1.2 are WebCenter Sites releases 12.2.1.0, 12.2.1.0 Patch 1, 12.2.1.0 Patch 2, and 12.2.1.1. This is an in-place upgrade.

Note:
If the existing Sites environment is configured with NIO-based Shared File System to a database, revert it back to disk storage before starting the upgrade process.

For information about the differences between in-place and out-of-place upgrades, see About In-Place versus Out-of-Place Upgrades in Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

Follow the steps in the following topics to perform the upgrade:

Topics:

- About the WebCenter Sites Upgrade Process from a Previous 12c Release
Review the flowchart and roadmap for an overview of the upgrade process for WebCenter Sites.

- Installing the Product Distribution
Before beginning your upgrade, download the 12c (12.2.1.2) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions on the target system and install them using Oracle Universal Installer.

- If you have installed Sites with Insights...
Oracle WebCenter Sites Insights is deprecated since 12.2.1.1. As a result, the reconfiguration template is not available during upgrade. You must perform the steps mentioned in this topic if your existing deployment contains Sites Insights.

- Running a Pre-Upgrade Readiness Check
To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. 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.

- Stopping Servers and Processes
Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.

- About Reconfiguring the Domain
Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

- Before Running the Upgrade Assistant
Before running the Upgrade Assistant to upgrade your 12.2.1.x domain, complete the tasks listed in this topic.

- 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.

- Upgrading Domain Component Configurations
After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

- Post-Upgrade Validation Tasks
Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

- Post-Upgrade Tasks
The post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in this topic.

6.2.1 About the WebCenter Sites Upgrade Process from a Previous 12c Release

Review the flowchart and roadmap for an overview of the upgrade process for WebCenter Sites.

Figure 6-2 Upgrade Process Flowchart for WebCenter Sites from a Previous 12c Release

Table 6-11 provides a roadmap for tasks that you must perform to upgrade WebCenter Sites from a previous 12c release.

Table 6-11 Tasks for Upgrading WebCenter Sites from a Previous 12c Release

Task

Description

Required

If you have not done so already, review the introductory topics in this guide and complete the required pre-upgrade tasks.

The pre-upgrade tasks include cloning your production environment, verifying system requirements and certifications, purging unused data, and creating non-SYSDBA user.

For a complete list of pre-upgrade tasks, see Pre-Upgrade Tasks for Oracle WebCenter Components.

Important:
You must back up the WebLogic domain, Sites configuration directory, Sites shared directory, and Sites schema before starting the upgrade process.

Required

Download and install the 12c (12.2.1.2) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions.

The Infrastructure distribution packs the WebLogic Server and the Java Required Files (JRF) that are required to set up the foundation to install other Fusion Middleware products.

As per the upgrade topology defined in this guide, you must install the Infrastructure in a new Oracle home.

You must install the Oracle WebCenter Sites distribution in the Oracle home that is created when you install the 12.2.1.2 Infrastructure. To install the product distributions, follow the procedure described in Installing the Product Distribution.

Required if you have installed WebCenter Sites with Insights

Remove the extension template and install component references to Insights and app server insights_server1 and its dependencies.

Oracle WebCenter Sites Insights is deprecated since 12.2.1.1. As a result, the reconfiguration template is not available during upgrade. You must perform the steps mentioned in the following topic if your existing deployment contains Sites Insights: If you have installed Sites with Insights....

Optional

Run a pre-upgrade readiness check.

See Running a Pre-Upgrade Readiness Check.

Required

Shut down the existing environment (stop all Administration and Managed Servers).

WARNING:
Failure to shut down your servers during an upgrade may lead to data corruption.

See Stopping Servers and Processes.

Required

Complete the required tasks before running the Upgrade Assistant.

The pre-upgrade tasks are a set of tasks that you must complete before starting the upgrade process with the Upgrade Assistant.

These tasks are listed in Before Running the Upgrade Assistant.

Required

Upgrade the product schemas with the Upgrade Assistant.

Upgrade the schemas components that are available for upgrade with the Upgrade Assistant by following the procedure described in Upgrading Product Schemas.

Required

Reconfigure the existing 12c domain.

When you run the Reconfiguration Wizard on your existing domain, it prepares your domain for upgrade by selecting and applying the reconfiguration templates.

Reconfigure the domain by following the procedure described in About Reconfiguring the Domain.

Required

Upgrade the domain configuration.

Upgrade all the configurations contained in your 12.2.1.0 domain with the Upgrade Assistant by following the procedure described in Upgrading Domain Component Configurations.

Required

Complete the post-upgrade validation tasks.

Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

To use the validation script, see Post-Upgrade Validation Tasks.

Required

Complete the other post-upgrade tasks.

Other post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in Post-Upgrade Tasks.

Required

Restart the servers and processes.

See Starting Servers and Processes.

6.2.2 Installing the Product Distribution

Before beginning your upgrade, download the 12c (12.2.1.2) Oracle Fusion Middleware Infrastructure and Oracle WebCenter Sites distributions on the target system and install them using Oracle Universal Installer.

Note:
When Infrastructure is required for the upgrade, you must install the Oracle Fusion Middleware distribution first before you install other Fusion Middleware products.

Make sure that you download and install all the Oracle products that are part of your domain, for example Oracle HTTP Server. You must install the 12.2.1.2 binaries into a new Oracle home. It should be on the same host as the existing Oracle home.

To install the 12c (12.2.1.2) distributions:

1. Sign in to the target system.

2. Download the following from Oracle Technology Network or Oracle Software Delivery Cloud to your target system:

- Oracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle WebCenter Sites (fmw_12.2.1.2.0_wcsites_generic.jar)

3. Change to the directory where you downloaded the 12c (12.2.1.2) product distribution.

4. Start the installation program for Oracle Fusion Middleware Infrastructure:

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. On UNIX operating systems, the Installation Inventory Setup screen appears if this is the first time you are installing an Oracle product on this host.
Specify the location where you want to create your central inventory. Make sure that the operating system group name selected on this screen has write permissions to the central inventory location, and click Next.

Note:
The Installation Inventory Setup screen does not appear on Windows operating systems.

6. On the Welcome screen, review the information to make sure that you have met all the prerequisites. Click Next.

7. On the Auto Updates screen, select an option:

- Skip Auto Updates: If you do not want your system to check for software updates at this time.

- Select patches from directory: To navigate to a local directory if you downloaded patch files.

- Search My Oracle Support for Updates: To automatically download software updates if you have a My Oracle Support account. You must enter Oracle Support credentials then click Search. To configure a proxy server for the installer to access My Oracle Support, click Proxy Settings. Click Test Connection to test the connection.

Click Next.

8. On the Installation Location screen, specify the location for the Oracle home directory and click Next.
For more information about Oracle Fusion Middleware directory structure, see Understanding Directories for Installation and Configuration in Oracle Fusion Middleware Planning an Installation of Oracle Fusion Middleware.

9. On the Installation Type screen, select the following:

- For Infrastructure, select Fusion Middleware Infrastructure

- For Oracle WebCenter Sites, select WebCenter Sites

Note:

Ensure that you select WebCenter Sites and not WebCenter Sites with Examples.

Click Next.

10. The Prerequisite Checks screen analyzes the host computer to ensure that the specific operating system prerequisites have been met.
To view the list of tasks that are verified, select View Successful Tasks. To view log details, select View Log. If any prerequisite check fails, then an error message appears at the bottom of the screen. Fix the error and click Rerun to try again. To ignore the error or the warning message and continue with the installation, click Skip (not recommended).

11. On the Installation Summary screen, verify the installation options that you selected.
If you want to save these options to a response file, click Save Response File and enter the response file location and name. The response file collects and stores all the information that you have entered, and enables you to perform a silent installation (from the command line) at a later time.
Click Install to begin the installation.

12. On the Installation Progress screen, when the progress bar displays 100%, click Finish to dismiss the installer, or click Next to see a summary.

13. The Installation Complete screen displays the Installation Location and the Feature Sets that are installed. Review this information and click Finish to close the installer.

14. After you have installed Oracle Fusion Middleware Infrastructure, enter the following command to start the installer for your product distribution and repeat the steps above to navigate through the installer screens:
(UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_wcsites_generic.jar

(Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_wcsites_generic.jar

6.2.3 If you have installed Sites with Insights...

Oracle WebCenter Sites Insights is deprecated since 12.2.1.1. As a result, the reconfiguration template is not available during upgrade. You must perform the steps mentioned in this topic if your existing deployment contains Sites Insights.

Note:
Perform this procedure only if you are upgrading from 12.2.1.0 and you have installed Oracle WebCenter Sites with Insights.

Complete the following steps before running the pre-upgrade Readiness Check or before running the Reconfiguration Wizard:

1. Sign in to the host where you have installed Insights. Take a complete backup of your existing domain.

2. Remove extension template reference to Insights from the domain-info.xml file.

a. Change to the following directory:
(UNIX) EXISTING_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/init-info/domain-info.xml

(Windows) EXISTING_ORACLE_HOME\user_projects\domains\DOMAIN_NAME\init-info\domain-info.xml

b. Open the domain-info.xml file for editing.

c. Remove the <extention-template-ref> with name "Oracle WebCenter Sites - Insights".

d. Save and close the file.

3. Remove the install component reference to Insights from the domain-info.xml file.

a. Change to the following directory:
(UNIX) EXISTING_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/init-info/domain-info.xml

(Windows) EXISTING_ORACLE_HOME\user_projects\domains\DOMAIN_NAME\init-info\domain-info.xml

b. Open the domain-info.xml file for editing.

c. Remove the <install-comp-ref> with name="oracle.wcsites.insights".

d. Save and close the file.

4. Remove app server insights_server1 and its dependencies from the config.xml file.

a. Change to the following directory:
(UNIX) EXISTING_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/config/config.xml

(Windows) EXISTING_ORACLE_HOME\user_projects\domains\DOMAIN_NAME\config\config.xml

b. Open the config.xml file for editing.

c. Remove the app server insights_server1 and its dependencies.

d. Save and close the file.

6.2.4 Running a Pre-Upgrade Readiness Check

To identify potential issues with the upgrade, Oracle recommends that you run a readiness check before you start the upgrade process. 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.

Topics:

- 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.

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

- Performing a Readiness Check with the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to complete the 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.

6.2.4.1 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.

6.2.4.2 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) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

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, set the DISPLAY environment variable to the system name or IP address of your local workstation, and rerun Upgrade Assistant.

If you continue to receive these errors after setting DISPLAY, try launching another GUI tool, such as vncconfig. If you see the same errors, your DISPLAY environment variable may still not be set correctly.

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

Topics:

- Upgrade Assistant Parameters

6.2.4.2.1 Upgrade Assistant Parameters

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

Table 6-12 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

6.2.4.3 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:

- Individually Selected Schemas allows you to select individual schemas for review before upgrade. The readiness check reports whether a schema is supported for an upgrade or where an upgrade is needed.
When you select this option, the screen name changes to Selected Schemas.

- Domain Based allows 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.

Click Next.

3. If you selected Individually Selected Schemas: On the Available Components screen, select the components that have a schema available to upgrade for which you want to perform a readiness check.
If you selected Domain Based: On the Component List screen, review the list of components that are present in your domain for which you want to perform a readiness check.

If you select a component that has dependent components, those components are automatically selected. For example, if you select Oracle Platform Security Services, Oracle Audit Services is automatically selected.

Depending on the components you select, additional screens may display. For example, you may need to:

- Specify the domain directory.

- Specify schema credentials to connect to the selected schema: Database Type, DBA User Name, and DBA Password. 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.

Click Next to start the readiness check.

4. 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.

5. 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.

6. 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.

6.2.4.4 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 6-13 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

NEW_ORACLE_HOME/oracle_common/upgrade/logs

The directory location of the generated log file.

No action required.

Readiness report location

NEW_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.

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: NEW_ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: NEW_ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.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
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
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
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ 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_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ 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 MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
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_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 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.3.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: FAILURE.

If you are running the 12.1.3.0 version of Oracle Fusion Middleware IAU Schemas, and those schemas were upgraded from 11g (11.1.1.7 and later) or 12c (12.1.2.0), your readiness check may fail with the following error:

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

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.

6.2.5 Stopping Servers and Processes

Before you run the Upgrade Assistant to upgrade your schemas and configurations, you must shut down all of the pre-upgrade processes and servers, including the Administration Server and any managed servers.

An Oracle Fusion Middleware environment can consist of an Oracle WebLogic Server domain, an Administration Server, multiple managed servers, Java components, system components such as Identity Management components, and a database used as a repository for metadata. The components may be dependent on each other, so they must be stopped in the correct order.

Note:
The procedures in this section describe how to stop the existing, pre-upgrade servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager.

To stop your pre-upgrade Fusion Middleware environment, navigate to the pre-upgrade domain and follow the steps below:

Step 1: Stop System Components

To stop system components, such as Oracle HTTP Server, use the stopComponent script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

You can stop system components in any order.

Step 2: Stop the Managed Servers

To stop a WebLogic Server Managed Server, use the stopManagedWebLogic script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

- (Windows) EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Step 3: Stop Oracle Identity Management ComponentsStop any Oracle Identity Management components, such as Oracle Internet Directory:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name

Step 4: Stop the Administration Server

When you stop the Administration Server, you also stop the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To stop the Administration Server, use the stopWebLogic script:

- (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Step 5: Stop Node Manager

To stop Node Manager, close the command shell in which it is running.

Alternatively, after setting the nodemanager.properties attribute QuitEnabled to true (the default is false), you can use WLST to connect to Node Manager and shut it down. See stopNodeManager in Oracle Fusion Middleware WLST Command Reference for WebLogic Server.

6.2.6 About Reconfiguring the Domain

Run the Reconfiguration Wizard to reconfigure your domain component configurations to 12c (12.2.1.2).

When you reconfigure a WebLogic Server domain, the following items are automatically updated, depending on the applications in the domain:

- WebLogic Server core infrastructure

- Domain version

Note:

Before you begin the domain reconfiguration, note the following limitations:

- The Reconfiguration Wizard does not update any of your own applications that are included in the domain.

- Transforming a non-dynamic cluster domain to a dynamic cluster domain during the upgrade process is not supported.
The dynamic cluster feature is available when running the Reconfiguration Wizard, but Oracle only supports upgrading a non-dynamic cluster upgrade and then adding dynamic clusters. You cannot add dynamic cluster during the upgrade process.

Specifically, when you reconfigure a domain, the following occurs:

- The domain version number in the config.xml file for the domain is updated to the Administration Server's installed WebLogic Server version.

- Reconfiguration templates for all installed Oracle products are automatically selected and applied to the domain. These templates define any reconfiguration tasks that are required to make the WebLogic domain compatible with the current WebLogic Server version.

- Start scripts are updated.
If you want to preserve your modified start scripts, be sure to back them up before starting the Reconfiguration Wizard.

Note:
When the domain reconfiguration process starts, you can’t undo the changes that it makes. Before running the Reconfiguration Wizard, ensure that you have backed up the domain as covered in the pre-upgrade checklist. If an error or other interruption occurs while running the Reconfiguration Wizard, you must restore the domain by copying the files and directories from the backup location to the original domain directory. This is the only way to ensure that the domain has been returned to its original state before reconfiguration.

Follow these instructions to reconfigure the existing domain using the Reconfiguration Wizard. See Reconfiguring WebLogic Domains in Oracle Fusion Middleware Upgrading Oracle WebLogic Server.

Topics:

- Backing Up the Domain

- Starting the Reconfiguration Wizard

- Reconfiguring the WebCenter Sites Domain with the Reconfiguration Wizard
Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing domain.

6.2.6.1 Backing Up the Domain

Before running the Reconfiguration Wizard, create a backup copy of the domain directory.

To create a backup of the domain directory:

1. Copy the source domain to a separate location to preserve the contents.
(Windows) copy C:\domains\mydomain to C:\domains\mydomain_backup.

(UNIX) cp mydomain /domains/mydomain_backup

2. Before updating the domain on each remote Managed Server, create a backup copy of the domain directory on each remote machine.

3. Verify that the backed up versions of the domain are complete.

If domain reconfiguration fails for any reason, you must copy all files and directories from the backup directory into the original domain directory to ensure that the domain is returned entirely to its original state before reconfiguration.

6.2.6.2 Starting the Reconfiguration Wizard

Note:
Shut down the administration server and all collocated managed servers before starting the reconfiguration process. See Stopping Servers and Processes.

To start the Reconfiguration Wizard in graphical mode:

1. Sign in to the system on which the domain resides.

2. Open the command shell (on UNIX operating systems) or open a command prompt window (on Windows operating systems).

3. Edition Based Database Users Only: If your schemas are configured with EBR database, a default edition name must be manually supplied before you run the Reconfiguration Wizard.
Run the following SQL command to set the default edition:
ALTER DATABASE DEFAULT EDITION = edition_name;

where edition_name is the child edition name.

4. Go to the oracle_common/common/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\commom\bin

5. Start the Reconfiguration Wizard with the following logging options:

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

where log_file is the absolute path of the log file you'd like to create for the domain reconfiguration session. This can be helpful if you need to troubleshoot the reconfiguration process.

The parameter -log_priority=ALL ensures that logs are logged in fine mode.

Note:

When you run this command, the following error message might appear to indicate that the default cache directory is not valid:

*sys-package-mgr*: can't create package cache dir

You can change the cache directory by setting the environment variable CONFIG_JVM_ARGS. For example:

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

6.2.6.3 Reconfiguring the WebCenter Sites Domain with the Reconfiguration Wizard

Navigate through the screens in the Reconfiguration Wizard to reconfigure your existing domain.

Note:
Reconfiguration templates are automatically selected for every Oracle product that is installed, and are applied to the domain. These templates define any reconfiguration tasks that are required to make the WebLogic domain compatible with the current WebLogic Server version. If you see a template that is reported as missing, verify whether you have installed that respective Oracle product in your domain. For example, if Oracle HTTP Server is part of your existing domain, ensure that you install the 12c (12.2.1.2) Oracle HTTP Server product distribution.

Note:
If the source is a clustered environment, run the Reconfiguration Wizard on the primary node only. Use the pack/unpack utility to apply the changes to other cluster members in the domain.

To reconfigure the domain with the Reconfiguration Wizard:

1. On the Select Domain screen, specify the location of the domain you want to upgrade or click Browse to navigate and select the domain directory. Click Next.

2. On the Reconfiguration Setup Progress screen, view the progress of the setup process. When complete, click Next.
During this process:

- The reconfiguration templates for your installed products, including Fusion Middleware products, are automatically applied. This updates various domain configuration files such as config.xml, config-groups.xml, and security.xml (among others).

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

- The domain upgrade is validated.

3. On the Domain Mode and JDK screen, select the JDK to use in the domain or click Browse to navigate to the JDK you want to use. The supported JDK version for 12c (12.2.1.2) is 1.8.0_101 and later. Click Next.

Note:
You cannot change the Domain Mode at this stage.

For a list of JDKs that are supported for a specific platform, see Oracle Fusion Middleware Supported System Configurations.

4. On the Database Configuration Type screen, select RCU Data to connect to the Server Table (_STB) schema.
Enter the database connection details using the RCU service table (_STB) schema credentials and click Get RCU Configuration.

The Reconfiguration Wizard uses this connection to automatically configure the data sources required for components in your domain.

Note:
By default Oracle’s Driver (Thin) for Service connections; Versions: Any is the selected driver. If you specified an instance name in your connection details — instead of the service name — you must select Oracle’s Driver (Thin) for pooled instance connections; Versions: Any If you do not change the driver type, then the connection will fail.

Note:
For any existing 11g datasource, the reconfiguration will preserve the existing values. For new datasources where the schema was created for 12c by the RCU, the default connection data will be retrieved from the _STB schema. If no connection data for a given schema is found in the _STB schema, then the default connection data is used.

If the check is successful, click Next. If the check fails, reenter the connection details correctly and try again.

Note:
If you are upgrading from 11g, and your database has _OPSS or _IAU 11g database schemas, you must manually enter database connection details for those schemas. These schemas were not required in 11g and had to be created manually. Users could assign any name to these schemas, therefore the Reconfiguration Wizard does not recognize them. When providing connection information for _IAU, use the IAU_APPEND user information.

5. On the JDBC Component Schema screen, verify that the DBMS/Service and the Host name is correct for each component schema and click Next.

6. For DB2, Populate the DBMS/Service and HostName for the WCSITES Component Schema in the 'Component Datasources' screen for reconfig.

7. On the JDBC Component Schema Test screen, select all the component schemas and click Test Selected Connections to test the connection for each schema. The result of the test is indicated in the Status column.
When the check is complete, click Next.

8. On the Advanced Configuration screen, you can select all categories for which you want to perform advanced configuration. For each category you select, the appropriate configuration screen is displayed to allow you to perform advanced configuration.

Note:
The categories that are listed on the Advanced Configuration screen depend on the resources defined in the templates you selected for the domain.

For this upgrade, select none of the options and click Next.

9. On the Configuration Summary screen, review the detailed configuration settings of the domain before continuing.
You can limit the items that are displayed in the right-most panel by selecting a filter option from the View drop-down list.

To change the configuration, click Back to return to the appropriate screen. To reconfigure the domain, click Reconfig.

Note:
The location of the domain does not change when you reconfigure it.

10. The Reconfiguration Progress screen displays the progress of the reconfiguration process.
During this process:

- Domain information is extracted, saved, and updated.

- Schemas, scripts, and other such files that support your Fusion Middleware products are updated.

When the progress bar shows 100%, click Next.

11. The End of Configuration screen indicates whether the reconfiguration process completed successfully or failed. It also displays the location of the domain that was reconfigured as well as the Administration Server URL (including the listen port). If the reconfiguration is successful, it displays Oracle WebLogic Server Reconfiguration Succeeded.
If the reconfiguration process did not complete successfully, an error message is displayed indicates the reason. Take appropriate action to resolve the issue. If you cannot resolve the issue, contact My Oracle Support.

Note the Domain Location and the Admin Server URL for further operations.

6.2.7 Before Running the Upgrade Assistant

Before running the Upgrade Assistant to upgrade your 12.2.1.x domain, complete the tasks listed in this topic.

Before running the Upgrade Assistant:

1. If the source is a clustered environment, pack the domain from primary node and unpack it on the secondary cluster members.

a. Replace the Sites config folder on the second node with the one from the primary node.

b. Update the following xml files located at EXISTING_DOMAIN_HOME/wcsites/wcsites/config/:

- jbossTicketCacheReplicationConfig.xml:
Update the bind_addr property with a valid host or IP address for this cluster node.

Note:

Oracle recommends changing the multicastGroupPort value to a unique value greater than 2048. Ensure that the multicast port used injbossTicketCacheReplicationConfig.xml is the same on each node in the cluster but is different on other clusters running on the same network.

- cas-cache.xml:
If you are using IPv6 addressing, set multicastGroupAddress value to a valid IPv6 multicast address. This value must be the same for each node in the cluster. For example: [ff0x:0:0:0:0:0:0:301].

Set the timeToLive parameter to a value appropriate for your environment (typically 1). The timeToLive field must be changed from the default value of 0 if the cluster members are not all collocated on the same machine. This field must be set based on the distribution of your clustered machines, as shown in the following table:

Table 6-14 timeToLive Value Descriptions

timeToLive Value

Description

1

Multicast packets restricted to the same subnet.

32

Multicast packets restricted to the same site.

64

Multicast packets restricted to the same geographical region.

128

Multicast packets restricted to the same continent.

256

No restriction.

Repeat this step for cs-cache.xml, linked-cache.xml, and ss-cache.xml files.

2. Start the Admin Server and then grant permissions for the new Sites security jar by navigating to the following location:
EXISTING_DOMAIN_HOME/wcsites/bin/grant-opss-permission

Then, shutdown the Admin Server.

3. Restore your custom settings to the xml configuration files.

For DB2:

a. Add the db2jcc.jar and db2jcc_license_cu.jar files back to the domain classpath.

b. Edit the setDomainEnv.sh file present at the following location using a text editor:
DOMAIN_HOME/bin

Find the following text:

# ADD EXTENSIONS TO CLASSPATHS

Add the following line after # ADD EXTENSIONS TO CLASSPATHS:

PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}

c. Save the setDomainEnv.sh file.

4. Restore any customization performed to xml configuration files (for example, MobilityService.xml or any other xml file) post the reconfiguration process.

6.2.8 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.

Topics:

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Product Schemas Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade the 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.

6.2.8.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure 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, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. 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:

Topics:

- Upgrade Assistant Parameters

6.2.8.1.1 Upgrade Assistant Parameters

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

Table 6-15 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

6.2.8.2 Upgrading Product Schemas Using the Upgrade Assistant

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

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 Selected Schemas screen, select Individually Selected Schemas or All Schemas Used by a Domain to upgrade the schemas for all the components that WebCenter Sites uses. Click Next.
The Upgrade Assistant identifies the components that are available for a schema upgrade. The components used by WebCenter Sites are:

- Oracle Audit Services

- Oracle Platform Security Services

- Common Infrastructure Services

- Oracle WebLogicServer

- Oracle WebCenter Sites

3. If you selected Individually Selected Schemas: On the Available Components screen, select Oracle WebCenter Sites and other components, as listed in step 2. Click Next. When you select a component, the schemas and any dependencies are automatically selected.

4. 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.

5. On the WebCenter Sites Source Version screen, select 12.2.1.0.0 and Later and click Next. This is the starting point of your upgrade.

6. On the WebCenter Sites Source Schema screen, select the database type from the Database Type drop-down list.
Specify the database connect string in the Database Connect String field in the following format:

- (Oracle Database) host:port/service or host:port:SID or TNS connect string

- (Microsoft SQL Server) //host:port;DatabaseName=dbname

- (IBM DB2) //host:port;DatabaseName=dbname

Specify the user name with DBA privileges in the DBA User Name field. Specify the DBA password in the DBA Password field.

Specify the user name and password for the schema in the Schema User Name and Schema Password fields, respectively.

Note:

For the DB2 database schema upgrade, the Oracle WebCenter Sites component will not be listed if you select All Schemas Used by a Domain in the Selected Schemas screen because WebCenter Sites uses a different driver class from what WebLogic provides. Therefore, you must upgrade Oracle WebCenter Sites schema by selecting Individually Selected Schemas separately from the rest of the components that WebCenter Sites uses.

7. On the WebCenter Sites Location screen, specify the complete location of the existing Sites home and Sites shared directory, and location of the 12c configuration file: wcs_properties.json.
Click Next.

8. 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 Oracle Fusion Middleware Upgrading with the Upgrade Assistant Upgrade Guide 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.

9. On the Upgrade Summary screen, review the summary of the options you have selected for schema upgrade.
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 Upgrade to start the upgrade process.

10. 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.

11. If the upgrade is successful: On the Upgrade Success screen, 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.

6.2.8.3 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.2.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.

6.2.9 Upgrading Domain Component Configurations

After reconfiguring the domain, use the Upgrade Assistant to upgrade the domain component configurations inside the domain to match the updated domain configuration.

Topics:

- Starting the Upgrade Assistant
Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

- Upgrading Domain Components Using the Upgrade Assistant
Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

- Verifying the Domain-Specific-Component Configurations Upgrade
To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.

6.2.9.1 Starting the Upgrade Assistant

Run the Upgrade Assistant to upgrade product schemas, domain component configurations, or standalone system components to 12c (12.2.1.2). Oracle recommends that you run the Upgrade Assistant as a non-SYSDBA user, completing the upgrade for one domain at a time.

To start the Upgrade Assistant:

Note:

Before you start the Upgrade Assistant, make sure 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, then you will not be able to download files containing Unicode characters in their names. This can cause the upgrade to fail.

1. Go to the oracle_common/upgrade/bin directory:

- (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin

2. 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:

Topics:

- Upgrade Assistant Parameters

6.2.9.1.1 Upgrade Assistant Parameters

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

Table 6-16 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)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME\oracle_common\upgrade\logs
NEW_ORACLE_HOME\oracle_common\upgrade\temp

-help

Optional

Displays all of the command-line options.

6.2.9.2 Upgrading Domain Components Using the Upgrade Assistant

Navigate through the screens in the Upgrade Assistant to upgrade component configurations in the WebLogic domain.

After running the Reconfiguration Wizard to reconfigure the WebLogic domain to 12c (12.2.1.2), you must run the Upgrade Assistant to upgrade the domain component configurations to match the updated domain configuration.

To upgrade domain component configurations 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 next screen:

- Select All Configurations Used By a Domain. The screen name changes to WebLogic Components.

- In the Domain Directory field, enter the WebLogic domain directory path.

Click Next.

3. On the Component List screen, verify that the list includes all the components for which you want to upgrade configurations and click Next.
If you do not see the components you want to upgrade, click Back to go to the previous screen and specify a different domain.

4. 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.

5. On the WebCenter Sites Source Version screen, select 12.2.1.0.0 or Later and click Next. This is the starting point of your upgrade.

6. (Single-server environment) The WebCenter Sites Source Details screen is displayed if your source is a single-server environment.
On the WebCenter Sites Source Cluster Details screen, specify the complete path of the Source_Version (12.2.1.0 or 12.2.1.1) Sites install directory and Source_Version Sites deployment directory and click Upgrade.

You can also click Browse to select a particular directory using the navigation tree.

7. (Clustered environment) The WebCenter Sites Source Details screen is displayed if your source is a clustered environment.
Specify the Source_Version Sites Install and Source_Version Sites deployment directory for each node in the Source Source_Version Sites install directory and Source Source_Version Sites deployment directory fields respectively.

Following are examples of the Sites Deployment Directory:

- (Tomcat) TOMCAT_HOME/webapps/sites

- (WebSphere) WAS_HOME/installableApps/sites

- (WebLogic) DOMAIN_HOME/manual/sites

You can also click Browse to select a particular directory using the navigation tree.

After specifying the Source_Version directories, click Upgrade.

Note:
The node names listed in the Upgrade Assistant are the names that you provided while registering the nodes in Cluster Node Management screen.

8. On the Examine screen, review the status of the Upgrade Assistant as it examines each component, verifying that the component configuration 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 Oracle Fusion Middleware Upgrading with the Upgrade Assistant Upgrade Guide 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 configuration data; the only consequence is that the information the Upgrade Assistant has collected must be collected again in a future upgrade session.

9. On the Upgrade Summary screen, review the summary of the options you have selected for component configuration upgrade.
The response file collects and stores all the information that you have entered, and enables you to perform a silent upgrade at a later time. The silent upgrade performs exactly the same function that the Upgrade Assistant performs, but you do not have to manually enter the data again. If you want to save these options to a response file, click Save Response File and provide the location and name of the response file.

Click Upgrade to start the upgrade process.

10. 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 components 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.

11. If the configuration upgrade is successful, summary files are generated at the following location:
NEW_ORACLE_HOME/oracle_common/upgrade/logs/

If the source (12.2.1.0 or 12.2.1.1) is a clustered environment, the summary details are generated for each cluster as follows:

NEW_ORACLE_HOME/oracle_common/upgrade/logs/

If the source (12.2.1.0 or 12.2.1.1) is a single-server environment, the following three summary files are generated:

- PropertyMigration_Summary.txt for Property Migration Summary

- HomeMigration_Summary.txt for Site Home Migration Summary

- SharedMigration_Summary.txt for Sites Shared Migration Summary

If the schema upgrade fails, you can review the logs for possible errors. The log file is generated at the following location:

NEW_ORACLE_HOME/oracle_common/upgrade/logs

Click Close to close the Upgrade Assistant.

6.2.9.3 Verifying the Domain-Specific-Component Configurations Upgrade

To verify that the domain-specific-component configurations upgrade was successful, sign in to the Administration console and the Oracle Enterprise Manager Fusion Middleware Control and verify that the version numbers for each component is 12.2.1.2.

To sign in to the Administration Console, go to: http://administration_server_host:administration_server_port/console

To sign in to Oracle Enterprise Manager Fusion Middleware Control Console, go to: http://administration_server_host:administration_server_port/em

Note:

After upgrade, make sure you run the administration tools from the new 12c Oracle home directory and not from the previous Oracle home directory.

During the upgrade process, some OWSM documents, including policy sets and predefined documents such as policies and assertion templates, may need to be upgraded. If a policy set or a predefined document is upgraded, its version number is incremented by 1.

6.2.10 Post-Upgrade Validation Tasks

Oracle has provided validation scripts that you can run on your newly upgraded domain to ensure data integrity after a successful schema and configuration upgrade. You can review the validation summary report for any inconsistencies in data that may have occurred during the schema and configuration upgrade processes.

To run the validation script:

1. The validation script is available at the following location:
(UNIX) NEW_Oracle_Home/wcsites/plugins/upgrade/

(UNIX) ./validation.sh

(Windows) NEW_Oracle_Home\wcsites\plugins\upgrade\

(Windows) validation.bat

2. When the validation check is complete, validation summary report: Validation.txt is generated. Save it at any location on your system.

3. Review the validation summary report to check if there is any inconsistency in the data between your existing domain and the newly configured 12.2.1.2 domain.

Note:
If your source (11.1.1.8) environment is using Patch 12 or above, comparison report for web.xml displays differences that are available on the target (12.2.1.2) environment. You can ignore any changes mentioned in summary report that are available on the target (12.2.1.2) environment.

6.2.11 Post-Upgrade Tasks

The post-upgrade tasks include restoring any custom settings, starting Administration Server and Managed Servers, reconfiguring passwords, and other administrative tasks listed in this topic.

After upgrading to WebCenter Sites 12.2.1.2:

1. Restore or re-deploy the custom settings from your existing environment to your 12.2.1.2 environment.
These include custom changes made to Java libraries, static web resources, or element changes.

To restore changes made to the Java libraries or static web pages, see Migrating Custom Java Libraries or Static Web Resources.

Note:

- WebCenter Sites 12c uses ODL logging framework and any custom Log4j log levels set on 11g environment are not migrated to ODL logging. You can reset these levels after the upgrade.

- Any customizations (example : WURFL services) done on 11g MobilityService.xml has to be ported manually to 12.2.1.2 xml.

2. Start Administration Server and Managed Servers. See Starting Servers and Processes.

Note:

Before you start the Administration Server and Managed Servers, clear the cached images and files in the browser.

3. Reconfigure passwords for the publishing process.

a. Sign in to the Administration Server URL as the Administrator.

b. Go to Admin menu and click Destinations under Publishing.

c. Update the publishing destination URL, Port, Username, and Password.

4. If external WebRoots are configured, update WebRoots from Sites Admin user interface.

5. If your source was a clustered environment, copy the config directory xml file settings from your source environment on which you run the Upgrade Assistant, to all other nodes on your upgraded environment.
These include the following:

- cs-cahe.xml

- cas-cache.xml

- ss-cache.xml

- linked-cache.xml

- MobilityServices.xml

- Custom/RestResources.xml

- wcs_properties_bootstrap.ini

Note:
Lucene search indexes are re-enabled during the upgrade process. Search results in Contributor UI will likely be delayed until the indexes are completely rebuilt post upgrade process.

6. (Applicable only if you are using SQL server) Fusion Middleware Infrastructure Release 12c requires the SQL Server database to be configured in a case sensitive mode. As a result, ics:sql jsp tag provided by WebCenter Sites require the table value to be in the same case as stated in the database.
Following is the syntax of the ics:sql statement:

<ics:sql
sql="sql commands"
listname="list name"
table="name of table"
[limit="max number of results"]/>

You must provide the name of the table in the same case as specified in the SQL Server database.

7. The following properties are reset to the application Admin user account values provided during Sites Configuration Setup process:

- xcelerate.batchuser and password

- cs.emailpassword

You must update these properties with their appropriate values using the Property Management Tool.

8. After WCC integration, reset the wcc.server.password in WCC Configuration to view all the mapped rules.

9. If the instance is delivery and has any of the Sample Sites published, then you must republish the Sample Sites to the delivery instance from upgraded development instance.

10. (If you are upgrading from a previous 12c release only and if Sites is installed with RSS and Site Capture on same domain)

a. If you are upgrading Sites with RSS and Site Capture to 12c (12.2.1.2) from 12.2.1.0 or a later release, you must create a new domain and install RSS and Site Capture again.

b. If you are not installing Site Capture on the same port, perform the following:

i. Change the Site Capture port in the FW_View and FW_Application tables for Site Capture in Sites

ii. Change the port number in the valid.urls property

iii. Change the port number in other properties under the SiteCapture category

c. After installing RSS, change the RSS port in the SystemSatellite table, unless RSS is installed on same port.

Topics:

- Starting Servers and Processes
After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

6.2.11.1 Starting Servers and Processes

After a successful upgrade, restart all processes and servers, including the Administration Server and any Managed Servers.

The components may be dependent on each other so they must be started in the correct order.

Note:
The procedures in this section describe how to start servers and process using the WLST command line or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Administration Console. See Starting and Stopping Administration and Managed Servers and Node Manager in Administering Oracle Fusion Middleware.

To start your Fusion Middleware environment, follow the steps below:

Step 1: Start the Administration Server

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Server Administration Console and Fusion Middleware Control.

To start the Administration Server, use the startWebLogic script:

- (UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

When prompted, enter your user name, password, and the URL of the Administration Server.

Step 2: Start Node Manager

To start Node Manager, use the startNodeManager script:

- (UNIX) NEW_DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

Step 3: Start Oracle Identity Management ComponentsStart any Oracle Identity Management components, such as Oracle Internet Directory, that form part of your environment:

- (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

Step 4: Start the Managed Servers

To start a WebLogic Server Managed Server, use the startManagedWebLogic script:

- (UNIX) NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

When prompted, enter your user name and password.

Note:
The startup of a Managed Server will typically start the applications that are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

Step 5: Start System Components

To start system components, such as Oracle HTTP Server, use the startComponent script:

- (UNIX) NEW_DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) NEW_DOMAIN_HOME\bin\startComponent.cmd component_name

You can start system components in any order.

6.3 Migrating Custom Java Libraries or Static Web Resources

Perform this optional step only if custom Java libraries or static web resources were added to the web application in your pre-upgrade environment and you want to continue to use them in the upgraded environment.

If the web application includes custom Java libraries (jar files) or custom static web resources, such as css, js, or images, then you will have to manually migrate them to the upgraded environment after the upgrade. If you do not migrate these resources, you will not be able to access the functionality in the upgraded environment.

The WebCenter Sites web application is shipped as a WAR file. The web application is deployed during Config Wizard process initially and can be redeployed multiple times during the application lifecycle. Oracle recommends that you do not include any implementation-specific customizations to the Sites WAR file as the changes will be overwritten during the upgrade process.

When extending the WebLogic Server Shared Libraries framework, Sites provides extend.sites.webapp-lib.war as a shared library. This file is located in NEW_ORACLE_HOME/wcsites/webcentersites/sites-home/ directory. Any implementation-specific customizations, such as static web resources or JAVA libraries, can be included in this WAR file. This shared library gets deployed during application lifecycle and shares the same context root as sites (/sites/). The contents of this shared library will not be overwritten during patching process.

Additionally, if the Sites UI has been customized, the code changes must also be migrated to the upgraded environment.

7 Upgrading WebCenter in a Clustered Topology

Use this process to upgrade a clustered, multi-node WebCenter topology.

To upgrade a WebCenter cluster topology, where your domain has servers running on more than one machine, you will perform the entire upgrade process on the first node (Node 1) and then pack and unpack the domain on the other node(s) as described below.

To upgrade a clustered topology:

1. Perform a complete upgrade on Node 1. Upgrading an Oracle WebCenter Domain

a. Perform all post-upgrade configuration tasks. Performing Post-Upgrade Configuration Tasks

b. Verify that the upgrade was successful. Verifying the New Applications Work as Expected

2. Pack the Administration Server:

cd NEW_ORACLE_HOME/common/bin
./pack.sh -managed=true -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -template_name=wc_domain_template

3. Copy wcdomaintemplate.jar to the ORACLE_HOME/common/bin on the other machines.

4. Remove or move the old domain directories (DOMAIN_HOME and APPLICATION_HOME) on the other machines.

5. Unpack the domain on each of the other machines:

cd ORACLE_HOME/common/bin
./unpack.sh -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -overwrite_domain=true

Topics:

- Troubleshooting a WebCenter Cluster Upgrade
If you encounter errors while upgrading your WebCenter clustered topology, review these post-upgrade tasks.

7.1 Troubleshooting a WebCenter Cluster Upgrade

If you encounter errors while upgrading your WebCenter clustered topology, review these post-upgrade tasks.

Topics:

- Accessing WebCenter Content URLs Post Upgrade
This step is only necessary when you cannot access WebCenter Content URLs after a clustered topology upgrade.

7.1.1 Accessing WebCenter Content URLs Post Upgrade

This step is only necessary when you cannot access WebCenter Content URLs after a clustered topology upgrade.

After performing pack and unpack on secondary nodes, you may not be able to access WebCenter Content URLs on secondary nodes. This happens when the pack and unpack process does not completely propagate the WebCenter Content Server on the secondary node.

1. Modify the variables in the Intradoc.cfg file.
a) Navigate to <Domain_Home>/ucm/cs/bin
b) Locate the Intradoc.cfg file and update the server directory: IdcHomeDir with the new 12.2.1 install location instead of the11g install location.

NOTE: You will need to do this for each WebCenter Content managed server.

2. Modify the idcs_components.hda file.
a) Navigate to <Domain_Home>/ucm/cs/data
b) Locate the idcs_components.hda file and remove all deprecated components.

TIP: To quickly update the file, create a copy of the existing idcs_components.hda file on Node1 and paste it on Node2 in the same location (<Domain_Home>/ucm/cs/data). This will overwrite the file on Node2.

.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2018, Oracle and/or its affiliates. All rights reserved.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Pre-General Availability Draft Documentation Notice

If this document is in public or private pre-General Availability status:

This documentation is in pre-General Availability status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

Private Pre-General Availability Draft Documentation Notice

If this document is in private pre-General Availability status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your pre-General Availability trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.