Oracle® Fusion Middleware

Patching Guide

11g Release 1 (11.1.1)

E16793-05

August 2010

Oracle Fusion Middleware Patching Guide 11g Release 1 (11.1.1)

E16793-05

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

Primary Author:  Kevin Hwang

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 software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software 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 which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on 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. 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.

Contents

Preface

- Intended Audience

- Documentation Accessibility

- Related Documents

- Conventions

1 Oracle Fusion Middleware Patching and Upgrade Overview

- 1.1 Patching and Upgrade Terminology

- 1.1.1 Patching

- 1.1.2 Migration

- 1.1.3 Upgrade

- 1.1.4 Installation

- 1.2 Patching and Upgrade Tools

2 Patching Oracle Fusion Middleware with Oracle OPatch

- 2.1 About Patching

- 2.1.1 Types of Patches That can be Used with OPatch

- 2.1.2 Types of Patches That can not be Used with OPatch

- 2.2 About OPatch

- 2.2.1 Getting OPatch

- 2.2.2 Getting Patches

- 2.2.3 OPatch Environment Variables

- 2.2.4 OPatch System Requirements

- 2.2.5 Backup and Recovery Considerations for Patching

- 2.3 OPatch in a Fusion Middleware Environment

- 2.3.1 A Typical Patching Scenario

- 2.3.2 Patching a Fusion Middleware Product

- 2.3.3 Patching in a Distributed Environment

- 2.3.3.1 Patching with a Local Middleware Home

- 2.3.3.2 Patching with a Shared Middleware Home

- 2.3.4 Patching Artifacts Deployed Outside the Oracle Home

- 2.4 Running OPatch

- 2.4.1 Applying Patches and Deploying Patched Artifacts to WebLogic Servers

- 2.4.1.1 Using the OPatch Property File

- 2.4.1.2 Using the -auto Option

- 2.4.1.3 Using the apply Command

- 2.4.1.4 Sample Output for the apply Command

- 2.4.2 Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers

- 2.4.3 Deploying Patched Artifacts to WebLogic Servers

- 2.4.4 Listing the Source Oracle Homes

- 2.4.5 Listing the Domains Created from the Middleware Home or Oracle Home

- 2.4.6 Listing the Applicable Oracle Homes for a Patch

- 2.4.7 Listing Patches Applied to an Oracle Home or WebLogic Domain

- 2.4.8 Starting or Stopping a Runtime Instance

- 2.5 Troubleshooting OPatch in a Fusion Middleware Environment

- 2.5.1 Notes About Patching the MDS Repository

- 2.5.2 Configuring Your Environment for OPatch

- 2.5.2.1 Setting the StartScriptEnabled Node Manager Property

- 2.5.2.2 Setting the Machine Name and Listen Address

3 Using Patch Assistant to Migrate from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) to Release 1 (11.1.1.2.0)

- 3.1 What is a Patch Set?

- 3.2 Overview of Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) Patch Assistant

- 3.3 Migration Process

- 3.4 Preparing to Migrate

- 3.4.1 Evaluating and Reviewing your Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) Environment

- 3.4.2 Preparing to Migrate Your Configuration

- 3.4.2.1 Prerequisites

- 3.4.2.2 Extracting the Contents of Patch Assistant

- 3.4.2.3 Setting Up the Patch Assistant Environment

- 3.4.2.4 Stopping Oracle Fusion Middleware

- 3.4.2.5 Setting Logging Properties

- 3.5 Migrating to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0)

- 3.5.1 Migration Roadmap

- 3.5.2 Migration Procedure

- 3.5.2.1 Stopping the Old Domain

- 3.5.2.2 Installing Oracle Software for 11.1.1.2.0

- 3.5.2.3 Downloading Patch Assistant

- 3.5.2.4 Migrating the Schema

- 3.5.2.5 Creating a WebLogic Domain for 11.1.1.2.0

- 3.5.2.6 Migrating the Domain

- 3.5.2.7 Migrating an Instance

- 3.5.2.8 Registering the Instance

- 3.5.2.9 Starting or Stopping the 11.1.1.2.0 Domain

- 3.5.2.10 Completing Post-Migration Tasks

- 3.5.2.11 Decommissioning the 11.1.1.1.0 Installation

- 3.5.3 Post-Migration Configuration for Oracle Fusion Middleware Components

- 3.5.3.1 Post-Migration Configuration for Oracle Fusion Middleware Audit Framework

- 3.5.3.2 Post-Migration Configuration for Oracle Business Intelligence Discoverer

- 3.5.3.3 Post-Migration Configuration for Oracle Directory Integration Platform

- 3.5.3.4 Post-Migration Configuration for Oracle Identity Federation

- 3.5.3.5 Post-Migration Configuration for Oracle Platform Security Services

- 3.5.3.6 Post-Migration Configuration for Oracle Reports

- 3.5.3.7 Post-Migration Configuration for Oracle SOA

- 3.5.3.8 Post-Migration Configuration for Oracle User Messaging Service

- 3.5.3.9 Post-Migration Configuration for Oracle WebCenter

- 3.5.3.10 Post Migration Configuration for Oracle Web Services Manager

- 3.5.4 Installation Process

- 3.5.5 Configuration Process

- 3.5.6 Properties in the patchMaster.properties File

- 3.5.6.1 Overriding Properties Set in the patchMaster.properties File

- 3.5.7 Oracle Fusion Middleware Components Supported by Patch Assistant

4 Applying the Latest Oracle Fusion Middleware Patch Set

- 4.1 Summary of the Patch Set Installation Process

- 4.2 Before You Begin

- 4.2.1 Perform General Pre-Patching Tasks

- 4.2.1.1 Back Up Your Middleware Home, Domain Home and Oracle Instances

- 4.2.1.2 Stop the Servers and Processes

- 4.2.1.3 Patch Oracle WebLogic Server

- 4.2.2 Check for Optional Patching Tasks

- 4.3 Download and Start the Patch Set Installer

- 4.4 Patch Set Installer Instructions

- 4.5 Updating Your Schemas with Patch Set Assistant

- 4.6 Post-Patching Tasks

- 4.6.1 Post-Patching Tasks for System Components

- 4.6.1.1 Redeploying Your System Components

- 4.6.1.2 Upgrading the Version Number String Shown in Oracle Enterprise Manager

- 4.6.1.3 Updating File System Permissions to Allow for Privileged Port Access

- 4.6.2 Post-Patching Task for Oracle Identity Management

- 4.6.3 Post-Patching Task for Oracle Web Tier

- 4.6.4 Post-Patching Tasks for Oracle SOA Suite

- 4.6.4.1 Saving and Restoring XEngine Customizations for Oracle B2B

- 4.6.4.2 Updating the Oracle Data Integrator Clients if BAM-ODI Integration is Enabled

- 4.6.5 Post-Patching Tasks for Oracle Portal and Oracle WebCenter

- 4.6.5.1 Saving and Restoring OmniPortlet and WebClipping Customizations for Oracle Portal and Oracle WebCenter

- 4.6.5.2 Updating Oracle WebCenter Wiki and Blog Server Files

- 4.6.5.3 Enabling Process Spaces in a WebCenter Domain

- 4.7 Optional Patching Procedures

- 4.7.1 Enabling WS-AtomicTransaction in JRF

- 4.7.2 Updating the Oracle Virtual Directory Version Number in Oracle Directory Service Manager

- 4.7.3 Securing UMS JMS Resources

- 4.7.4 Adding New OWSM Pre-Defined Policies

- 4.8 Starting the Servers and Processes

- 4.9 Verifying Your Patch Installation

5 Updating Your Schemas with Patch Set Assistant

- 5.1 Before You Begin

- 5.1.1 Back Up Your Database and Database Schemas

- 5.1.2 Check Your Database and Schemas

- 5.1.3 Check the aq_tm_processes Value for Oracle Portal

- 5.2 Running the Patch Set Assistant

- 5.2.1 Starting Patch Set Assistant

- 5.2.2 Command Line Syntax

- 5.2.3 Sample Commands

- 5.2.4 Verifying the Update

- 5.3 Patch Set Assistant Log Files

6 Patching an 11g (11.1.1.2.0) Oracle Identity Management High Availability Environment with 11g (11.1.1.3.0)

- 6.1 Task 1: Stopping Servers and System Components

- 6.1.1 Stopping Managed Servers

- 6.1.2 Stopping the Administration Server

- 6.1.3 Stopping the Node Manager

- 6.1.4 Stopping the Oracle Management Agent

- 6.1.5 Stopping the System Components

- 6.1.6 Special Consideration for Patching OID Replication Environments

- 6.2 Task 2: Updating Oracle WebLogic Server 10.3.2 to Oracle WebLogic Server 10.3.3

- 6.3 Task 3: Updating the Oracle Identity Management Oracle Home using the Oracle Identity Management Patch Set Installer

- 6.4 Task 4: Updating the Oracle HTTP Server Oracle Home Using the Oracle Web Tier Patch Set Installer

- 6.5 Task 5: Updating the Oracle Identity Management Repository using Patch Set Assistant

- 6.6 Task 6: Starting System Components and Servers

- 6.6.1 Starting System Components

- 6.6.1.1 Starting Oracle Internet Directory Processes

- 6.6.1.2 Starting Oracle Virtual Directory Processes

- 6.6.1.3 Starting Oracle HTTP Server

- 6.6.2 Starting Node Manager

- 6.6.3 Starting the Oracle WebLogic Administration Server

- 6.6.4 Starting the Managed Server

- 6.6.5 Starting Oracle Management Agent

- 6.7 Task7: Updating the Version Number String Shown in Oracle Enterprise Manager

- 6.8 Task 8: Updating the Oracle Virtual Directory Version String in the Oracle Directory Service Manager

7 Patching Oracle Enterprise Content Management 11g (11.1.1.2.0) with 11g (11.1.1.3.0)

- 7.1 Differences Between Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) and 11g (11.1.1.3.0)

- 7.2 Starting Points for the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

- 7.3 Summary of the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

- 7.3.1 Before You Begin Updating Your Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) Environment

- 7.3.1.1 Stopping the Input Agents in the 11g (11.1.1.2.0) Environment

- 7.3.1.2 Ensuring That All Active Processes Have Completed

- 7.3.2 Configuring the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Domain

- 7.3.3 Moving Configuration Information from Oracle I/PM 11g (11.1.1.2.0) to 11g (11.1.1.3.0)

- 7.3.3.1 Task 1: Start the Administration Server and Node Manager in the New Domain

- 7.3.3.2 Task 2: Update the Security Settings in the New Domain

- 7.3.3.3 Task 3: Configure the Credentials and Create a Workflow Connection for the New Domain

- 7.3.3.4 Task 4: Configure the Policy Stores in the New Domain

- 7.3.3.5 Task 5: Update the Input Agent Directories in the New Domain

- 7.3.3.6 Task 6: Update the Oracle I/PM Configuration Settings in the New Domain

- 7.3.3.7 Task 7: Configure Oracle UCM for the New Oracle I/PM Instance

- 7.3.3.8 Task 8: Upgrade Oracle UCM 10g to Oracle UCM 11g

- 7.3.3.9 Task 9: Verify Any Oracle I/PM Integrations

- 7.3.4 Moving Configuration Information from Oracle IRM 11g (11.1.1.2.0) to 11g (11.1.1.3.0)

- 7.3.4.1 Task 1: Move the Oracle IRM Configuration File to the New Domain

- 7.3.4.2 Task 2: Copy Oracle IRM Key Store to the New Domain

- 7.3.4.3 Task 3: Copy the Oracle IRM Key Store Credentials to the New Domain

A Patch Set Installer Screens

- A.1 Welcome Screen

- A.2 Specify Installation Location Screen

- A.3 Specify Security Updates Screen

- A.4 Installation Summary Screen

- A.5 Installation Progress Screen

- A.6 Installation Complete Screen

B Sample Patch Master Properties File

C Migrating the Oracle Portal Schema Located in a Customer Database

Index

Preface

The Oracle Fusion Middleware Installation Planning Guide covers common Oracle Fusion Middleware concepts that affect installation, installation procedures, and troubleshooting.

Intended Audience

This guide is intended for users who are installing Oracle Fusion Middleware products for the first time and are comfortable running some 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 installing Oracle Fusion Middleware need root access to run some scripts.

Documentation Accessibility

Our goal is to make Oracle products, services, and supporting documentation accessible to all users, including users that are disabled. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.

Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

Deaf/Hard of Hearing Access to Oracle Support Services

To reach Oracle Support Services, use a telecommunications relay service (TRS) to call Oracle Support at 1.800.223.1711. An Oracle Support Services engineer will handle technical issues and provide customer support according to the Oracle service request process. Information about TRS is available at http://www.fcc.gov/cgb/consumerfacts/trs.html, and a list of phone numbers is available at http://www.fcc.gov/cgb/dro/trsphonebk.html.

Related Documents

For additional information, see the following manuals:

- Oracle Fusion Middleware Repository Creation Utility User's Guide

- Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite

- Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server

- Oracle Fusion Middleware Installation Guide for Oracle SOA Suite

- Oracle Fusion Middleware Installation Guide for Oracle WebCenter

- Oracle Fusion Middleware Installation Guide for Oracle Identity Management

- Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer

- Oracle Fusion Middleware Installation Guide for Oracle Web Tier

- Oracle Fusion Middleware Administrator's Guide

- Oracle Fusion Middleware Concepts

- Oracle Fusion Middleware High Availability Guide

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 Oracle Fusion Middleware Patching and Upgrade Overview

This book describes the tools available for you to patch your existing Oracle Fusion Middleware or upgrade your existing Oracle Application Server environment.

The following topics are covered:

1.1 Patching and Upgrade Terminology

This section describes various terms that you should be familiar with before you continue.

1.1.1 Patching

Patching involves copying a small collection of files over an existing installation. A patch is normally associated with a particular version of an Oracle product and involves updating from one minor version of the product to a newer minor version of the same product (for example, from version 11.1.1.2.0 to version 11.1.1.3.0).

A patch set is a single patch that contains a collection of patches designed to be applied together.

1.1.2 Migration

Migration typically involves moving from a third-party (non-Oracle) product to an Oracle product.

It can also be used to refer to moving an existing set of software parameters (for example, an existing configuration or existing domain) from one release to another. For this release, instructions for migrating your configuration from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) to Release 1 (11.1.1.2.0) are provided in Chapter 3, "Using Patch Assistant to Migrate from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) to Release 1 (11.1.1.2.0)".

1.1.3 Upgrade

Upgrade involves moving from a previous major version to a new major version. For example, an upgrade would be required to move from Oracle Application Server 10g to Oracle Fusion Middleware 11g. Similarly, an upgrade is required to move from Oracle Fusion Middleware 11g Release 1 (11.1.1.3.0) to 11g Release 2 (11.1.2.0.0).

For this release, instructions for upgrading from Oracle Application Server 10g to Oracle Fusion Middleware 11g are provided.

1.1.4 Installation

Installation is when new software is copied onto your system for use. After the new software is installed, you can patch it or upgrade it as necessary.

1.2 Patching and Upgrade Tools

Table 1-1 provides a brief summary of the patching and upgrade tools, and provides pointers to more detailed information.

Table 1-1 Summary of Patching, Migration, and Upgrade Tools

Tool

Description

More Information

OPatch

OPatch is typically used to patch the software on your system by copying a small collection of files over your existing installation.

In Oracle Fusion Middleware, OPatch is used to patch an existing Oracle Fusion Middleware 11g installation.

Chapter 2, "Patching Oracle Fusion Middleware with Oracle OPatch"

Smart Update

Smart Update is used to patch your existing Oracle WebLogic Server installation.

Oracle Fusion Middleware products require the presence of Oracle WebLogic Server and its directory structure on your system. When you update your Oracle Fusion Middleware software, you must also update the version of Oracle WebLogic Server on your system using the Smart Update tool.

Oracle Smart Update Installing Patches and Maintenance Packs

Patch Set Installer

The Patch Set Installer is used to update your existing Fusion Middleware product to the latest version. At the time of publication, the latest version is 11g (11.1.1.3.0). The Patch Set Installer updates the software in the product's Oracle home directory; when you run the Patch Set Installer you will need to provide the location of your existing Middleware home and Oracle home directories.

The Patch Set Installer does not provide any mechanisms for configuring your product, so after the installation is complete, you must run the Configuration Wizard for your product before you can start using your product.

Chapter 4, "Applying the Latest Oracle Fusion Middleware Patch Set"

Patch Set Assistant

Patch Set Assistant is used to update your database schemas to prepare them for use with the latest version of Oracle Fusion Middleware software.

This tool is used with Patch Set updates only; Repository Creation Utility (RCU) should always be used to create and drop schemas.

Chapter 5, "Updating Your Schemas with Patch Set Assistant"

Upgrade Assistant

The Upgrade Assistant is used to upgrade from Oracle Application Server 10g to Oracle Fusion Middleware 11g.

Oracle Fusion Middleware Upgrade Planning Guide

2 Patching Oracle Fusion Middleware with Oracle OPatch

This document describes patching in an Oracle Fusion Middleware environment.

The following topics are covered:

- Section 2.1, "About Patching"

- Section 2.2, "About OPatch"

- Section 2.3, "OPatch in a Fusion Middleware Environment"

- Section 2.4, "Running OPatch"

- Section 2.5, "Troubleshooting OPatch in a Fusion Middleware Environment"

2.1 About Patching

Patches are a small collection of files copied over to an existing installation. They are associated with particular versions of Oracle products.

2.1.1 Types of Patches That can be Used with OPatch

OPatch can be used for the following types of patches:

A patch set exception (also known as a PSE, one-off, or interim patch)

This is usually a single fix for a single problem. One-offs in ST products (GC, DB/AS Control etc) are packaged and applied via OPatch. One-offs are bug fixes given to customers in critical need and are not cumulative, regressed or versioned. You can use the opatch lsinventory command to see which one-off patches are installed on your system.

A patch bundle (also known as an MLR patch)

This type of patch is created by putting several fixes into a single patch. This is usually done if several fixes are needed and the various interim patches apply to the same modules and cause the prior patch to be removed if applied individually as they can not coexist. Patch bundles are also applied using OPatch and metadata information about them are also kept in a set of XML files in the inventory and manipulated by OPatch.

Security Patches (also known as Critical Patch Updates or CPUs)

Security patches are different from other patch types in that they only fix a single or small number of problems, and that they should be applied as soon as possible – when a security patch is released extra attention is brought to the existence of the security problem. CPUs are periodic security bundles released by Oracle and are very much like interim patches and will be applied just like an interim patch using OPatch. Just like interim patches, CPUs are not versioned.

Patch Set Updates (PSUs)

Patch Set Updates are released on a quarterly basis, following the same schedule as the Critical Patch Updates (CPUs). These come out the closest Tuesday to the 15th of the months of January, April, July and October. Patch Set Update content is intended to address the top fifty critical bugs affecting the broad customer base.

2.1.2 Types of Patches That can not be Used with OPatch

The only type of patch that cannot be used with OPatch is a patch set. A patch set contains a large number of merged patches, is thoroughly tested, changes the version of the product it is applied to, can sometimes introduce new functionality, and should be applied when suitable. Patch sets are cumulative bug fixes that fix all bugs and consume all patches since the last base release. Patch sets are usually applied through OUI-based product specific installers.

2.2 About OPatch

OPatch is a Java-based utility that runs on all supported operating systems and requires installation of the Oracle Universal Installer. This document contains information pertaining to OPatch commands that are most commonly used in an Oracle Fusion Middleware environment. You can use all supported OPatch commands if you choose; for a full list of OPatch commands and for more information about the OPatch utility, refer to the Oracle Universal Installer and OPatch User's Guide at the following URL:

http://download.oracle.com/docs/cd/E11882_01/em.112/e12255/toc.htm

This section contains the following:

- Section 2.2.1, "Getting OPatch"

- Section 2.2.2, "Getting Patches"

- Section 2.2.3, "OPatch Environment Variables"

- Section 2.2.4, "OPatch System Requirements"

- Section 2.2.5, "Backup and Recovery Considerations for Patching"

2.2.1 Getting OPatch

OPatch can be found in your Fusion Middleware product's ORACLE_HOME/OPatch (on UNIX operating systems) or ORACLE_HOME\OPatch (on Windows operating systems) directory.

Oracle recommends that you always check for and obtain the latest version of OPatch from My Oracle Support (formerly Oracle MetaLink).

1. Access and log into My Oracle Support at the following location:

http://support.oracle.com/

2. In the Search Knowledge Base field, enter 224346.1. This is the ID of the document that describes how to obtain the latest version of OPatch.

3. In the search results, click on the link corresponding to document ID 224346.1.

4. In the document, click on the Patch 6880880 link which will take you to the screen where you can obtain the latest version of OPatch based on release versions and platforms.

2.2.2 Getting Patches

You can obtain the latest patches by specifying the patch ID in My Oracle Support (formerly MetaLink):

1. Access and log into My Oracle Support at the following location:

http://support.oracle.com/

2. Click the Patches & Updates link.

3. Enter the Patch ID or Number, then click Search. A Patch Search Results table appears.

4. Using the Release and Platform columns, find the desired patch, then click the associated Patch ID.

5. In the page that now appears, click the Download button in the right-hand column.

2.2.3 OPatch Environment Variables

OPatch uses the environment variables listed in Table 2-1:

Table 2-1 OPatch Environment Variables

Variable

Description

ORACLE_HOME

Points to the location of the Oracle home directory.

MW_HOME

Points to the location of the Middleware home directory.

PATH

Points to the location(s) from which various commands should be run.

2.2.4 OPatch System Requirements

The OPatch utility has the following requirements:

- The ORACLE_HOME environment variable must point to a valid Oracle home directory and match the value used during installation of the Oracle home directory.

- If the -invPtrLoc command-line argument was used during installation, then it must be used when using the OPatch utility. Oracle recommends the use of the default central inventory for a platform.

- The java, ar, cp, and make commands must be available in one of the directories listed in the PATH environment variable. The commands are not available for all platforms.

2.2.5 Backup and Recovery Considerations for Patching

It is highly recommended that you back up the ORACLE_HOME before any patch operation. You can back up the ORACLE_HOME using your preferred method. You can use any method such as zip, cp -r, tar, and cpio to compress the ORACLE_HOME.

If the ORACLE_HOME does not appear when you execute the opatch lsinventory -detail command, the ORACLE_HOME might be missing from the Central Inventory, or the Central Inventory itself could be missing or corrupted.

If the ORACLE_HOME is listed when you execute the opatch lsinventory -detail command, but the products and components within the ORACLE_HOME are not listed, the inventory within the ORACLE_HOME (local inventory) might be missing or corrupted.

If the local inventory is corrupted or lost for some reason, you can simply restore the ORACLE_HOME/inventory (on UNIX operating systems) or ORACLE_HOME\inventory (on Windows operating systems) if it was backed up. If a backup does not exist, you may have to reinstall the software.

2.3 OPatch in a Fusion Middleware Environment

This section describes the Oracle OPatch utility as it pertains to an Oracle Fusion Middleware environment. You should be familiar with the Oracle Fusion Middleware concepts introduced in the Oracle Fusion Middleware Installation Planning Guide, which is available at the following URL:

http://download.oracle.com/docs/cd/E15523_01/install.1111/b32474/toc.htm

This section contains the following:

- Section 2.3.1, "A Typical Patching Scenario"

- Section 2.3.2, "Patching a Fusion Middleware Product"

- Section 2.3.3, "Patching in a Distributed Environment"

- Section 2.3.4, "Patching Artifacts Deployed Outside the Oracle Home"

2.3.1 A Typical Patching Scenario

Consider a common, non-distributed Fusion Middleware topology for Oracle SOA Suite and Oracle WebCenter, as show in Figure 2-1:

Note:
OPatch can be used to patch any Fusion Middleware product, even though only a few are shown in this example. OPatch can not be used to patch Oracle WebLogic Server.

Figure 2-1 Common Fusion Middleware Topology for Oracle SOA Suite and Oracle WebCenter

Suppose you have a problem in the SOA Domain. Below is a typical patching process:

Step 1. Contact Oracle Support

You can contact your Oracle support representative, or you can go to My Oracle Support (formerly OracleMetaLink):

http://support.oracle.com/

Step 2. Check for Existing Patches

If Oracle Support is not able to resolve the issue, they may ask to see if you have any patches already installed on your system. To determine this information, you should run the opatch lsinventory command.

To check if a particular patch is installed in the Oracle home (or the set of Oracle homes within a Middleware home) you use the opatch checkInstalledOneOffs command. See Section 2.4.7, "Listing Patches Applied to an Oracle Home or WebLogic Domain" for more information about this command.

Step 3. Obtain OPatch and the Necessary Patch

Upon determining that you are in need of a new patch and it has not already been installed on your system, you should do the following:

1. Make certain that you have the latest version of OPatch, as described in Section 2.2.1, "Getting OPatch".

2. Obtain the patch as described in Section 2.2.2, "Getting Patches".

Step 4. Determine the Oracle Home

Once you obtain the patch, determine the Oracle home directory to which you are going to apply the patch.

The most common type of patch available in a Fusion Middleware environment involves patching a specific Oracle home directory. Some patches (for example, a patch pertaining to JRF) may apply to multiple Oracle home directories within a specific Middleware home. A third type of patch could involve client components in one Oracle home and server components in a different Oracle home (for example, Oracle WebCenter in the WebCenter Oracle home depends on BPEL Process Manager in the Oracle SOA Suite Oracle home).

If you do not know the name of your Oracle home, you should run the opatch lshomes command as described in Section 2.4.6, "Listing the Applicable Oracle Homes for a Patch" to obtain a list of Oracle homes that pertain to the domain. In this example, the Oracle home to which the patch should be applied is the SOA Oracle home.

After you determine your Oracle home, you should run the opatch checkApplicable command as described in Section 2.4.6, "Listing the Applicable Oracle Homes for a Patch" to make sure that the patch can actually be applied to the Oracle home.

As the Middleware home is the top-level entity in a Fusion Middleware topology, the location of your Middleware home will be required for many of the OPatch commands in a Fusion Middleware environment.

Step 5. Read the README File

Read the README file that accompanies the patch. This file contains important information and instructions that must be followed prior to applying your patch.

For example, the README file may instruct you apply the patch using the -auto option (described in Section 2.4.1.2, "Using the -auto Option"). The more common scenario is that the README will instruct you to use a series of OPatch commands, including opatch stop and opatch start (see Section 2.4.8, "Starting or Stopping a Runtime Instance").

Step 6. Apply the Patch

After you determine the Oracle home to which you need to apply the patch, you should apply the patch with the opatch apply command as described in Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers".

After Applying the Patch...

In most cases, after you apply the patch the instructions in the README file will tell you to run the opatch start command to re-start your servers.

After the patching is complete and your servers are restarted, you should check your product software to verify that the issue has been resolved.

If for some reason the result is not satisfactory, you can use the opatch rollback command to remove the patch from the Oracle home. See Section 2.4.2, "Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers" for more information, and consult the README file for specific instructions.

2.3.2 Patching a Fusion Middleware Product

Many Fusion Middleware artifacts are deployed to a runtime environment, where applications pick up these binaries for execution. A common example of this are J2EE artifacts (for example, .ear, .war, or .rar files) or J2EE shared libraries deployed to a Managed Server or cluster running within a domain. Patching in a Fusion Middleware environment involves updating and replacing these artifacts in the Oracle home. The servers to which the artifacts are deployed need to be restarted for the changes to take effect.

After the artifacts are deployed, there are various staging modes that affect how WebLogic Server treats these artifacts, which in turn determine how the applications are patched. All artifacts in Oracle Fusion Middleware 11g Release 1 (11.1.1) are deployed in NoStage Mode, which means that each Managed Server must access the archive files from a single source directory for deployment. If a J2EE application is deployed to three Managed Servers within a cluster, each Managed Server must be able to access the same application archive files from a shared or network-mounted directory in order to deploy the new J2EE application.

Take note of the following:

- If multiple Managed Servers on multiple machines are used, the path to the application bits must be the same on all machines because there is a single point of entry for the application in the domain configuration.

- Since the source location for the application bits is fixed and points back to its own ORACLE_HOME location, all domains that were created using a given ORACLE_HOME will pick up the patched bits once the ORACLE_HOME is patched.

- If you are using multiple Managed Servers on multiple machines and the product ORACLE_HOME is not shared or network-mounted on the target Managed Servers, then each machine must have the product installed on an ORACLE_HOME on the local file system from which the Managed Servers can access the application binaries. Therefore, the ORACLE_HOME on each local file system of each machine must be patched separately.

The steps that need to be performed for this scenario are as follows:

1. Use the opatch apply command to apply the bits to an Oracle home.

2. Stop all Managed Servers in the WebLogic Domain to which the application is deployed.

3. Restart all the Managed Servers in the same WebLogic Domain.

Steps 2 and 3 are performed by the Fusion Middleware capabilities in OPatch.

2.3.3 Patching in a Distributed Environment

The process to patch in a distributed environment depends on whether or not your Middleware home directory is shared or not shared.

2.3.3.1 Patching with a Local Middleware Home

Consider the environment shown in Figure 2-2. This is a distributed environment, where you have identical topologies on separate machines, each with its own local Middleware home and Fusion Middleware products inside the Middleware home:

Figure 2-2 Distributed Fusion Middleware Topology for Oracle SOA Suite and Oracle WebCenter

If you encountered a problem in the SOA domain, you would have to patch the corresponding Oracle home on each machine separately, according to the instructions in the README file. After you patch the SOA Oracle home on "Middleware Host 1," for example, you must then repeat the same procedure on "Middleware Host 2."

2.3.3.2 Patching with a Shared Middleware Home

Consider the environment shown in Figure 2-3. This is also a distributed environment, where you have identical topologies on separate machines, but the Middleware home on "Middleware Host 2" is shared or NFS mounted:

Figure 2-3 Distributed Fusion Middleware Topology for Oracle SOA Suite and Oracle WebCenter

In this topology, if you encountered a problem in the SOA Domain, you would only need to patch the SOA Oracle home on either "Middleware Host 1" or "Middleware Host 2" in accordance with the instructions in the README file, and OPatch would automatically patch all of the matching Oracle homes that share the same Middleware home.

2.3.4 Patching Artifacts Deployed Outside the Oracle Home

Some applications, such as Oracle Enterprise Manager Fusion Middleware Control and Oracle Web Services Manager Policy Manager (WSM-PM), are deployed outside of the product Oracle home (in the Oracle Common Home or oracle_common) directory. OPatch can also apply patches to files that reference the oracle_common directory.

2.4 Running OPatch

The OPatch utility is located in the ORACLE_HOME/OPatch (on UNIX operating systems) or ORACLE_HOME\OPatch (on Windows operating systems) directory. Below is the syntax for the OPatch utility:

path_to_opatch/opatch command -options

Acceptable values for command are described in Table 2-2.

Valid options for each command are described in the sections that describe each command.

Table 2-2 Commands for the OPatch Utility in a Fusion Middleware Environment

Command

Description

apply

Apply the patch to an Oracle home and deploy the patch to a WebLogic domain.

For details, see Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers".

rollback

Remove the patch from an Oracle home.

For details, see Section 2.4.2, "Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers".

deploy

Deploy the patch to a WebLogic domain.

For details, see Section 2.4.3, "Deploying Patched Artifacts to WebLogic Servers".

checkApplicable

List all Oracle homes to which a patch can be applied.

For details, see Section 2.4.6, "Listing the Applicable Oracle Homes for a Patch".

lshomes

List the Oracle homes that have been used to create WebLogic Domains.

For details, see Section 2.4.4, "Listing the Source Oracle Homes".

lsdomains

List all WebLogic domains created from the Middleware home or specific Oracle home.

For details, see Section 2.4.5, "Listing the Domains Created from the Middleware Home or Oracle Home".

checkInstalledOneOffs

Check if certain patches are installed on any Oracle homes.

For details, see Section 2.4.7, "Listing Patches Applied to an Oracle Home or WebLogic Domain".

start | stop

Start or Stop a WebLogic Administration Server, Managed Server, or Cluster.

For details, see Section 2.4.8, "Starting or Stopping a Runtime Instance".

To view additional information for these Fusion Middleware options, use the following command:

path_to_OPatch/opatch -help -fmw

2.4.1 Applying Patches and Deploying Patched Artifacts to WebLogic Servers

The apply command in a Fusion Middleware environment applies the patch to the Oracle home on the local machine.

Note:
The option to apply a patch to a Middleware home (including all Oracle homes inside that Middleware home) is not yet available.

2.4.1.1 Using the OPatch Property File

Sensitive information such as Administration Server credentials, and other important information such as the Administration Server URL, domain location and applications directory location, are obtained by prompts from the console. In some cases, default values may be found and specified by OPatch; in these cases, press Enter to use these default values.

Automation applications such as Grid Control and Fusion Applications may invoke OPatch with the -silent option, which does not prompt for any input from the console. To supply the necessary Administration Server credentials and other information, a response file can be created and passed to OPatch as an argument with the -property_file option.

For Fusion Middleware components, userConfigFile and userKeyFile can be specified in the property file as keys with corresponding file names. The userConfigFile file contains an encrypted user name and password, while the userKeyFile contains a secret key that is used to encrypt and decrypt the user name and password. Similarly, the AdminServerURL (URL of the Administration Server), DomainHome (full path to the domains directory) and ApplicationsDir (full path to the applications directory) can also be specified in the properties file.

2.4.1.2 Using the -auto Option

Some patches are certified by Oracle Product Support as capable of being used with the -auto option, which can automate certain portions of your patching procedure. The -auto option applies the patch to the Oracle home; verifies that the patch is actually applied, then performs any necessary redeploy operations against the specified WebLogic Domain, including stopping and starting all the servers that are affected by the patch. If your patch is certified for use with the -auto option, you will be informed of such in the patch's README file.

The -auto option should be used in conjunction with the -domain option; the only exception is if only one WebLogic Domain was configured from the Oracle home. In such cases, OPatch will use that domain as the default domain. If multiple domains have been created and the -domain option is not used, then it is the user's responsibility to run opatch deploy to redeploy the patched artifacts to their respective domains, and also stop and start the affected servers in each of the domains.

2.4.1.3 Using the apply Command

The apply command (with the -auto option specified) performs the following:

1. Stops all affected target servers.
This might involve stopping server instances on other nodes for:

1. Staged mode applications.

2. NoStage mode applications sharing the Oracle home.

2. Applies the patch to the Oracle home on the local machine.

3. Performs any required deploy operations for patched artifacts.

4. Restarts all affected servers.

The syntax for the apply command is shown below:

opatch apply
[-auto [-domain domain_name]]
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-property_file path_to_property_file]
[-report]]

A summary of the options for the apply command are described in Table 2-3.

Table 2-3 Options for the OPatch apply Command

Option

Description

-auto [-domain domain_name]

Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If -auto is used then -domain must also be used to indicate the name of the domain in which the rollout should occur; the exception is when there is only one domain configured out of the Oracle home, in which case the -domain flag is optional.

See Section 2.4.1.2, "Using the -auto Option" for more information.

-mw_home MW_HOME

Optional - The Middleware home to which the patch will be applied. The Middleware home specified here supersedes the MW_HOME environment variable. If neither is specified, then the Middleware home from where the command is run will be used.

-oh ORACLE_HOME

Optional - This option is used to specify the Oracle home to which the patch should be applied. This value supersedes the ORACLE_HOME environment variable. If neither is specified, OPatch will apply the updates to the Oracle home from which it was launched.

-property_file name

Optional - absolute path and name of the property file.

See Section 2.4.1.1, "Using the OPatch Property File" for more information.

-report

Optional - print out the actions that will be taken by executing the command, but does not actually execute the command.

2.4.1.4 Sample Output for the apply Command

Below is a sample output from the opatch apply command on a UNIX operating system:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch apply
-auto /OracleFMW/Middleware_PS1_RC2/FMWPatches/9991008/
-oh /OracleFMW/Middleware_PS1_RC2/oracle_common/
-domain MySOAWebCenterDist
Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/oracle_common
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/oracle_common//oui
Log file location : /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch2009-12-06_09-44-02AM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Please enter the WebLogic Admin Server username:> weblogic
Please enter the WebLogic Admin Server password:>
Please enter the WebLogic Admin Server URL(t3://stadn41:7011):>
Please enter the WebLogic domain directory location(/OracleFMW/MyDomains/domains/MySOAWebCenterDist):>
Please enter the WebLogic applications directory location(/OracleFMW/MyDomains/applications/MySOAWebCenterDist):>
[FMW] Running apply '-auto' prerequisite checks...
[FMW] ProductDriver::preReq_Product() succeeded
[FMW] ProductDriver::preReq_Deploy() succeeded

All the applications affected by this patch are deployed in 'No Stage' mode.
Redeploy operation will not be performed for the affected applications.
Please refer to the log file for more details.

[FMW] ProductDriver::preReq_LifeCycle() succeeded
[FMW] Apply '-auto' prerequisite checks succeeded...

ApplySession applying interim patch '9991008' to OH '/OracleFMW/Middleware_PS1_RC2/oracle_common'

Running prerequisite checks...

You selected -local option, hence OPatch will patch the local system only.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/OracleFMW/Middleware_PS1_RC2/oracle_common')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch '9991008' for restore. This might take a while...
Backing up files affected by the patch '9991008' for rollback. This might take a while...

Patching component oracle.jrf.j2ee, 11.1.1.2.0...
Copying file to "/OracleFMW/Middleware_PS1_RC2/oracle_common/modules/oracle.jrf_11.1.1/jrf-api.jar"

Patching component oracle.jrf.dms, 11.1.1.2.0...
Copying file to "/OracleFMW/Middleware_PS1_RC2/oracle_common/modules/oracle.dms_11.1.1/dms.war"
ApplySession adding interim patch '9991008' to inventory

Verifying the update...
Inventory check OK: Patch ID 9991008 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 9991008 are present in Oracle Home.

The local system has been patched and can be restarted.

[FMW] Ignoring Deploy operations as all patched artifacts are deployed in 'No Stage' mode
[FMW] Performing Auto Post-Deploy Actions
[FMW] Performing Auto Post-Bounce Actions
--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OUI-67851:
All the applications affected by this patch are deployed in 'No Stage' mode.
Redeploy operation will not be performed for the affected applications.
Please refer to the log file for more details.

--------------------------------------------------------------------------------
OPatch Session completed with warnings.

OPatch completed with warnings.

2.4.2 Rolling Back Patches and Deploying Patched Artifacts to WebLogic Servers

The rollback command allows you to remove an existing one-off patch by specifying the unique patch ID.

The rollback command (with the -auto option specified) performs the following:

1. Stops all affected target servers.
This might involve stopping server instances on other nodes for:

1. Staged mode applications.

2. NoStage mode applications sharing the Oracle home.

2. Rolls back the patch on the Oracle home on the local machine.

3. Performs any required deploy operations for patched artifacts.

4. Restarts all affected servers.

The syntax for the rollback option is shown below:

opatch rollback -id patch_id
[-auto [-domain domain_name]]
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-property_file path_to_property_file
[-report]]

A summary of the options for the rollback command are described in Table 2-4.

Table 2-4 Options for the OPatch rollback Command

Option

Description

-id patch_id

Use the -lsinventory option to display all applied patch IDs. Each one-off patch is uniquely identified by an ID. To rollback to a previous patch version, that patch version's ID must be supplied.

-auto [-domain domain_name]

Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If -auto is used then -domain must also be used to indicate the name of the domain in which the rollout should occur; the exception is when there is only one domain configured out of the Oracle home, in which case the -domain flag is optional.

Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information.

-mw_home MW_HOME

Optional - The Middleware home to which the patch will be applied. The Middleware home specified here supersedes the MW_HOME environment variable. If neither is specified, then the Middleware home from where the command is run will be used.

-oh ORACLE_HOME

Optional - This option is used to specify the Oracle home to which the patch should be applied. This value supersedes the ORACLE_HOME environment variable. If neither is specified, OPatch will apply the updates to the Oracle home from which it was launched.

-property_file name

Optional - absolute path and name of the property file.

Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information.

-report

Optional - print out the actions that will be taken by executing the command, but does not actually execute the command.

2.4.3 Deploying Patched Artifacts to WebLogic Servers

This operation deploys modified artifacts from the Fusion Middleware ORACLE_HOME to the Fusion Middleware domain.

The location of the patch binaries must be specified using the -ph option. If the patch is installed in the current Oracle home (the Oracle home from which you are running this command) then the -ph option is not required.

If the patch is already applied to the Oracle home, the -id option can be used to specify the patch you want to use for deployment.

The syntax for the deploy command is shown below:

opatch deploy -id patch_id -ph patch_location
[-auto [-domain domain_name]]
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-property_file path_to_property_file
[-report]]

A summary of the options for the deploy command are described in Table 2-5.

Table 2-5 Options for the OPatch deploy Command

Option

Description

-id patch_id

The unique ID of the patch that is installed in the Oracle home.

-ph patch_location

The absolute path to the location of the patch. If none is specified, then the current directory is used.

-auto [-domain domain_name]

Optional - causes OPatch to automate the rollout of the patch to Oracle Fusion Middleware entities. If -auto is used then -domain must also be used to indicate the name of the domain in which the rollout should occur; the exception is when there is only one domain configured out of the Oracle home, in which case the -domain flag is optional.

Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information.

-mw_home MW_HOME

Optional - The Middleware home to which the patch will be applied. The Middleware home specified here supersedes the MW_HOME environment variable. If neither is specified, then the Middleware home from where the command is run will be used.

-oh ORACLE_HOME

Optional - This option is used to specify the Oracle home to which the patch should be applied. This value supersedes the ORACLE_HOME environment variable. If neither is specified, OPatch will apply the updates to the Oracle home from which it was launched.

-property_file name

Optional - absolute path and name of the property file.

Refer to Section 2.4.1, "Applying Patches and Deploying Patched Artifacts to WebLogic Servers" for more information.

-report

Optional - print out the actions that will be taken by executing the command, but does not actually execute the command.

2.4.4 Listing the Source Oracle Homes

The lshomes command lists all the Oracle homes pertaining to logical entities such as Host or Domain. For a Host, the list of Oracle homes is obtained from the machine's central inventory. For a WebLogic domain, the list of homes is limited to product Oracle homes that are installed within a top-level Middleware home.

If the -domain or -domaindir option is used, the command lists the Oracle homes that have been used to create or extend the WebLogic domain. If not, all the homes registered with the machine's central inventory or the inventory location specified using -invPtrLoc are listed.

The Middleware home can be specified by using the -mw_home option or by setting the MW_HOME environment variable. When the Middleware home is specified and the -domain or -domaindir option is not specified, this command will list all the Oracle homes within the Middleware home that are registered with the machine's central inventory or the specified inventory location.

The syntax for the lshomes option is shown below:

opatch lshomes
[-domain domain_namne | -domain_dir domain_location]
[-mw_home MW_HOME ]
[-invPtrLoc path_to_oraInst.loc]

A summary of the options for the lshomes command are described in Table 2-6.

Table 2-6 Options for the OPatch lshomes Command

Option

Description

-domain domain_name

Optional - list the Oracle homes that have been used to create or extend this WebLogic Domain.

-domain_dir domain_location

Optional - list the Oracle homes that have been used to create or extend the WebLogic Domain at this location.

You must specify the absolute path to the WebLogic Domain.

-mw_home MW_HOME

Optional - list only the Oracle homes registered with the machine's central inventory that are located in this Middleware home.

You must specify the absolute path to the Middleware home directory; this value supersedes the MW_HOME environment variable. If neither is available, the Middleware home from which the command is executed will be used.

-invPtrLoc path_to_oraInst.loc

Optional - absolute path to the location of your oraInst.loc file; this option is needed if the installation was performed using the -invPtrLoc option.

Below is an example of the opatch lshomes command on a UNIX operating system:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch lshomes
-domain MySOAWebCenterDist
Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

UTIL session

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui
Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_10-57-49AM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Invoking utility "lshomes"
Home path = "/OracleFMW/Middleware_PS1_RC2/oracle_common"
Home path = "/OracleFMW/Middleware_PS1_RC2/Oracle_SOA1"
Home path = "/OracleFMW/Middleware_PS1_RC2/Oracle_WC1"
OPatch command 'lshomes' done.

OPatch succeeded.

2.4.5 Listing the Domains Created from the Middleware Home or Oracle Home

The lsdomains command lists all the WebLogic Domains that have been created from a certain Oracle home:

- If the Oracle home is specified, then only those domains created from the specified Oracle home are listed. If no Oracle home is specified, OPatch will list the domains created from the Oracle home as defined by the ORACLE_HOME environment variable. If neither is available, then OPatch will use the Oracle home directory from which the command is run.

- If a Middleware home is specified, all domains created from all Oracle homes within the specified Middleware home are listed.

- If neither is specified, and neither the MW_HOME or ORACLE_HOME environment variable is defined, then OPatch will run the command for the Middleware home from where the command was run.

The syntax for the lsdomains command is shown below:

opatch lsdomains
[-oh ORACLE_HOME]
[-mw_home MW_HOME]
[-invPtrLoc path_to_oraInst.loc]

A summary of the options for the lsdomains command are described in Table 2-7.

Table 2-7 Options for the OPatch lsdomains Command

Option

Description

-oh ORACLE_HOME

Optional - absolute path to the Oracle home directory.

-mw_home MW_HOME

Optional - absolute path to the Middleware home directory.

-invPtrLoc path_to_oraInst.loc

Optional - absolute path to the location of your oraInst.loc file; this option is needed if the installation was performed using the -invPtrLoc option.

Below is an example of the opatch lsdomains command on a UNIX operating system:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch lsdomains
-oh /OracleFMW/Middleware_PS1_RC2/oracle_common
Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

UTIL session

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/oracle_common
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/oracle_common/oui
Log file location : /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch2009-12-06_11-04-41AM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/oracle_common/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Invoking utility "lsdomains"
Domain Name = "MySOAWebCenterDist" Path = "/OracleFMW/MyDomains/domains/MySOAWebCenterDist"
Domain Name = "MyWebCenterOnly" Path = "/OracleFMW/MyDomains/domains/MyWebCenterOnly"
OPatch command 'lsdomains' done.

OPatch succeeded.

2.4.6 Listing the Applicable Oracle Homes for a Patch

This checkApplicable command produces a list of Oracle homes to which the patch can be applied. For Fusion Middleware, this command is limited in scope to the top-level Middleware home:

- If only the Middleware home is specified, OPatch will check to see whether or not this patch can be applied to all Oracle homes within the specified Middleware home.

- If an Oracle home is specified in addition to the Middleware home, OPatch will check to see if the patch can be applied to the specified Oracle home in the specified Middleware home.

- If neither is specified, and neither the MW_HOME or ORACLE_HOME environment variable is defined, then OPatch will run the command for the Middleware home from where the command was run.

The syntax for the checkApplicable command is shown below:

opatch checkApplicable
[-ph patch_location]
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-invPtrLoc path_to_oraInst.loc]

A summary of the options for the checkApplicable command are described in Table 2-8.

Table 2-8 Options for the OPatch checkApplicable Command

Option

Description

-ph patch_location

Optional - location of the patch for which you want to run the checkApplicable command. If not specified, then the patch in the current directory is used.

-mw_home MW_HOME

Optional - absolute path to the Middleware home directory.

-oh ORACLE_HOME

Optional - absolute path to the Oracle home directory.

-invPtrLoc path_to_oraInst.loc

Optional - absolute path to the location of your oraInst.loc file; this option is needed if the installation was performed using the -invPtrLoc option.

Below is an example of the opatch checkApplicable command on a UNIX operating system:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch checkapplicable
-ph /OracleFMW/Middleware_PS1_RC2/FMWPatches/9991008/
Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

UTIL session

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui
Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_10-59-57AM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Invoking utility "checkapplicable"

"checkApplicable" passed for Patch "9991008" and Oracle Home "/OracleFMW/Middleware_PS1_RC2/oracle_common".
"checkApplicable" failed for Patch "9991008" and Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_SOA1".
The details are:
Patch 9991008: Required component(s) missing : [ oracle.jrf.j2ee, 11.1.1.2.0 ] , [ oracle.jrf.dms, 11.1.1.2.0 ]
"checkApplicable" failed for Patch "9991008" and Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_WC1".
The details are:
Patch 9991008: Required component(s) missing : [ oracle.jrf.j2ee, 11.1.1.2.0 ] , [ oracle.jrf.dms, 11.1.1.2.0 ]
Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check.

OPatch command 'checkApplicable' done.
--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OUI-67124:Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check.
--------------------------------------------------------------------------------
OPatch Session completed with warnings.

OPatch completed with warnings.

2.4.7 Listing Patches Applied to an Oracle Home or WebLogic Domain

The checkInstalledOneOffs command checks to see if the specified patch or patches have been applied to certain Oracle homes or WebLogic Domains:

- If a Middleware home is specified, OPatch checks all the Oracle homes within the specified Middleware home that are registered with the machine's central inventory. If not specified, then the MW_HOME environment variable is used.

- If an Oracle home is specified, OPatch checks the patch against the specified Oracle home only.

- If neither is specified, and neither the MW_HOME or ORACLE_HOME environment variable is defined, then OPatch will run the command for the Middleware home from where the command was run.

- If a WebLogic Domain is specified, OPatch checks against all the Oracle homes within the specified WebLogic Domain.

The syntax for the checkInstalledOneOffs command is shown below:

opatch checkInstalledOneOffs -id patch_IDs
[-mw_home MW_HOME]
[-oh ORACLE_HOME]
[-domain domain_name]
[-invPtrLoc path_to_oraInst.loc]

A summary of the options for the checkInstalledOneOffs command are described in Table 2-9.

Table 2-9 Options for the OPatch checkInstalledOneOffs Command

Option

Description

-id patch_IDs

ID of the patch or patches that you want to check. Separate multiple patch IDs with a comma (,) character.

-mw_home MW_HOME

Optional - absolute path to the Middleware home directory.

-oh ORACLE_HOME

Optional - absolute path to the Oracle home.

-domain domain_name

Optional - name of the WebLogic Domain.

-invPtrLoc path_to_oraInst.loc

Optional - absolute path to the location of your oraInst.loc file; this option is needed if the installation was performed using the -invPtrLoc option.

Below is an example of the opatch checkInstalledOneOffs command on a UNIX operating system. In this example, patch 8965224 is installed in the SOA Oracle home and patch 9991008 is installed in the Oracle Common Home:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch checkinstalledoneoffs
-id 8965224,9991008
Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

UTIL session

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui
Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_09-40-41AM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Invoking utility "checkinstalledoneoffs"

"checkInstalledOneOffs" failed for Oracle Home "/OracleFMW/Middleware_PS1_RC2/oracle_common".
Not Installed Patch IDs: [8965224]

"checkInstalledOneOffs" failed for Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_SOA1".
Not Installed Patch IDs: [9991008]

"checkInstalledOneOffs" failed for Oracle Home "/OracleFMW/Middleware_PS1_RC2/Oracle_WC1".
Not Installed Patch IDs: [8965224, 9991008]

Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check.
OPatch command 'checkInstalledOneOffs' done.
--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OUI-67124:Some of the Oracle Homes under the Middleware Home "/OracleFMW/Middleware_PS1_RC2" have failed this check.
--------------------------------------------------------------------------------
OPatch Session completed with warnings.

OPatch completed with warnings.

2.4.8 Starting or Stopping a Runtime Instance

The start and stop commands allow Fusion Middleware runtime entities to be started or stopped, respectively. Only entities of the same type can be started or stopped; if you need to start or stop entities of multiple types, you must run this command separately for each entity type.

In order to run this command:

- Node Manager must be configured and running on the target server machine.

- The WebLogic_Home/common/nodemanager/nodemanager.domains (on UNIX operating systems) or WebLogic_Home\common\nodemanager\nodemanager.domains (on Windows operating systems) must be populated.

- You must be able to connect to the Administration Server, which must be up and running.

The syntax for the start and stop commands is shown below:

opatch start|stop
-domain domain_name
-targets product_entity_name
-target_type product_entity_type
[-oh ORACLE_HOME]

A summary of the options for the start and stop commands are described in Table 2-10.

Table 2-10 Options for the OPatch start and stop Commands

Option

Description

-domain domain_name

The name of the domain in which the specified targets will be started or stopped.

-targets product_entity_name

The name of the WebLogic or Fusion Middleware entity you want to start or stop. Only entities of the same type can be specified; multiple entities should be separated by a comma.

-target_type target_type

The type of WebLogic or Fusion Middleware entity you want to start. Valid values are:

- fmwApplication

- fmwServer

- fmwCluster

- fmwContainer

The fmwContainer option starts or stops the container (for example, the WebLogic Server) hosting the application.

The fmwServer option starts or stops the actual java process that is running (for example, a Managed Server).

-oh ORACLE_HOME

Optional - the absolute path to the Oracle home directory. If this is not specified, the value in the ORACLE_HOME environment variable is used. If neither is available, then the Oracle home from which the command is executed is used.

Below is an example of the opatch start command on a UNIX operating system:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch start
-targets soa_server1
-target_type fmwserver
-domain MySOAWebCenterDist

Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

UTIL session

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui
Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_12-30-31PM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Invoking utility "start"
Please enter the WebLogic Admin Server username:> weblogic
Please enter the WebLogic Admin Server password:>
Please enter the WebLogic Admin Server URL(t3://stadn41:7011):>
[FMW] Performing Start Actions
[FMW] Finished Start Actions
OPatch command 'start' done.

OPatch succeeded.

Below is an example of the opatch stop command on a UNIX operating system:

[aime@stadn41 Oracle_SOA1]$ ./OPatch/opatch stop -targets soa_server1 -target_type fmwserver -domain MySOAWebCenterDist
Invoking OPatch 11.1.0.6.9

Oracle Interim Patch Installer version 11.1.0.6.9
Copyright (c) 2009, Oracle Corporation.  All rights reserved.

UTIL session

Oracle Home       : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1
Central Inventory : /ade/aime_dte6989/oracle/work/EM_SH_1/oraInventory
from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.9
OUI version       : 11.1.0.7.0
OUI location      : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/oui
Log file location : /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch2009-12-06_11-13-59AM.log

Patch history file: /OracleFMW/Middleware_PS1_RC2/Oracle_SOA1/cfgtoollogs/opatch/opatch_history.txt

OPatch detects the Middleware Home as "/OracleFMW/Middleware_PS1_RC2"

Invoking utility "stop"
Please enter the WebLogic Admin Server username:> weblogic
Please enter the WebLogic Admin Server password:>
Please enter the WebLogic Admin Server URL(t3://stadn41:7011):>
[FMW] Performing Stop Actions
[FMW] Finished Stop Actions
OPatch command 'stop' done.

OPatch succeeded.

2.5 Troubleshooting OPatch in a Fusion Middleware Environment

This section describes common issues you may encounter when running the OPatch utility in a Fusion Middleware environment.

2.5.1 Notes About Patching the MDS Repository

For special information about patching the MDS repository, refer to "Applying Patches" in the Oracle Fusion Middleware Administrator's Guide.

2.5.2 Configuring Your Environment for OPatch

Before you can use OPatch, you must make sure to have the following settings properly configured in your environment:

- Section 2.5.2.1, "Setting the StartScriptEnabled Node Manager Property"

- Section 2.5.2.2, "Setting the Machine Name and Listen Address"

2.5.2.1 Setting the StartScriptEnabled Node Manager Property

By default, a server that is started via the Administration Console or WLST is not configured with the required JRF classpath and system properties. This is necessary to ensure that the startup scripts in JRF extended domain, which set up JRF classpath and server properties, are used. Use one of the methods below to configure the StartScriptEnabled setting:

1. Edit the nodemanager.properties file, which is usually located in the WebLogic_HOME/common/nodemanager (on UNIX operation systems) or WebLogic_HOME\common\nodemanager (on Windows operation systems) directory.
Add the following line to the nodemanager.properties file:

StartScriptEnabled=true

2. Run the ORACLE_HOME/common/bin/setNMProps.sh (on UNIX operating systems) or ORACLE_HOME\common\bin\setNMProps.cmd (on Windows operating systems) script before starting the node manager. This script automatically adds StartScriptEnabled=true to the nodemanager.properties file in the WebLogic_HOME/common/nodemanager (on UNIX operation systems) or WebLogic_HOME\common\nodemanager (on Windows operation systems) directory.

3. Add the -DStartScriptEnabled=true property to the JAVA_OPTIONS environment variable, then run the WebLogic_Home/server/bin/startNodeManager.sh (on UNIX operating systems) or WebLogic_Home\server\bin\startNodeManager.cmd (on Windows operating systems) script.

2.5.2.2 Setting the Machine Name and Listen Address

The machine name of the Administration Server and Managed Servers must be set to a valid value. It cannot be set to blank or None.

The listen address of the Administration and Managed Servers must be set to the real physical host's address (hostname, FQDN, or IP address). It cannot be set to blank or localhost.

These values need to be properly set only once; you will not need to reset them should you ever need to patch your software.

To set the machine name and listed address of the Managed Servers:

1. Open the Administration Console.

2. In the Domain Structure, navigate to domain_name > Environments > Machines.

3. If your WebLogic Server is running in Production Mode, click the Lock & Edit button on the left hand side. If your WebLogic Server is running in Development Mode, this step is not needed.

4. Click the New button to create a new machine. Specify a name and select the operating system.

5. Select the machine you just created, go to Configuration > Node Manager and change the Listen Address to the host on which the Node Manager is listening, then click the Save button.

6. In the Domain Structure, navigate to domain_name > Environments > Servers.

7. For each Managed Server, assign the machine you just created. In the Listen Address field, specify the name of the host on which the Node Manager is listening. Click Save when you are finished.

8. If your WebLogic Server is running in Production Mode, click the Activate Changes button on the left hand side. If your WebLogic Server is running in Development Mode, this step is not needed.

To set the machine name and listen address of the Administration Server:

1. Stop the Administration Server and all Managed Servers.

2. Back up the config.xml file in the domain.
The default location of this file is MW_HOME/user_projects/domains/domain_name/config (on UNIX operating systems) and MW_HOME\user_projects\domains\domain_name\config (on Windows operating systems).

3. Modify the existing config.xml file as follows:

1. Find the following line:

<name>AdminServer</name>

2. Add the following lines:

<machine>host_name</machine>
<listen-address>host_name</listen-address>

3. Save the file.

4. Restart the Administration Server and all the Managed Servers.
If you encounter any problems, revert back to the saved version of the config.xml file and contact Oracle Support.

3 Using Patch Assistant to Migrate from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) to Release 1 (11.1.1.2.0)

This chapter contains the following sections:

- What is a Patch Set?

- Overview of Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) Patch Assistant

- Migration Process

- Preparing to Migrate

- Migrating to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0)

3.1 What is a Patch Set?

Patch set is a mechanism for delivering fully tested and integrated product fixes. A patch set includes all files that have been rebuilt to implement the bug fixes. All of the fixes in the patch set have been tested and are certified to work with one another.

Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) is cumulative and includes all of the fixes from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0).

Patch sets contain generic fixes that apply to all platforms and may also include platform-specific fixes.

Note:
To download free installation documentation, release notes, white papers, or other collateral, go to Oracle Technology Network (OTN). You must register online before using OTN; registration is free and can be done at:
http://www.oracle.com/technology/membership

If you already have a user name and password for OTN, then you can go directly to the documentation section of the OTN Web site at:

http://www.oracle.com/technology/documentation

3.2 Overview of Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) Patch Assistant

Patch Assistant enables you to migrate your existing configuration of Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) components, used in conjunction with the 11.1.1.1.0 and 11.1.1.2.0 installations. Patch Assistant is not a complete software distribution. You must run this Patch Assistant over an existing Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) installation. Patch Assistant is designed to work with all Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) products. You may see messages that an Oracle product is not present in a domain or instance. This message is informational and does not indicate an error.

Refer to Table 3-7 for the Oracle Fusion Middleware components supported by Patch Assistant.

Note:
Patch Assistant is used only for updating Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) Domains and Oracle Instances. If you are not updating your existing 11.1.1.1.0 domains and instances, you are not required to use Patch Assistant.

Patch Assistant helps to migrate the following from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0):

- Oracle Fusion Middleware Domains

Note:
It is required that you migrate the entire Oracle WebLogic domain. When the domain is migrated, all components in the domain are also migrated.

- Oracle Instances

- Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) database schema created using Oracle Repository Creation Utility (RCU)

Note:
You must migrate both the schema and the middle tier.

When you run Patch Assistant tool, the configuration files contained in the Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) domain and Instance directories are copied to the new directories in the Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) installation. The Middleware home is the full path of the Oracle directory that contains the Oracle Fusion Middleware installation, and MW_HOME will be used in this documentation to refer to the directory where the product is installed.

Note:
MW_HOME must be replaced with the full path name of the installed Oracle Fusion Middleware instance.

3.3 Migration Process

Figure 3-1 illustrates the migration process. Review this chart to get familiar with the steps you are required to take, based on your existing Oracle Fusion Middleware environment.

Figure 3-1 Flow Chart of the Migration Process

3.4 Preparing to Migrate

This section contains important information you should read before you migrate.

3.4.1 Evaluating and Reviewing your Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) Environment

The first step in the migrating process is to evaluate your current Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) environment. During the migration process, the topology of the deployment must not change, the port configuration must be retained, and there must be minimal changes in namespaces. All the changes in the namespaces are encapsulated by the properties in the patchMaster.properties file, which is included in the fmw11gR1ps1_patchassist.zip file.

For a list of products included in this patch set, see Section 3.5.7, "Oracle Fusion Middleware Components Supported by Patch Assistant".

3.4.2 Preparing to Migrate Your Configuration

This section discusses the following topics:

- Prerequisites

- Extracting the Contents of Patch Assistant

- Setting Up the Patch Assistant Environment

- Stopping Oracle Fusion Middleware

- Setting Logging Properties

3.4.2.1 Prerequisites

This section describes the general and product-specific prerequisites for running Patch Assistant.

This section discuss the following topics:

- General Prerequisites

- Product-Specific Prerequisites

3.4.2.1.1 General Prerequisites

The following are the general prerequisites for running Patch Assistant:

- Ensure that Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) is installed and configured.

- Ensure that you install 11.1.1.2.0 on the same operating system used by the 11.1.1.1.0 installation.

- Ensure that the system configuration meets the recommended system configuration described in your product documentation. For more information, see http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html.

- Ensure that you have Apache Ant 1.7.0 and Java JDKs (Java SE 6 1.6.0_11 and jrockit_160_05_R27.6.2-20), which are packaged with Oracle WebLogic Server.

Note:
If you are using Oracle Internet Directory, Oracle Virtual Directory, Oracle HTTP Server, or Oracle Web Cache as standalone Oracle Fusion Middleware installations, you must install and configure Apache Ant separately. For more information, see Installing Ant at http://ant.apache.org/manual/installlist.html and Section 3.4.2.3, "Setting Up the Patch Assistant Environment".

- Make a detailed note of the topology used for the Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) installation.

- Ensure that you do not change the port configuration and instance names in your existing Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) installation.

- Ensure that the environment variables for tmp and temp directories for Microsoft Windows are set, as described in the Oracle Fusion Middleware Administrator's Guide.

- Back up your Oracle software, inventory, schema, and domain before applying this patch set, or before making any other changes to your existing Oracle software. Refer to your product administrator's guide for instructions on backing up your Oracle software and inventory. For more information, see the "Advanced Administration: Backup and Recovery" part in the Oracle Fusion Middleware Administrator's Guide.

- On Windows, it is recommended that you edit the patchMaster.properties file in a Notepad. If you are using any other text editor, such as Windows WordPad, then save the file as Text Document. Do not save the file in Rich Text Format.

- On Windows, you must delete the service name for Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) before installing Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) because both the installations use the same service name. To do so, run the following Ant task on the command line:

ant master-opmn-delete-service

Enter the required information when prompted by the Ant task.

Note:
If you want to abort the migration and revert to the 11.1.1.1.0 deployment, run the following Ant task on the command line:

ant master-opmn-create-service

- Heterogeneous nodes in a Cluster (one in 11.1.1.2.0, other in 11.1.1.2.0) is not supported during the migration process. You must migrate all nodes to 11.1.1.2.0 before environment can be used.

3.4.2.1.2 Product-Specific Prerequisites

Depending on your Oracle Fusion Middleware component, you may have to meet additional prerequisites as follows:

- Oracle Fusion Middleware Audit Framework

- Oracle Directory Integration Platform

- Oracle Internet Directory and Oracle Virtual Directory

- Oracle WebCenter

- Oracle Portal

Oracle Fusion Middleware Audit Framework

For Oracle Fusion Middleware Audit Framework, the audit policy is configured for Java components in Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0), you must export the configuration before running Patch Assistant, as follows:

1. Log in to Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Expand WebLogic Domain on the left pane, and select your domain.
Your selected domain page is displayed.

3. From the WebLogic Domain, select Security, and then Audit Policy.
The Audit Policy page is displayed.

4. Select the Audit Policy, and click Export.

5. Save the AuditConfiguration file to your machine.

Oracle Directory Integration Platform

For the Oracle Directory Integration Platform, do the following:

1. Ensure that your Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) Oracle Internet Directory is up and running in SSL No-Auth mode.

2. Extend the Oracle WebLogic domain created during the Oracle Internet Directory 11g Release 1 (11.1.1.2.0) installation, by running the following command:
Windows

config.cmd (Located at: ORACLE_HOME\bin)

UNIX

config.sh (Located at: ORACLE_HOME/bin)

The Oracle Fusion Middleware Configuration Wizard appears. Enter the Oracle Internet Directory 11g Release 1 (11.1.1.2.0) connection details and credentials.

3. Stop the Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) domain.

Oracle Internet Directory and Oracle Virtual Directory

Depending on your installation, complete the following prerequisites:

- If your 11.1.1.1.0 configuration has Oracle Internet Directory and Oracle Virtual Directory created with a new Oracle WebLogic domain, then choose the Create a new WebLogic domain option on the Welcome screen of the Oracle Fusion Middleware Configuration Wizard when configuring the 11.1.1.2.0 domain.
During the configuration of 11.1.1.2.0, if you select the Create a new WebLogic domain option, then you must deselect Oracle Internet Directory and Oracle Virtual Directory, and select Oracle Directory Services Manager.

- If your Oracle Internet Directory and Oracle Virtual Directory are not registered to any Oracle WebLogic domain in your 11.1.1.1.0 configuration, then 11.1.1.2.0 configuration is not required. You must set the property patchMaster.Oracleinstancenewlist in the patchMaster.properties file to a new directory for the instance. Ensure that you retain the same instance name used in 11.1.1.1.0.

- If your 11.1.1.1.0 configuration has Oracle Internet Directory and Oracle Virtual Directory registered to an existing Oracle WebLogic domain, then 11.1.1.2.0 configuration is not required. You must set the property patchMaster.Oracleinstancenewlist in the patchMaster.properties file to a new directory and register the instance with the existing 11.1.1.2.0 WebLogic domain using Ant target. Ensure that you retain the same instance name used in 11.1.1.1.0.

Oracle WebCenter

To migrate Oracle WebCenter, you may choose either of these approaches:

- Keep two parallel instances of Oracle WebCenter, that is 11.1.1.1.0 as well as 11.1.1.2.0. To do this, you must perform a complete installation of Oracle WebCenter 11.1.1.2.0. You can then migrate your Oracle WebCenter 11.1.1.1.0 data into the new WebCenter instance by using the export and import utilities. This approach enables you to use both instances of Oracle WebCenter, if required. For example, you may run the two instances in parallel to minimize downtime or to ensure that the 11.1.1.2.0 instance is set up to the same level as the 11.1.1.1.0 instance before you switch over to the 11.1.1.2.0 instance completely.
For information about how to install Oracle WebCenter, see the Oracle Fusion Middleware Installation Guide for Oracle WebCenter. For information about export and import utilities, see the "Managing Export, Import, Backup, and Recovery of WebCenter" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

- Migrate the Oracle WebCenter 11.1.1.1.0 repository and mid-tier completely to Oracle WebCenter 11.1.1.2.0. This approach preserves your Oracle WebCenter 11.1.1.1.0 repository data and enables you to reuse the repository.
This guide describes the tasks required to implement this migration approach for Oracle WebCenter.

Oracle Portal

Before updating, you should backup your OmniPortlet and WebClipping customizations. For more information, see Section 4.6.5.1, "Saving and Restoring OmniPortlet and WebClipping Customizations for Oracle Portal and Oracle WebCenter".

3.4.2.2 Extracting the Contents of Patch Assistant

You can download the fmw11gR1ps1_patchassist.zip, which is included in the Oracle Fusion Middleware 11g Release 1 Patch Set 1 Patch Scripts media. The zip file is available in the same media pack as Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) on Oracle Technology Network (OTN) at the following URL: http://oracle.com/technology

After downloading this zip file, extract its contents to its own location, in your local machine, where the old and new Oracle Fusion Middleware components are installed. Ensure that the same operating system is used for the 11.1.1.1.0 and 11.1.1.2.0 installations. The zip file includes the following files:

- README – Describes the environment.

- patchMaster.properties - The user input file.

- build.xml – The master build file. Each Oracle Fusion Middleware component has its own build.xml file.

3.4.2.3 Setting Up the Patch Assistant Environment

To set up the Patch Assistant environment for Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0), you must set up ANT_HOME, add it to your PATH, set the JAVA_HOME and the permgen size.

For example, on Windows:

set ANT_HOME=MW_HOME\modules\org.apache.ant_1.7.0
set PATH=%PATH%;%ANT_HOME%\bin
set JAVA_HOME=MW_HOME\jdk160_14_R27.6.4-18
set ANT_OPTS=-Xmx512M -XX:MaxPermSize=512m

For example, on UNIX:

setenv MW_HOME ##set mw home here##
setenv ANT_HOME $MW_HOME/modules/org.apache.ant_1.7.0
setenv PATH $ANT_HOME/bin:$PATH
setenv JAVA_HOME $MW_HOME/jdk160_14_R27.6.5-32
setenv ANT_OPTS "-Xmx512M -XX:MaxPermSize=512m"

3.4.2.4 Stopping Oracle Fusion Middleware

Before you run Patch Assistant, you must stop the following:

- Oracle WebLogic Server

- Administration Servers

- Managed Servers

- Oracle Management Agent

- Java EE Applications

- High Availability Environments

For more information, see the Starting and Stopping Oracle Fusion Middleware chapter in the Oracle Fusion Middleware Administrator's Guide.

3.4.2.5 Setting Logging Properties

You can use the log file to verify the migration or to detect any errors after running Patch Assistant. Patch Assistant creates a time stamp file in the Patch Assistant home. You can specify the following logging levels:

- info (This is the default setting)

- error

- warning

- verbose

- debug

Note:
The debug and the verbose options may display sensitive information in the logs, and they are not recommended for typical use.

Before you use your log file, you must set the logging properties as follows:

Open the patchMaster.properties file in a text editor, and update the following properties:

# Description: Specifies the directory where the log files go
patchMaster.Logdir=${patchMaster.Dir}

Specifies the default location where the log file is saved.

# Description: Specifies the logging level to be recorded in the log file
patchMaster.Loglevel=info

Sets the logging level.

To override the default patchMaster.properties Log level, run the command as shown in the following example:

ant -DpatchMaster.Loglevel=error

Note:
You can override the patchMaster.properties by setting properties on the command line. If the debug or verbose options are used on the command line, they override the logging level property set in the patchMaster.properties file. For more information, see Section 3.5.6.1, "Overriding Properties Set in the patchMaster.properties File".

3.5 Migrating to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0)

This sections contains migration instructions. The following topics are covered:

- Migration Roadmap

- Migration Procedure

- Post-Migration Configuration for Oracle Fusion Middleware Components

- Installation Process

- Configuration Process

- Properties in the patchMaster.properties File

- Oracle Fusion Middleware Components Supported by Patch Assistant

3.5.1 Migration Roadmap

Table 3-1 describes the high-level tasks for migrating from Oracle Fusion Middleware 11.1.1.1.0 to 11.1.1.2.0. The table also provides information on where to get more details on each task.

Table 3-1 Tasks in the Migration Procedure

Task

Description

Documentation

Mandatory or Optional?

Task 1 - Prepare Environment with General Prerequisites, such as Backing Up Existing Configuration and Retaining Ports and Instance Names

Complete all general prerequisites for running Patch Assistant.

For more information, see Section 3.4.2.1.1, "General Prerequisites".

Mandatory

Task 2- Prepare Environment with Product-Specific Prerequisites, if any

Complete all product-specific prerequisites for running Patch Assistant, as applicable.

For more information, see Section 3.4.2.1.2, "Product-Specific Prerequisites".

Optional

Task 3 - Stop All Oracle Fusion Middleware 11.1.1.1.0 Domains and Instances

Ensure that you stop all Oracle Fusion Middleware 11.1.1.1.0 domains and instances.

For more information, see Section 3.4.2.4, "Stopping Oracle Fusion Middleware" and Section 3.5.2.1, "Stopping the Old Domain".

Mandatory

Task 4 - Install Software (Oracle WebLogic Server, Repository Creation Utility, and Oracle Products) for 11.1.1.2.0

Install Oracle software, including Oracle WebLogic Server, Repository Creation Utility, and Oracle products for 11.1.1.2.0. Do not create or configure a WebLogic domain at this stage of the migration process.

Install the Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) and its components in a separate Middleware home on the same host as the Oracle Fusion Middleware 11g Release 1 (11.1.1) MW_HOME. Ensure that you stop the Oracle Fusion Middleware components for 11.1.1.1.0, before you begin the installation. This will enable the 11.1.1.2.0 installation to retain the same 11.1.1.1.0 port number, host name, and machine name.

Installation instructions for Oracle WebLogic Server are provided in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

For system requirements information, go to:

http://www.oracle.com/technology/software/products/ias/files/fusion_requirements.htm

For certification information, go to:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

For information about installing Oracle products, refer to the product-specific installation guides.

Mandatory

Task 5 - Download the Patch Assistant Zip File

Download the Patch Assistant zip file and extract its contents.

After unzipping, configure Patch Assistant before editing the properties.

For more information, see Section 3.5.2.3, "Downloading Patch Assistant".

Mandatory

Task 6 - Set Up the patchMaster.properties File and Run Patch Assistant for Schema Only

Ensure that the Oracle database that contains the 11.1.1.1.0 schemas is up and running. This will allow access to the SCHEMA_VERSION_REPOSITORY table by Patch Assistant.

Specify the schema-related properties in the patchMaster.properties file, and run the ant master-patch-schema command to migrate the schema only.

Note: For Oracle Portal, you must complete the steps in Task 7, 8, and 9, and then follow the steps to migrate the schema. It is recommended that you refer to the following topics in the Oracle Fusion Middleware Upgrade Guide for Oracle Portal, Forms, Reports, and Discoverer before you run Patch Assistant to migrate the schema:

- Understanding the Impact of the Oracle Portal Schema Upgrade

- Checking for Invalid Objects in the Database Where the Oracle Portal 10g Schema Resides

- Backing Up the Database Where the Oracle Portal 10g Schema Resides

- Verifying the Required Database Parameters for Oracle Portal 11g

- Verifying That the Database and Oracle Internet Directory Are Running

Log files specific to Oracle Portal migration are generated in the upgrade.log and precheck.log files in the ORACLE_HOME/upgrade/logs directory (UNIX).

If your Oracle Portal repository is not stored in the Oracle Metadata Repository, and is instead installed in a separate database, then do not use the procedures in this section. Instead, refer to Appendix C, "Migrating the Oracle Portal Schema Located in a Customer Database".

For more information, see Section 3.5.2.4, "Migrating the Schema".

Mandatory

Task 7 - Use the Oracle Fusion Middleware Configuration Wizard (config.sh) to Create and Configure a WebLogic Domain for 11.1.1.2.0

Create and configure a WebLogic administration domain for your 11.1.1.2.0 installation. Ensure that you configure the domain as it was in your 11.1.1.1.0 installation.

For more information, see Section 3.5.2.5, "Creating a WebLogic Domain for 11.1.1.2.0" and the product-specific installation guides.

Mandatory

Task 8 - Set Up the patchMaster.properties File and Run Patch Assistant for Domain

Specify the domain-related properties in the patchMaster.properties file, and run the ant master-patch-domain command to migrate the WebLogic domain.

You must patch all products in the domain being migrated.

For more information, see Section 3.5.2.6, "Migrating the Domain".

Mandatory

Task 9 - Set Up the patchMaster.properties File and Run Patch Assistant for Oracle Instance

Specify the instance-related properties in the patchMaster.properties file, and run the ant master-patch-oinstance command to migrate the instances.

For more information, see Section 3.5.2.7, "Migrating an Instance".

Optional

Task 10 - Run Patch Assistant for Registering Instance

After migrating the instances, run the ant master-register-oinstance command to register the instances.

For more information, see Section 3.5.2.8, "Registering the Instance".

Mandatory

Task 11 - Start 11.1.1.2.0 Domains and Instances

Run the ant master-start-domain-new command to start the new 11.1.1.2.0 domain. In addition, start the new instances.

For more information, see Section 3.5.2.9, "Starting or Stopping the 11.1.1.2.0 Domain".

Mandatory

Task 12 - Prepare Environment with Product-Specific Post-Migration Requirements

Perform any product-specific post-migration tasks.

For more information, see Section 3.5.3, "Post-Migration Configuration for Oracle Fusion Middleware Components".

Mandatory if your Oracle product requires any post-migration configuration.

Task 13 - Decommission 11.1.1.1.0 Installation

Deinstall the 11.1.1.1.0 installation.

For more information, see Section 3.5.2.11, "Decommissioning the 11.1.1.1.0 Installation".

Optional

3.5.2 Migration Procedure

Migrating your existing configuration from 11.1.1.1.0 to 11.1.1.2.0 involves the following tasks:

1. Stopping the Old Domain

2. Installing Oracle Software for 11.1.1.2.0

3. Downloading Patch Assistant

4. Migrating the Schema

5. Creating a WebLogic Domain for 11.1.1.2.0

6. Migrating the Domain

7. Migrating an Instance

8. Registering the Instance

9. Starting or Stopping the 11.1.1.2.0 Domain

10. Completing Post-Migration Tasks

11. Decommissioning the 11.1.1.1.0 Installation

3.5.2.1 Stopping the Old Domain

To stop the old 11.1.1.1.0 domain, complete the following steps:

Note:
You can also use Fusion Middleware Control, Oracle WebLogic Server Administration Console, or WLST or OPMN commands to stop the Oracle Fusion Middleware components.

1. Open the patchMaster.properties file (Located in your patchMaster directory) in a text editor, and specify the following properties in the patchMaster.properties file, as applicable:

patchMaster.Oraclehomeold
patchMaster.Oracleinstanceoldlist
patchMaster.Domainadminhost
patchMaster.Domainadminport

If the patchMaster.Domainadminhost property is not specified, the default value local host is used. If the patchMaster.Domainadminport property is not specified, the default value 7001 is used. After editing the properties, save the file and close. For more information about properties in the patchMaster.properties file, see Section 3.5.6, "Properties in the patchMaster.properties File".

Note:
If you have multiple Oracle products installed, then you must run Patch Assistant once for each product and setting the patchMaster.Oraclehomeold for each product.

2. Run the following command on the command line:

ant master-stop-domain-old

3. Enter the domain user name and password, when prompted.

3.5.2.2 Installing Oracle Software for 11.1.1.2.0

You must install Oracle WebLogic Server, Repository Creation Utility (RCU), and Oracle products for 11.1.1.2.0:

- Create a new Middleware home directory.

- Install Repository Creation Utility.

- Perform a software-only installation of the product bundle.

Ensure that your system environment meets the general installation requirements for Oracle Fusion Middleware. Some Oracle Fusion Middleware Components require schemas that must be installed in an Oracle database. It is recommended that you do not install any new schemas for your existing 11g R1 (11.1.1.1.0) products. However, in the same environment, you can add new products for which you may have to create the appropriate schemas. For such products, you can create and load the schemas in your database by using RCU. Ensure that you have a supported Oracle database up and running. See http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html for more information.

Ensure that same instance name used in 11.1.1.1.0 and 11.1.1.2.0.

Note:
When you migrate the mid-tier, you are installing a fresh mid-tier in your new 11.1.1.2.0 environment. Patch Assistant migrates the middle tier configuration to this new instance.

For information about the installation process, including Cluster scenarios, see Section 3.5.4, "Installation Process".

3.5.2.3 Downloading Patch Assistant

For information about downloading Patch Assistant and extracting its contents, see Section 3.4.2.2, "Extracting the Contents of Patch Assistant".

3.5.2.4 Migrating the Schema

Before you can update the repository, ensure that your 11.1.1.1.0 domain is configured and it includes tables populated from running the Repository Creation Utility (RCU).

Note:
You can choose to install Oracle Content Server while installing Oracle WebCenter, or later by performing a standalone installation. In Oracle Fusion Middleware 11.1.1.1.0, if you performed a standalone installation of Oracle Content Server, then before you migrate the schemas, you must rename the Oracle Content Server's schema so that it contains the standard suffix, OCSERVER. For information, see Section 3.5.2.4.1, "Renaming the Oracle Content Server Schema"

To migrate the schema, complete the following steps:

1. Open the patchMaster.properties file (Located in your patchMaster directory) in a text editor, and specify the following schema-related properties in the patchMaster.properties file:

patchMaster.Schemaurl
patchMaster.Schemauser
patchMaster.Schemaprefix
patchMaster.Mwhomenew
patchMaster.Mwhomeold
patchMaster.Componentlist

Note:
The patchMaster.Componentlist property is optional, if you are migrating the schema for a single component. For Oracle Portal, in addition to the above properties, you must specify the patchMaster.Oraclehomenew property.
In patchMaster.Componentlist, include Oracle Content Server as a component only if you created the server's schema using RCU. If you did not create the schema using RCU, then list the server in patchMaster.Componentlist only after completing the schema renaming process described in section Section 3.5.2.4.1, "Renaming the Oracle Content Server Schema"

After editing the properties, save the file and close. For more information about properties in the patchMaster.properties file, see Section 3.5.6, "Properties in the patchMaster.properties File".

2. Run the following command on the command line to migrate the database schema, and provide the required user name and password when prompted:

ant master-patch-schema

Patch Assistant can only migrate one set of component schemas that share the same prefix. If different components in your deployment have different prefixes and you have multiple schemas sharing a repository, then you must invoke Patch Assistant multiple times, once for each prefix.

Note:
If you migrate the Metadata Services schema for one component, it also affects all the other components using the same Metadata Services schema. If you are using Oracle SOA, you must enter ant -q master-patch-schema on the command line to migrate the schema.

Refer to your product-specific upgrade guides, in the Oracle Fusion Middleware Online Documentation Library, for more information about upgrading schema for your Oracle Fusion Middleware.

During the schema migration, exceptions may occur. Some of these exceptions can be ignored. The following example shows one such exception:

[java] SEVERE: Error while registering Oracle JDBC Diagnosability MBean.
[java] java.security.AccessControlException: access denied (javax.management.MBeanTrustPermission register)
[java]     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)

Note:
Patch Assistant ensures that all required properties are set for each of the operations.
Patch Assistant attempts to migrate all Oracle Fusion Middleware components. If a component is not installed or configured in the deployment, log messages indicating these attempts are generated.

Log files specific to Oracle Portal migration are generated in the upgrade.log and precheck.log files in the ORACLE_HOME/upgrade/logs directory (UNIX).

3.5.2.4.1 Renaming the Oracle Content Server Schema

In Oracle Fusion Middleware 11.1.1.1.0, if you performed a standalone installation Oracle Content Server, then before migrating the schemas, you must rename the Oracle Content Server's schema so that it contains the standard suffix, OCSERVER. You must also rebuild indexes on Oracle Content Server.

To rename the Oracle Content Server schema:

1. Create a new schema (for example, DEV_OCSERVER) using the RCU. Ensure that you use the same password as that of your existing Oracle Content Server schema.

2. Export the existing schema (for example, IDC_IR10).

3. Import data into the new schema you created (DEV_OCSERVER).

Note:
Before you import data into the newly created schema, ensure that all the seeded database objects are removed from that schema.

4. Open the config/config.cfg file from the installation directory of your Oracle Content Server.

5. Change the Oracle Content Server schema name listed in the configuration file to the newly created schema. (for example, rename IDC_IR10 to DEV_OCSERVER)

6. Access the Oracle Content Server administration console and ensure that the data exists.

After renaming the Oracle Content Server schema, you must migrate the schema, as described in the beginning of this section.

After migrating the schemas, you must rebuild the indexes on Oracle Content Server.

To re-create the index:

1. Log on to Oracle Content Server as a system administrator.

2. Access Repository Manager from the Admin Console by navigating to Administration > Admin Applets > Repository Manager.

3. Click the Indexer tab.

4. In the Collection Builder Cycle section, click Start. If the collection rebuild is already in progress, do not choose to restart the operation. First stop the collection rebuild operation, and then start the operation. Note that the collection rebuild operation is a time-consuming task.

3.5.2.5 Creating a WebLogic Domain for 11.1.1.2.0

Create a WebLogic domain for 11.1.1.2.0 as follows:

1. Run the MW_Home/oracle_common/common/bin/config.sh command (on UNIX) or the MW_Home\oracle_common\common\bin\config.cmd command (on Windows) on the command line. The Oracle Fusion Middleware Configuration Wizard appears.
For Oracle Portal, Oracle Forms, Oracle Reports, and Oracle Discoverer the config.sh command is located at ORACLE_HOME/bin (on UNIX) and the config.cmd is located at ORACLE_HOME\bin (on Windows).

2. On the Welcome screen, select the Create a new WebLogic domain option. Click Next. The Select Domain Source screen appears.

3. On the Select Domain Source screen ensure that the Generate a domain configured automatically to support the following products: option is selected. Select templates for the products that are included in your existing 11.1.1.1.0 installation. For example, if the domain in your 11.1.1.1.0 installation had SOA configured, you must configure the new domain with SOA in 11.1.1.2.0. Click Next. The Select Domain Name and Location screen appears.

4. Enter a name and a location for the domain to be created, and click Next. Ensure that the domain name is same as the 11.1.1.1.0 domain. Click Next. The Configure Administrator User Name and Password screen appears.

5. Configure a user name and a password for the administrator. The default user name is weblogic. Click Next.

6. Choose a JDK in the Configure Server Start Mode and JDK screen.

7. Configure JDBC Component Schemas and ensure that you retain the same 11.1.1.1.0 topology during this configuration.

8. On the Select Optional Configuration screen, select the Administration Server and Managed Servers, Clusters, and Machines, and Deployments and Services check boxes. Click Next.

9. Configure the Administration Server, Managed Servers, Clusters, Machines, as required. Ensure that you retain the same 11.1.1.1.0 topology during this configuration.

10. On the Configuration Summary screen, review the domain configuration, and click Create to start creating the domain.

The WebLogic domain with your configuration attributes is created.

Note:
Patch Assistant ensures that all required properties are set for each of the operations.
Patch Assistant attempts to migrate all Oracle Fusion Middleware components. If a component is not installed or configured in the deployment, log messages indicating these attempts are generated.

For more information about the configuration process, including Cluster scenarios, see Section 3.5.5, "Configuration Process".

3.5.2.6 Migrating the Domain

Before you can migrate the WebLogic domain, ensure that the database schemas are migrated, the new 11.1.1.2.0 products are installed, the new 11.1.1.2.0 domain is configured (as it was configured in the previous 11.1.1.1.0 installation), and all the WebLogic domains are shut down. When you migrate the 11.1.1.1.0 domain, the products configured in the domain are also migrated to the new 11.1.1.2.0 domain.

Note:
If you have multiple Oracle products installed, then you must run Patch Assistant once for each product and setting the patchMaster.Oraclehomeold property for each product. You must patch all products in the domain being migrated.

To migrate the WebLogic domain, complete the following steps:

1. Open the patchMaster.properties file (Located in your patchMaster directory) in a text editor, and specify the following domain-related properties:

patchMaster.Domainhomenew
patchMaster.Domainapplicationshomenew
patchMaster.Domainhomeold
patchMaster.Domainusername
patchMaster.Oracleinstanceoldlist
patchMaster.Oraclehomeold

After editing the properties, save the file and close. For more information about properties in the patchMaster.properties file, see Section 3.5.6, "Properties in the patchMaster.properties File".

2. Run the following command on the command line to migrate the WebLogic domain:

ant master-patch-domain

Note:
Patch Assistant ensures that all required properties are set for each of the operations.
Patch Assistant attempts to migrate all Oracle Fusion Middleware components. If a component is not installed or configured in the deployment, log messages indicating these attempts are generated.

For the Oracle Directory Integration Platform, you only need to enter the above target to complete the migration process. If you are using Oracle SOA, you must enter ant -q master-patch-domain on the command line to migrate the WebLogic domain.

If you are using a Cluster environment, ensure that the database schemas are migrated, the new 11.1.1.2.0 products are installed in a Cluster environment, the new 11.1.1.2.0 domain is configured (as it was configured in the previous 11.1.1.1.0 installation) in a Cluster environment, and all the WebLogic domains are shut down.

3.5.2.7 Migrating an Instance

Before you can migrate the Oracle Instances, ensure that the database schemas are migrated, the new 11.1.1.2.0 products are installed, the new 11.1.1.2.0 domain is configured (as it was configured in the previous 11.1.1.1.0 installation), the domain is migrated, and the Oracle Instances are shut down.

Note:
For Oracle Business Intelligence Discoverer in a High Availability (clustered) environment with multiple Managed Servers, you can override the default value WLS_DISCO by specifying the following java properties on the command-line:

- srcDiscoMgdServer

- destDiscoMgdServer

For example:

ant -DsrcDiscoMgdServer=WLS_DISCO1 -DdestDiscoMgdServer=WLS_DISCO1 master-patch-oinstance

To migrate an instance, complete the following steps:

1. Open the patchMaster.properties file (Located in your patchMaster directory) in a text editor, and specify the following properties related to your Oracle Instance homes:

patchMaster.Oracleinstanceoldlist
patchMaster.Oracleinstancenewlist

After editing the properties, save the file and close. For more information about properties in the patchMaster.properties file, see Section 3.5.6, "Properties in the patchMaster.properties File".

2. Run the following command on the command line to migrate the Oracle Instances:

ant master-patch-oinstance

Note:
Patch Assistant ensures that all required properties are set for each of the operations.
Patch Assistant attempts to migrate all Oracle Fusion Middleware components. If a component is not installed or configured in the deployment, log messages indicating these attempts are generated.

3.5.2.8 Registering the Instance

After migrating an instance, you must register the instance by completing the following steps:

Note:
Before registering the instance, ensure that your Administration Server is up and running.

1. Open the patchMaster.properties file (Located in your patchMaster directory) in a text editor, and specify the following properties in the patchMaster.properties file, as applicable:

patchMaster.Oracleinstancenewlist

After editing the properties, save the file and close. For more information about properties in the patchMaster.properties file, see Section 3.5.6, "Properties in the patchMaster.properties File".

2. Run the following command on the command line:

ant master-register-oinstance

3. Enter the domain user name and password, when prompted.

Note:
Patch Assistant ensures that all required properties are set for each of the operations.
Patch Assistant attempts to migrate all Oracle Fusion Middleware components. If a component is not installed or configured in the deployment, log messages indicating these attempts are generated.

3.5.2.9 Starting or Stopping the 11.1.1.2.0 Domain

Starting or stopping the new 11.1.1.2.0 domain requires the patchMaster.Domainhomenew property to be specified in the patchMaster.properties file.

To start the new 11.1.1.2.0 domain, run the following command on the command line:

ant master-start-domain-new

To stop the new 11.1.1.2.0 domain, run the following command on the command line:

ant master-stop-domain-new

3.5.2.10 Completing Post-Migration Tasks

For information about post-migration tasks specific to your product, see Section 3.5.3, "Post-Migration Configuration for Oracle Fusion Middleware Components".

Note:
When the Oracle Portal, Forms, Reports, and Discoverer installation is performed on a Windows machine, the System PATH is updated so that the ORACLE_HOME\bin for that installation precedes PATH. You cannot run Oracle Forms from the first installation, by default. To access the 11.1.1.1.0 components, right-click on My Computer and then Properties, select the Advanced tab, and click the Environment Variables button. Edit the System variable PATH so that the ORACLE_HOME\bin that you want to use is the one that precedes PATH.

3.5.2.11 Decommissioning the 11.1.1.1.0 Installation

After migrating to 11.1.1.2.0, you can deinstall Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0). For more information, refer to the following:

- "Deinstalling Oracle Identity Management 11g Release 1 (11.1.1)" chapter in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

- "Deinstalling Oracle Portal, Forms, Reports and Discoverer" chapter in the Oracle Fusion Middleware Installation Guide for Oracle Portal, Forms, Reports and Discoverer.

- “Deinstalling Oracle SOA Suite” chapter in the Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.

- “Deinstalling Oracle WebCenter” chapter in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

- "Deinstalling Oracle Web Tier" chapter in the Oracle Fusion Middleware Installation Guide for Oracle Web Tier.

Note:
When you deinstall 11.1.1.1.0, the Installer removes the previously created 11.1.1.2.0 windows service. Use the Ant command-line utility to re-create that service for each instance as follows:

ant master-opmn-create-service

Enter the required information when prompted by the Ant task.

3.5.3 Post-Migration Configuration for Oracle Fusion Middleware Components

After running the Patch Assistant, you must manually configure some of the Oracle Fusion Middleware Components:

- Post-Migration Configuration for Oracle Fusion Middleware Audit Framework

- Post-Migration Configuration for Oracle Business Intelligence Discoverer

- Post-Migration Configuration for Oracle Directory Integration Platform

- Post-Migration Configuration for Oracle Identity Federation

- Post-Migration Configuration for Oracle Platform Security Services

- Post-Migration Configuration for Oracle Reports

- Post-Migration Configuration for Oracle SOA

- Post-Migration Configuration for Oracle User Messaging Service

- Post-Migration Configuration for Oracle WebCenter

- Post Migration Configuration for Oracle Web Services Manager

3.5.3.1 Post-Migration Configuration for Oracle Fusion Middleware Audit Framework

After running Patch Assistant for Oracle Fusion Middleware Audit Framework, you must complete the following tasks:

- Update the Translation Table in Audit Schema

- Migrating Audit Policy Configuration for Java Components

- Creating the Audit Data Source

3.5.3.1.1 Update the Translation Table in Audit Schema

If the IAU_DISP_NAMES_TL audit event translation data is defined in the 11.1.1.1.0, then you can migrate them to the 11.1.1.2.0, by completing the following steps:

1. Run SQLPlus, and connect to the database as the system user. For example:

sqlplus sys as sysdba

2. Run SQL commands in the following order:

SQL> alter session set current_schema=<Name_of_Your_Audit_Schema>;
SQL> delete from iau_disp_names_tl;
SQL> @disp_names.sql;

disp_names.sql is located at fmw11gR1ps1_patchassist\Audit folder.

Note:
To avoid scrambled characters, a Unicode-supported database is required to store the translation data. In addition, to ensure proper character set conversion between SQL*Plus and the database server, a compatible character set, such as UTF8 or AL32UTF8, needs to be set for the NLS_LANG environment variable before running disp_names.sql.
For the complete list of legal NLS_LANG values, see the Oracle Database Documentation Library at:

http://www.oracle.com/technology/documentation/database.html

3.5.3.1.2 Migrating Audit Policy Configuration for Java Components

If the audit policy is configured for Java components in 11.1.1.1.0, you must import the configuration file after running Patch Assistant, as follows:

1. Log in to the Oracle Enterprise Manager 11g Fusion Middleware Control.

2. Expand the WebLogic Domain on the left pane, and select your domain.
Your selected domain page is displayed.

3. From the WebLogic Domain, select Security, and then Audit Policy.
The Audit Policy page is displayed.

4. Select the Audit Policy, and click Import.

5. Click Browse, and specify the path where your AuditConfiguration file is located.

6. Click Ok.

3.5.3.1.3 Creating the Audit Data Source

If the audit data source is used in Oracle Fusion Middleware 11.1.1.1.0, then you must re-create the audit data store used in 11.1.1.2.0. To do so, perform the following steps:

1. Log in to the Oracle WebLogic Server administration console:

http://host:7001/console

2. Under JDBC, click the Data Sources link.
The Summary of JDBC Data Sources page is displayed.

3. Click New to create a new data source.
The Create a New JDBC Data Source page is displayed.

4. Enter the following details for the new data source:

- Name: Enter a name such as Audit Data Source-0

- JNDI Name: jdbc/AuditDB

- Database Type: Oracle

- Database Driver: Oracle's Driver (Thin XA) Versions: 9.0.1, 9.0.2, 10, 11

If deploying to a managed cluster server, check AdminServer. This selection ensures that the data source is listed in the audit store when switching from file to database store.

5. Click Next.
The Transaction Options page is displayed.

6. Click Next.
The Connection Properties page is displayed.

7. In the Connection Properties page, enter the following information:

- Database Name: Enter the name of the database to which you will connect. This usually maps to the SID.

- Host Name: Enter the hostname of the database.

- Port: Enter the database port.

- Database User Name: This is the name of the audit schema that you created in RCU. The suffix is always IAU for the audit schema. For example, if you gave the prefix as test, then the schema name is test_iau.

- Password: This is the password for the audit schema that you created in RCU.

Click Next.

8. The next page lists the JDBC driver class and database details. Accept the default values, and click Test Configuration to test the connection. If you see the message "Connection established Successfully", click Next. If it displays any error, go back and check the connection details.

9. In the Select Targets page, select the servers where this data source must be configured, and click Finish.

3.5.3.2 Post-Migration Configuration for Oracle Business Intelligence Discoverer

After running Patch Assistant, ensure that all your existing Oracle BI Discoverer Plus OLAP users have proper access privileges to the Oracle BI Discoverer 11g Release 1 (11.1.1.2.0) Discoverer Catalog. To set proper access privileges, perform the following tasks using the command-line utilities:

- Authorizing a New User to Access the Discoverer Catalog

- Updating the Privileges of an Existing Discoverer Catalog User

3.5.3.2.1 Authorizing a New User to Access the Discoverer Catalog

Use the following commands to authorize one or more users so they can access the Discoverer Catalog:

java -classpath path_to_d4o_jar_file load . java -classpath path_to_d4o_jar_file authorize -h hostname -po portname
-sid database_SID -p d4osyspasswd -u user

For example. on Windows:

java -classpath C:\temp\d4o.jar load . java -classpath C:\temp\d4o.jar authorize -h sys42.example.com -po 1521
-sid disco_db1 -p nPword432 -u jones

For example, on UNIX:

java -classpath /home/abc/temp/d4o.jar load . java -classpath /home/abc/temp/d4o.jar authorize -h sys42.example.com -po 1521
-sid disco_db1 -p nPword432 -u jones

In this example, you must run the load command only once before authorizing any number of users. For example, if you want to authorize 10 users, run the load command once, and then run the authorize command once for each user.

3.5.3.2.2 Updating the Privileges of an Existing Discoverer Catalog User

To update the user's privileges to access all private and shared folders, use the following command:

java -classpath path_to_d4o_jar_file updatePrivileges -h hostname -po portname
-sid database_SID -p d4osyspasswd -u user

For example, on Windows:

java -classpath C:\temp\d4o.jar updatePrivileges -h sys42.example.com -po 1521
-sid disco_db1 -p nPword432 -u jones

For example, on UNIX:

java -classpath /home/abc/d4o.jar updatePrivileges -h sys42.example.com -po 1521
-sid disco_db1 -p nPword432 -u jones

In this example, if you specify the -u option, then the privileges are upgraded only for that user. If you do not specify the -u option, then the privileges are upgraded for all users.

3.5.3.3 Post-Migration Configuration for Oracle Directory Integration Platform

After running Patch Assistant, start your Oracle Directory Integration Platform 11g Release 1 (11.1.1.2.0) domain. For more information, see the Starting and Stopping Oracle Fusion Middleware chapter in the Oracle Fusion Middleware Administrator's Guide and, then complete the following steps:

1. Log in to Oracle Enterprise Manager Fusion Middleware Control.

2. In the Oracle Enterprise Manager home page, select Farm, and then Agent-Monitored Targets.
The Agent-Monitored Targets page is displayed.

3. From the Targets table, select the target used by the Oracle Directory Integration Platform, and click Configure.
The Configure Target page is displayed.

4. Click Change Agent and, then select the Oracle Internet Directory Agent URL from the drop-down box.

5. Click Ok.

6. Click Apply.

7. Log out of Oracle Enterprise Manager.

8. Log in to Oracle Enterprise Manager again.

9. Unregister the ASInstance created during Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) Directory Integration Platform configuration by running the following command:
Windows:

ORACLE_INSTANCE\bin\opmnctl unregisterinstance -adminHost -adminPort -adminUserName

UNIX:

$ORACLE_IMSTANCE/bin/opmnctl unregisterinstance -adminHost -adminPort -adminUserName

10. Delete the ASInstance created during Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) Directory Integration Platform Configuration by running the following command:
Windows:

ORACLE_HOME\opmn\bin\opmnctl deleteinstance -oracleInstance <Oracle instance root directory>

UNIX:

$ORACLE_HOME/opmn/bin/opmnctl deleteinstance -oracleInstance <Oracle instance root directory>

3.5.3.4 Post-Migration Configuration for Oracle Identity Federation

After running Patch Assistant, your Credential Store Framework (CSF) is not migrated to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0), if you are using an LDAP store. You must migrate the credentials manually from a source repository to a target repository by using the WLST command migrateSecurityStore. For information, see the "Migrating Credentials with the Command migrateSecurityStore" section in the Oracle Fusion Middleware Security Guide.

3.5.3.5 Post-Migration Configuration for Oracle Platform Security Services

You must manually migrate your existing Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) policy store because the corresponding schema changes when you install Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0). During this migration, any existing 11.1.1.1.0 installation policies are updated to 11.1.1.2.0 policies. You will find the existing 11.1.1.1.0 data provisioned in the 11.1.1.2.0 LDAP store.

However, you must redeploy your applications after installing Oracle Fusion Middleware (11.1.1.2.0), but the provisioned policies are already in the migrated LDAP store.

Note:
When redeploying your applications, you should not migrate the policies as they already exist in the policy store.

Note that Oracle WebLogic Server domains are containers of application policy data that is used by Oracle Platform Security Services. Typically, a domain is identified by its name, as in the following example:

Relative DN(RDN)cn=MyDomain,cn=JpsContext,cn=JpsTestNode

The Relative DN (RDN) cn=MyDomain is the node on the LDAP server that corresponds to a domain. All data under such a domain, including Credential Store and Policy Store data, is preserved.

Note:
If you are using Oracle WebLogic Server LDAP, then you must re-create the user. For more information, see "Security Data Migration" section in the Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.

Migration Scenarios

If you are migrating Oracle Platform Security Services 11.1.1.1.0 Policy Store to 1.1.1.2.0 Policy Store, consider the following migration scenarios:

- Migrating File-Based Policy and Credential Store

- Migrating Oracle Internet Directory Policy and Credential Store and Reusing an Existing Oracle Internet Directory Server

3.5.3.5.1 Migrating File-Based Policy and Credential Store

To migrate your existing file-based policy and credential store from 11.1.1.1.0 to 11.1.1.2.0, you must install Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0), which is configured to use the file-based policy (XML), credential (wallet) stores, and then migrate the credentials and application policies by using the WebLogic Scripting Tool (WLST) command migrateSecurityStore. For more information, see the "Migrating Credentials with the Command migrateSecurityStore" section in the Oracle Fusion Middleware Security Guide.

3.5.3.5.2 Migrating Oracle Internet Directory Policy and Credential Store and Reusing an Existing Oracle Internet Directory Server

To migrate your existing Oracle Internet Directory policy and credential store from Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0), start the servers in your Oracle Fusion Middleware domain and then complete the following steps:

Note:
Ensure that your Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) installation has applications deployed on a single domain and configured with LDAP or credential store. In addition, make sure that you do not have any resource catalog information provisioned.

1. Reconfigure the LDAP authenticator to use the same LDAP server used in the 11.1.1.1.0 installation. For information, see the Oracle Fusion Middleware Security Guide.

Note:
For information on reconfiguring the LDAP authenticator to use the same LDAP server used in Oracle WebCenter 11.1.1.1.0 installation, see the "Reassociating the Identity Store with an External LDAP" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

2. Update the Java Platform Security (JPS) LDAP schema in the LDAP store by using the WLST reassociateSecurityStore command. The reassociation creates a temporary node under a pre-existing jps root node. The temporary data is the domain, you specified during reassociation. The domain needs to be a new temporary name and the jpsroot should have the same name that contains the domain you are migrating from 11.1.1.1.0. For information, see the "reassociateSecurityStore" section in the Oracle Fusion Middleware Security Guide. This command creates a temporary domain that will be deleted later. For example:

reassociateSecurityStore(domain="ps1_tmp_domain",admin="cn=orcladmin", password="welcome1", ldapurl="ldap://example.com:3060", servertype="OID", jpsroot="cn=jpsroot_r1_name")

Note:
Set a temporary name for the domain, and ensure that the jpsroot has the same name as in 11.1.1.1.0.

3. Ensure that the Oracle WebLogic Administration Server is stopped to change the server configuration. To stop the server, run the following command:
Windows:

MW_HOME\user_projects\domains\<domain_name>\bin\stopWebLogic.cmd
username password admin_url

UNIX:

$ MW_HOME/user_projects/domains/<domain_name>/bin/stopWeblogic.sh
username password admin_url

4. Rebuild the Oracle Internet Directory catalog by running the following catalog commands from the Oracle Internet Directory machine:

Note:
Before you start using the Oracle Identity Management command-line tools, you must configure your environment. This involves setting the appropriate environment variables as follows:

- ORACLE_HOME - The location of non-writable files in your LDAP-based identity store installation.

- ORACLE_INSTANCE - The location of writable files in your LDAP-based identity store installation.

- TNS_ADMIN - The location of tnsnames.ora file in your Oracle home.
Ensure that the tnsnames.ora file (Located at ORACLE_HOME/network/admin) contains the conn_str that will be used in the catalog command.

- PATH - Add the following directory locations to your PATH:

ORACLE_HOME/bin
ORACLE_HOME/ldap/bin
ORACLE_HOME/ldap/admin

Drop the catalog first before re-creating it as follows:

catalog connect="conn_str" delete=true attribute= createtimestamp
catalog connect="conn_str" delete=true attribute= modifytimestamp
catalog connect="conn_str" delete=true attribute= orclJpsResourceName
catalog connect="conn_str" delete=true attribute= orclJPSObjGUID
catalog connect="conn_str" delete=true attribute= orclJpsResourceTypeActionNames

Then add the following:

catalog connect="conn_str" add=true attribute= createtimestamp
catalog connect="conn_str" add=true attribute= modifytimestamp
catalog connect="conn_str" add=true attribute= orclJpsResourceName
catalog connect="conn_str" add=true attribute= orclJPSObjGUID
catalog connect="conn_str" add=true attribute= orclJpsResourceTypeActionNames

For more information, see "Performing Bulk Operations" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

5. Delete the temporary domain, created in step 1, by performing the following:

1. Disable the Server Entry Cache. For more information, see "Tuning Recommendations for Server Entry Cache" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

2. Stop Oracle Internet Directory by running the following command:
Windows

ORACLE_INSTANCE\bin\opmnctl stopall

UNIX

ORACLE_INSTANCE/bin/opmnctl stopall

3. Run the following command:

bulkdelete connect=”connect string” basedn=”cn=ps1_tmp_domain,cn=JPSContext,cn=jpsroot_r1_name”

Note:
Do not use JXplorer or any other LDAP browser to delete the JPS root node.

For more information, see "Deleting Entries or Attributes of Entries by Using bulkdelete" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

4. Start Oracle Internet Directory by running the following command:
Windows

ORACLE_INSTANCE\bin\opmnctl startall

UNIX

ORACLE_INSTANCE/bin/opmnctl startall

5. Enable the Server Entry Cache. For more information, see the "Tuning Recommendations for Server Entry Cache" section and the "Attributes of the Instance-Specific Configuration Entry" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

6. Stop and start Oracle Internet Directory by running the following commands:
Windows

ORACLE_INSTANCE\bin\opmnctl stopall ORACLE_INSTANCE\bin\opmnctl startall

UNIX

ORACLE_INSTANCE/bin/opmnctl stopall ORACLE_INSTANCE/bin/opmnctl startall

6. Open the jps-config.xml file (located in your MW_HOME\user_projects\domains\<DomainName>\config\fmwconfig directory) in a text editor and replace the 11.1.1.2.0 domain name with 11.1.1.1.0 domain name. For example, replace cn=ps1_tmp_domain with cn=R1_domain_name.

7. Migrate the default system policies from the XML store to the LDAP store by using the WLST Command migrateSecurityStore. For more information, see the "Migrating Credentials with the Command migrateSecurityStore" section in the Oracle Fusion Middleware Security Guide. In the jps-config.xml file, add the entries to specify the source and the destination source JPS context. The source JPS context must be the one that uses the XML store as the policy store, and the destination JPS context must be the one that uses the LDAP store. For example, add the following entries in the jps-config.xml file:

<jpsContext name="filestore">
<serviceInstanceRef ref="policystore.xml"/>
</jpsContext>
<jpsContext name="ldapstore">
<serviceInstanceRef ref="policystore.ldap"/>
</jpsContext>

Ensure that the policystore.xml service instance in jps-config.xml file refers to the shipped system-jazn-data.xml file (out-of-the-box), as in the following example:

<serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml">
<description>File Based Policy Store Service Instance</description>
</serviceInstance>

Migrate the system policies by using the WLST migrateSecurityStore command, as shown in the following example:

migrateSecurityStore(type="globalPolicies", configFile="<domain level jpsconfig.xml file loc>", src="filestore" ,dst="ldapstore")

For more information about the migrating system policies, see the "Migrating Policies to the Domain Policy Store" section in the Oracle Fusion Middleware Security Guide.

8. Ensure that the LDAP server contains the Role Categories entry under your application policy node.

1. Run the ldapsearch command to search for this Role Categories entry from the Oracle Internet Directory machine:

LDAP_OH/bin/ldapsearch -h <host> -p <port> -D "<Admin DN>" -w password -b "cn=Role Categories,cn=<app name>,cn=<domain name>,cn=JpsContext,cn=<jpsroot name>" -s base "(objectclass=*)"

Where LDAP_OH/bin is the OID/IdM IDM_ORACLE_HOME/bin directory.

Example:

LDAP_OH/bin/ldapsearch -h oid.example.com -p 3060 -D "cn=orcladmin" -w password -b "cn=Role Categories,cn=appname,cn=domainname,cn=JpsContext,cn=jpsroot" -s base "(objectclass=*)"

For detailed syntax, see the "ldapsearch" topic in the Oracle Fusion Middleware User Reference for Oracle Identity Management.

Note:
If the Role Categories entry is not available, the following message is displayed:

ldap_search: No such object

2. If the Role Categories entry is not present, create an LDIF file named rolecat.ldif with the following content:

dn: cn=Role Categories,cn=<app name>,cn=<domain name>,cn=JPSContext,cn=<jpsroot name>
objectclass: top
objectclass: orclContainer
cn: Role Categories

Example:

dn: cn=Role Categories,cn=webcenter,cn= R1_domain_name,cn=JPSContext,cn=jpsroot_r1_name
objectclass: top
objectclass: orclContainer
cn: Role Categories

3. Run the ldapadd command to add this node to the application policy store as follows:

LDAP_OH/bin/ldapadd -p <port> -h <host> -D "<Admin DN>" -w <password> -vf rolecat.ldif

Where LDAP_OH/bin is the OID/IdM IDM_ORACLE_HOME/bin directory.

Example:

LDAP_OH/bin/ldapadd -p 3060 -h oid.example.com -D "cn=orcladmin" -w password -vf rolecat.ldif

For detailed syntax, see the "ldapadd" topic in the Oracle Fusion Middleware User Reference for Oracle Identity Management.

Note:
If the node exists, the output of the ldapadd command indicates that the object already exists.

Note:
The ldapadd command for Role Categories must be run for every application that uses LDAP as policy store.

9. Start the Oracle WebLogic Administration Server, as shown in the following example:

MW_HOME/user_projects/domains/domain_name/bin/startWebLogic.sh
-Dweblogic.management.username=weblogic
-Dweblogic.management.password=password

For more information, see "Starting and Stopping Oracle Fusion Middleware" in Oracle Fusion Middleware Administrator's Guide.

10. Redeploy any user applications that were deployed in 11.1.1.1.0.

3.5.3.6 Post-Migration Configuration for Oracle Reports

After running Patch Assistant, your Oracle Internet Directory Policy and Credential Store (CSF) is not migrated to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0). For information about migrating the Oracle Internet Directory Policy and Credential Store (CSF), see Section 3.5.3.5.2, "Migrating Oracle Internet Directory Policy and Credential Store and Reusing an Existing Oracle Internet Directory Server".

3.5.3.7 Post-Migration Configuration for Oracle SOA

After running Patch Assistant, you must perform the following:

Note:
Service Engine configuration has moved from file to the database in 11.1.1.2.0.

1. Re-deploy your J2EE applications, including TaskDetail Application used in Human Workflow Applications. For more information, see "Deploying SOA Composite Applications" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

2. Reconfigure any changes made to configuration files (For example: soa-infra-config) and component-level configuration files in 11.1.1.1.0 must be reconfigured for 11.1.1.2.0 using the Oracle Enterprise Manager Fusion Middleware Control.

3. Reconfigure the log level settings using the Oracle Enterprise Manager Fusion Middleware Control. For more information, see "Configuring Logging" section in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

4. Re-create the seeding of the Workflow users.

5. Reconfigure the Secure Sockets Layer (SSL) for the SOA composite application. For more information, see the "Securing SOA Composite Applications" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

6. If you have configured the Oracle HTTP Server for 11.1.1.1.0, then you must reconfigure it for 11.1.1.2.0.

7. For composites involving BPEL Sensors with sensor action as JMS Queue, JMS Topic, JMS Adapter (remote JMS), re-create the JMS Queue, JMS topic, and the remote JMS set up.

8. Configure the identity and policy provider, as described in Section 3.5.3.5.2, "Migrating Oracle Internet Directory Policy and Credential Store and Reusing an Existing Oracle Internet Directory Server".

9. Configure the SSO provider for 11.1.1.2.0.

10. Configure the adapters as follows:

- Create the data source for the AQ adapter by following the steps described in the "Configuring the Data Sources in the Oracle WebLogic Server Administration Console" section in the Oracle Fusion Middleware User's Guide for Technology Adapters.

- Configure AQ JMS in Oracle WebLogic Server Administration Console. For more information, see the Oracle Fusion Middleware User's Guide for Technology Adapters.

- Create the foreign server for the AQJMS again and restart the server.

- After migration, if the log was showing Queue Manager not available (with MQ reason code: 2059), you must modify the JNDI, which is used by the composite deployed to point to the Queue Manager, which was used for pre-upgrade. After making this change, you must restart SOA.

11. Migrate the B2B for 11.1.1.2.0 as follows:

1. Import previously exported repository from 11.1.1.1.0 with the Replace Existing MetaData flag.

2. Update the key store password and restart the B2B server.

3. Select the certificate alias in delivery channel and save.

4. Deploy the B2B agreements.

3.5.3.8 Post-Migration Configuration for Oracle User Messaging Service

After running Patch Assistant, you must perform the following:

- Migrating Configuration for Additional Custom-Deployed Drivers

- Migrating Configuration for User Messaging Service Worklist Driver

3.5.3.8.1 Migrating Configuration for Additional Custom-Deployed Drivers

If your Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) domain has configuration files for additional User Messaging Service driver deployments beyond those provisioned at install time, then you must migrate them to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0). Run the following Ant command on the command-line:

ant -f UMS/build.xml patch-ums-driver-config -Ddriver.name=<driver_name>

Where <driver_name> is the deployment name of the custom driver. The build.xml file is located in your patchMaster directory.

Note:
This command only migrates the configuration to Oracle Fusion Middleware (11.1.1.1.2.0) domain and will not deploy the driver.

3.5.3.8.2 Migrating Configuration for User Messaging Service Worklist Driver

If your Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) domain has the User Messaging Service Worklist Driver installed and configured, then the configuration of the Worklist Driver is automatically migrated by the Patch Assistant. Patch Assistant does not install this additional driver. You must re-install the driver in the Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) domain. For more information, see "Install the Worklist Driver" section in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

3.5.3.9 Post-Migration Configuration for Oracle WebCenter

This section describes the tasks involved in getting your Oracle WebCenter 11.1.1.2.0 up and running after you have migrated the mid-tier.

3.5.3.9.1 Overview of Tasks for Configuring Oracle WebCenter Post Mid-Tier Migration

Table 3-2 describes the tasks involved in configuring Oracle WebCenter 11.1.1.2.0 after the Patch Assistant script has been executed. The table also specifies whether these tasks are optional or mandatory.

Table 3-2 Post Mid-Tier Migration Tasks for Oracle WebCenter

Task

Description

Mandatory/Optional?

Reconfiguring Oracle WebCenter Identity Store and Migrating the Application Policy to the WebCenter Policy Store

Configure the identity store to use the same configuration as Oracle WebCenter 11.1.1.1.0. Also, run the updateSpacesPolicy.py script to update the application store to include appropriate security permissions for WebCenter Spaces.

Note: You must run updateSpacesPolicy.py even if your Oracle WebCenter uses the embedded LDAP identity store.

Mandatory

Configuring Oracle WebCenter for Secure Sockets Layer (SSL)

Configure Oracle WebCenter 11.1.1.2.0 to use the same SSL configuration and keystore as Oracle WebCenter 11.1.1.1.0.

Mandatory if SSL is configured in Oracle WebCenter 11.1.1.1.0

Configuring Oracle WebCenter for Single Sign-On (SSO)

Configure your single sign-on (SSO) solution to use the same SSO configuration as Oracle WebCenter 11.1.1.1.0.

Mandatory if SSO is configured in Oracle WebCenter 11.1.1.1.0

Refreshing Group Space Data in WebCenter Spaces

Refresh the group space data and the data about group space members.

Mandatory

Reapplying Configuration Changes

Reapply any configuration changes made to Oracle WebCenter 11.1.1.1.0.

Mandatory

Importing Wiki Templates and Attachments

Migrate templates and attachments to the database repository of Oracle WebCenter Wiki and Blog Server.

Mandatory if Oracle WebCenter Wiki and Blog Server is configured for Oracle WebCenter 11.1.1.1.0

Migrating Oracle Content Server

Run the WebCenter configuration script wc_contentserverconfig to migrate to Oracle Content Server 10.1.3.5.1. Also, configure a JPS user provider in place of the existing LDAP user provider.

Mandatory if Oracle Content Server is configured for Oracle WebCenter 11.1.1.1.0

Configuring Oracle WebCenter Discussions for WebCenter Spaces

Configure Web Services Security (WS-Security) if you want to use Oracle WebCenter Discussions with Oracle WebCenter Spaces.

Mandatory

Migrating Custom WebCenter Applications

Migrate custom WebCenter applications to Oracle WebCenter 11.1.1.2.0.

Mandatory

3.5.3.9.2 Reconfiguring Oracle WebCenter Identity Store and Migrating the Application Policy to the WebCenter Policy Store

You must migrate your existing identity store and credential store. Before doing so, be sure to start all the servers in your WebCenter domain.

If you are using the embedded LDAP based policy and credential store, for information about the tasks that you need to perform, see the "Exporting and Importing a File-based Policy Store" and "Exporting and Importing a File-based Credential Store" sections in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

When Oracle WebCenter 11.1.1.1.0 is configured to use an external LDAP-based identity store, then post mid-tier migration you must migrate your identity store and credential store to Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0). For information about how to migrate Oracle Internet Directory policy and credential store, see Section 3.5.3.5.2, "Migrating Oracle Internet Directory Policy and Credential Store and Reusing an Existing Oracle Internet Directory Server."

After migrating the identity and credential store, you must run the updateSpacesPolicy.py script to update the WebCenter Spaces application policy to include appropriate security permissions. If you do not run this script, WebCenter Spaces users will not be able to access their profile information or the service tabs in group spaces.

Note:
You must run the updateSpacesPolicy.py script even if your Oracle WebCenter uses the embedded LDAP identity store.

To execute updateSpacesPolicy.py:

1. Launch WLST with this command:

WC_ORACLE_HOME/common/bin/wlst.sh

Where WC_ORACLE_HOME refers to the Oracle WebCenter installation directory.

2. At the WLST command prompt, enter the following command to connect to the Administration Server:

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

For example, use the following command:

connect('weblogic','weblogic', 'myhost.example.com:7001')

3. Use the following command to run the updateSpacesPolicy.py script:

wls:/weblogic/serverConfig> execfile('WC_ORACLE_HOME/webcenter/scripts/updateSpacesPolicy.py')

4. Ensure that there are no errors logged on the console. If there are errors, use the error message as a guide and inspect the updateSpacesPolicy.py script to determine the grant command that failed. You must fix errors, if any, and run the grant command manually.

5. Restart the Administration Server and the WLS_Spaces Managed Server.

3.5.3.9.3 Configuring Oracle WebCenter for Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) provides additional security for connections between WebCenter applications or components by providing an additional authentication layer, and by encrypting the data exchanged. During mid-tier migration, the SSL configuration does not get migrated. After running the Patch Assistant script, you must reconfigure SSL for Oracle WebCenter and, if required, for various WebCenter Services integrated into your WebCenter applications. For information about how to configure SSL for WebCenter applications and WebCenter Services, see the "Configuring WebCenter Applications and Components to Use SSL" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

For example, in Oracle WebCenter 11.1.1.1.0, if secured portlets were used in WebCenter Spaces, then your keystore must have been set to the Custom Identity and Java Standard Trust keystore and you would have imported the required portlet certificates in the Java standard trust keystore (typically cacerts). Now, post mid-tier migration, you must configure the WLS_Spaces server, in your Oracle WebCenter 11.1.1.2.0 instance, to use the Custom Identity and Java Standard Trust keystore and other SSL-specific settings that were configured for Oracle WebCenter 11.1.1.1.0. Also, you must reimport all your portlet certificates into the trust keystore to access secured portlets in Oracle WebCenter 11.1.1.2.0.

3.5.3.9.4 Configuring Oracle WebCenter for Single Sign-On (SSO)

For single sign-on (SSO) authentication, your Oracle WebCenter 11.1.1.1.0 may be configured to use Oracle Access Manager (OAM), Oracle Single Sign-on (OSSO), or a SAML-based single sign-on solution for WebCenter applications only. After mid-tier upgrade, you may need to perform the following configuration, depending on the SSO solution used:

- Configuring OAM: Configure the authenticator and the OAM asserter to use the same configuration as used in Oracle WebCenter 11.1.1.1.0. For information, see the "Configuring Oracle Access Manager (OAM)" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

- Configuring OSSO: Configure the authenticator and the OSSO asserter to use the same configuration as used in Oracle WebCenter 11.1.1.1.0. For information, see the "Configuring Oracle Single Sign-On (OSSO)" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

- Configuring SAML-based SSO: You must set up your entire SAML-based SSO solution. For information, see the "Configuring SAML-based Single Sign-on" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

Note:
If WebCenter is running with SSO, the OmniPortlet producer receives an authorization exception when it tries to store connection information in the Credential Store Framework (CSF) wallet. For information about how to resolve this issue, see the "OmniPortlet Producer Authorization Exception in SSO Environment" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

3.5.3.9.5 Refreshing Group Space Data in WebCenter Spaces

After mid-tier migration, you must refresh the group space data. Also, refresh the member data for each group space individually.

To refresh the group space data:

1. Log on to WebCenter Spaces as an administrator.

2. Click the Administration link, and go to the Group Spaces tab.

3. Click the Refresh icon.

To refresh the member data for a group space:

1. Log on to WebCenter Spaces as an administrator.

2. Go to the desired group space, open the Settings tab, and then the Members tab.

3. Click the Refresh icon in the Manage Group Space Members section.
You must perform this procedure for each group space individually.

Note:
In your migrated WebCenter instance if access is denied to a group space, ensure that the credential store has been migrated successfully and the group space data has been refreshed.
After you upgrade from Oracle WebCenter 11.1.1.1.0 to Oracle WebCenter 11.1.1.2.0, you may initially see a group space GUID in Activity Stream in lieu of a group space name in WebCenter Spaces. This can occur when you configure an Activity Stream task flow instance and select to display activity from a group space that was upgraded. You can work around this issue by generating some activity in that group space, like adding or removing a member. This refreshes the Activity Stream instance with the group space display name.

3.5.3.9.6 Reapplying Configuration Changes

If you want the same configuration as defined in your Oracle WebCenter 11.1.1.1.0, then you must reapply the configuration changes in Oracle WebCenter 11.1.1.2.0. Configuration changes may relate to the any of the following:

- WebCenter Portlet Producers: Any changes made to the provider.xml file of a portlet producer, like changing a proxy server, require that post mid-tier migration you reconfigure those changes, redeploy the portlet producer EAR application, and restart WLS_Portlet Managed Server. For information about redeploying portlet producers, see the "Managing Portlet Producers" chapter in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

- WebCenter Services: While installing Oracle Fusion Middleware 11.1.1.2.0, if you changed the host and port number of the back-end servers on which your WebCenter Services rely, you must reconfigure the required service connections to use the new server configuration. For information about specific services, see the "Managing Services, Portlet Producers, and External Applications" part in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

- WebCenter Wikis and Blogs: Any configuration changes made to your Oracle WebCenter Wiki and Blog Server 11.1.1.1.0, such as changing the theme or setting the attachment size, require that you reapply those changes in Oracle WebCenter Wiki and Blog Server 11.1.1.2.0. To reconfigure settings, use Administration mode of your Oracle WebCenter Wiki and Blog Server. For information, see the "Oracle WebCenter Wiki and Blog Server - Configuration" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

- WebCenter Spaces and Workflows: The WebCenter Spaces workflows functionality requires sca_CommunityWorkflows.jar and WebCenterWorklistDetailApp.ear to be deployed to a SOA server. If WebCenter Spaces workflows were enabled in Oracle WebCenter 11.1.1.1.0, you must redeploy these applications to the SOA server post mid-tier migration. For information, see the "Back-End Requirements for WebCenter Spaces Workflows" section in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

- WebCenter Spaces profile settings: In WebCenter Spaces, profile settings set on the WebCenter Administration > Services > Profile screen are not retained when you upgrade from Oracle WebCenter 11.1.1.1.0 to Oracle WebCenter 11.1.1.2.0. After the upgrade, you must reapply the required profile settings on the WebCenter Administration > Services > People Connections > Profiles screen.

3.5.3.9.7 Importing Wiki Templates and Attachments

In Oracle WebCenter Wiki and Blog Server 11.1.1.1.0, regardless of the repository type configured for the server, templates and attachments are stored in a file-based repository. Oracle WebCenter Wiki and Blog Server 11.1.1.2.0 supports only a database repository; templates and attachments are also stored in the database repository.

If your Oracle WebCenter Wiki and Blog Server 11.1.1.1.0 used a database repository, then during migration templates and attachments are migrated to the database repository configured for Oracle WebCenter Wiki and Blog Server 11.1.1.2.0. If your Oracle WebCenter Wiki and Blog Server 11.1.1.1.0 used a file-based repository, then during migration wiki templates and attachments are migrated to a file-based repository. To make these templates and attachments available in Oracle WebCenter Wiki and Blog Server 11.1.1.2.0, you must manually migrate them to the database repository.

To import attachments for a wiki page, the user who owns that wiki page or you as an administrator must reupload the attachments on the wiki page. When you reupload an attachment, the attachment gets stored in the database repository. Note that attachments must be reuploaded for each wiki page individually.

To migrate templates:

1. Log on to Oracle WebCenter Wiki and Blog Server 11.1.1.2.0 as an administrator.

2. Click the Administration link to open Administration mode.

3. Click Templates.

4. Click import.

5. On the Import Templates page, in the Folder field, enter the path to templates. For example:
$APPLICATIONS_DIRECTORY/owc_wiki/templates.

Where, $APPLICATIONS_DIRECTORY is the directory where you installed Oracle WebCenter Wiki and Blog Server 11.1.1.2.0. That is, $APPLICATIONS_DIRECTORY = MW_HOME/user_projects/applications/DOMAIN_NAME.

6. Click Import Templates. The existing file-based templates are individually re-created in the wiki database repository.

3.5.3.9.8 Migrating Oracle Content Server

Oracle WebCenter 11.1.1.2.0 is compatible with Oracle Content Server 10.1.3.5.1. To migrate your existing Oracle Content Server and prepare it to work with Oracle WebCenter 11.1.1.2.0, you must perform the following tasks:

- Run the WebCenter configuration script, wc_contentserverconfig. This script is available on the Universal Content Management (UCM) media shipped with Oracle WebCenter. For information about how to run the script, see the "Oracle Content Server - Installation" section in the Oracle Fusion Middleware Installation Guide for Oracle WebCenter.

- Reconfigure the identity store for Oracle Content Server. To connect to an LDAP-based identity store, Oracle Content Server 10.1.3.5.1 requires a JPS user provider, instead of an LDAP user provider. Therefore, you must configure a JPS user provider and ensure that the existing LDAP user provider for Oracle Content Server is disabled. For information, see the "Configuring the Identity Store" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

3.5.3.9.9 Configuring Oracle WebCenter Discussions for WebCenter Spaces

When you migrate from Oracle Fusion Middleware 11.1.1.1.0 to Oracle Fusion Middleware 11.1.1.2.0, the patch assistant script migrates the database schema of your Oracle WebCenter Discussions server. Out-of-the-box, Oracle WebCenter Discussions 11.1.1.2.0 is configured to use the embedded LDAP identity store of Oracle WebLogic Server.

You must configure Web Services Security (WS-Security) if you want to use Oracle WebCenter Discussions with WebCenter Spaces.

To configure Oracle WebCenter Discussions:

1. Log on to the Oracle WebCenter Discussions 11.1.1.2.0 server as an administrator by using the following URL format:

http://host:port/owc_discussions/admin

Where host:port refer to the host name and port number of the system where Oracle WebCenter is installed.

2. To verify that Oracle WebCenter Discussions has been migrated successfully, in Jive Forums Admin Console, ensure that "Jive Forums Silver 5.5.20.2-oracle" is displayed in the top-right corner.

3. Configure WS-Security trusted authentication if you want to use Oracle WebCenter Discussions with WebCenter Spaces. For information about how to configure WS-Security, see the "Configuring WS-Security" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

4. Reconfigure SSO for Oracle WebCenter Discussions, if required. For information, see the "Configuring a WebCenter Application to Use Single Sign-On" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

3.5.3.9.10 Migrating Custom WebCenter Applications

To make your custom WebCenter applications available in Oracle WebCenter 11.1.1.2.0, you must migrate them from your Oracle WebCenter 11.1.1.1.0 instance. You do not need to migrate the metadata of these applications because Oracle WebCenter 11.1.1.2.0 schemas are an in-place patch of your Oracle WebCenter 11.1.1.1.0 schemas for MDS, PORTLET, and WEBCENTER.

To migrate a custom WebCenter application:

1. Open the application in Oracle JDeveloper 11.1.1.2.0.
This invokes the migration wizard that automatically migrates your application to Oracle WebCenter 11.1.1.2.0.

2. Save the application.

3. Create a WebLogic Managed Server instance and provision it with a required set of shared libraries. For information, see the "Creating and Provisioning a WebLogic Managed Server Instance" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

4. Create and register the Metadata Service (MDS) repository for your application on the WebLogic Domain's Administration Server instance. For information, see the "Creating and Registering the Metadata Service Repository" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

5. Deploy the application to a Managed Server. For information, see the "Deploying the Application to a WebLogic Managed Server Instance" section and the "Deploying Portlet Producer Applications" section in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

Your custom WebCenter applications may have WebCenter Services integrated that rely on back-end servers. For example, Discussions and Search services rely on Oracle WebCenter Discussions and Oracle SES, respectively. While installing Oracle Fusion Middleware 11.1.1.2.0, if you changed the host or port number of your back-end servers, you must reconfigure the required WebCenter Services to use the new server configuration. For information about specific services, see the "Managing Services, Portlet Producers, and External Applications" part in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.

3.5.3.10 Post Migration Configuration for Oracle Web Services Manager

To migrate Oracle Web Services Manager (WSM), perform the following tasks:

- Purging the Policy Usage Analysis Information from the Metadata Services Repository

- Migrating the Oracle WSM Policies in the MDS Repository

- Migrating Custom Policy Accessor Properties

Note:
Before you can migrate Oracle WSM, you must migrate components of the security environment, such as the identity store and key store configurations. For more information, see Section 3.5.3.5, "Post-Migration Configuration for Oracle Platform Security Services".

3.5.3.10.1 Purging the Policy Usage Analysis Information from the Metadata Services Repository

In this release, the same Oracle Metadata Services (MDS) repository can be used to manage policies across multiple domains. In previous releases, an MDS repository could only be used by a single domain.

If you have analyzed policy usage using the Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) installation, you will need to purge the policy usage analysis information from the MDS repository to ensure that accurate usage results are reflected for the Oracle Fusion Middleware 11g Release 1 (11.1.1.2.0) version.

To purge the policy usage analysis information from the MDS repository, use the deleteMetadata MDS command as follows:

deleteMetadata(application='wsm-pm',server='server_name',
docs='/policyAttachments/**')

server_name specifies the name of the server on which the Oracle WSM policy manager is running.

After purging the policy usage analysis information, you must restart the server.

For more information about managing MDS repositories, see "Maintaining the MDS Repository" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

3.5.3.10.2 Migrating the Oracle WSM Policies in the MDS Repository

In Oracle WSM 11g Release 1 (11.1.1), predefined and custom Oracle WSM policies are stored in the Oracle MDS repository. In this patch set, there are two new predefined policies available:

- oracle/wss_saml_or_username_token_over_ssl_service_policy

- oracle/wss11_saml_or_username_token_with_message_protection_service_policy

You can use Oracle WebLogic Scripting Tool (WLST) commands to upgrade the repository with the new predefined policies. You can also refresh the repository by deleting all Oracle WSM policies from the repository, including custom policies, and then repopulating it using the predefined policies provided in your installation. All of the policies in the repository are also revalidated when you upgrade the repository.

For more information, see "Upgrading the Oracle WSM Policies in the MDS Repository" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

3.5.3.10.3 Migrating Custom Policy Accessor Properties

If you have customized the policy accessor properties, you must re-apply the policy manager connection information once you have migrated your installation. For more information, see "Configuring Platform Policy Properties" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

3.5.4 Installation Process

Table 3-3 describes the 11.1.1.2.0 installation process that must be completed during the migration process.

Table 3-3 Installation Process

Scenario

Description and Steps

Installing products in a new Middleware home

Before you can install 11.1.1.2.0 products in a new Middleware home, ensure that the repository is updated and the 11.1.1.1.0 schema is migrated to the 11.1.1.2.0 schema.

To install products, complete the following steps:

1. Install Oracle WebLogic Server. This step is not required for Web tier.

2. Run product-specific Installers to install the new products.

For more information, see the Oracle Fusion Middleware Installation Planning Guide and the product installation guides in the Oracle Fusion Middleware Documentation Library for the products you are installing and configuring.

Installing products in a new Middleware home, on a second machine, in a Cluster environment

Before you can install 11.1.1.2.0 products in a new Middleware home, ensure that the repository is updated and the 11.1.1.1.0 schema is migrated to the 11.1.1.2.0 schema.

To install products in a Cluster environment, complete the following steps:

1. Install Oracle WebLogic Server. This step is not required for Web tier.

2. Run product-specific Installers to install the new products. Ensure that Middleware home on the second machine must be at the same file path as the first machine.

For more information, see the Oracle Fusion Middleware Installation Planning Guide and the product installation guides in the Oracle Fusion Middleware Documentation Library for the products you are installing and configuring.

3.5.5 Configuration Process

Table 3-4 describes the 11.1.1.2.0 configuration process that must be completed during the migration process.

Table 3-4 Configuration Process

Scenario

Description and Steps

Configuring Oracle Instances in a new Middleware home

Before you can configure Oracle Instances in a new Middleware home, ensure that the repository is updated, the 11.1.1.1.0 schema is migrated to the 11.1.1.2.0 schema, all 11.1.1.2.0 products are installed, and the WebLogic domain is migrated.

To configure Oracle Instances, run the ant master-patch-oinstance command.

Configuring Oracle Instances in a new Middleware home, on a second machine, in a Cluster environment

Before you can configure Oracle Instances in a new Middleware home, ensure that the repository is updated, the 11.1.1.1.0 schema is migrated to the 11.1.1.2.0 schema, all 11.1.1.2.0 products are installed in the Cluster environment (on a second machine), and the WebLogic domain is migrated.

To configure Oracle Instances, run the ant master-patch-oinstance command.

Configuring products in a new WebLogic domain

Before you can configure 11.1.1.2.0 products in a new WebLogic domain, ensure that the repository is updated, the 11.1.1.1.0 schema is migrated to the 11.1.1.2.0 schema, and the 11.1.1.2.0 products are installed in a new Middleware home.

To configure products in a new WebLogic domain, complete the following steps:

1. Start the Oracle Fusion Middleware Configuration Wizard from your new Middleware home.

2. Choose product templates to match components on the old 11.1.1.1.0 domain.

3. For the new domain, choose the same domain name as the old 11.1.1.1.0 domain.

4. Configure servers, machines, or clusters to match the old 11.1.1.1.0 topology.

5. Create domain.

6. Optional: Start Node Manager.

Configuring products in a new WebLogic domain, on a second machine, in a Cluster environment

Before you can configure 11.1.1.2.0 products in a new WebLogic domain, ensure that the repository is updated, the 11.1.1.1.0 schema is migrated to the 11.1.1.2.0 schema, and the 11.1.1.2.0 products are installed in a new Middleware home on a second machine in the Cluster environment.

To configure products in a new WebLogic domain, complete the following steps:

1. Start the Oracle Fusion Middleware Configuration Wizard from your new Middleware home.

2. Choose product templates to match components on the old 11.1.1.1.0 domain.

3. For the new domain, choose the same domain name as the old 11.1.1.1.0 domain.

4. Configure servers, machines, or clusters to match the old 11.1.1.1.0 topology.

5. Create domain.

6. Optional: Start Node Manager.

7. Run the pack command on the new domain on the first machine.

8. Run the unpack command on the second machine.

3.5.6 Properties in the patchMaster.properties File

Table 3-5 describes the properties that you can set in the patchMaster.properties file. All the properties are not mandatory. For the list of properties that are required for specific components, see Table 3-6.

Note:
On Windows, you must use / as the delimiter to specify the property path. For example:

c:/my/path/file

Table 3-5 Patch Master Properties

Properties

Description

patchMaster.Componentlist

List the Fusion Middleware components, you want to patch from 11.1.1.1.0 to 11.1.1.2.0.

Example:

patchMaster.Componentlist=Audit,BAM,DIP,Discoverer,Forms,JPS

patchMaster.Schemaurl

Specify the connection string to a single repository being patched.

Example:

patchMaster.Schemaurl=jdbc:oracle:thin:@localhost:1521:orcl

patchMaster.Schemauser

Specify the system user for the repository specified by patchMaster.Schemaurl.

Example:

patchMaster.Schemauser=SYS AS SYSDBA

patchMaster.Schemaprefix

Specify the repository schema metadata namespace.

Example:

patchMaster.Schemaprefix=DEV

For Oracle Portal users, if you upgraded your Oracle Portal 10g to Oracle Portal 11g R1 (11.1.1.1.0), you must specify the schema prefix as APPSERVER.

For Oracle Internet Directory, you must specify the schema prefix as ODS.

patchMaster.Mwhomenew

Specify the path where your 11.1.1.2.0 home is installed.

Example:

patchMaster.Mwhomenew=/scratch/newhome

patchMaster.Mwhomeold

Specify the path where your 11.1.1.1.0 home is installed.

Example:

patchMaster.Mwhomeold=/scratch/oldhome

patchMaster.Domainhomenew

Specify the Oracle WebLogic Server domain 11.1.1.2.0 home.

Example:

patchMaster.Domainhomenew=/scratch/newhome/user_projects/domains/newDomain

patchMaster.Domainapplicationshomenew

Specify the Oracle WebLogic Server domain applications; 11.1.1.2.0 home.

Example:

patchMaster.Domainapplicationshomenew=/scratch/newhome/user_projects/applications/newDomain

patchMaster.Domainhomeold

Specify the Oracle WebLogic Server domain 11.1.1.1.0 home.

Example:

patchMaster.Domainhomeold=/scratch/oldhome/user_projects/domains/oldDomain

patchMaster.Domainusername

Specify the Oracle WebLogic Server domain user name.

Example:

patchMaster.Domainusername=currentuser

patchMaster.Syspassword

Specify the password for the Oracle Weblogic domain. This property is not available, by default. You may add and set this property. If the property is not present, Patch Assistant prompts you to enter the password.

Example:

patchMaster.Syspassword=welcome1

patchMaster.Oracleinstancenewlist

List the paths to 11.1.1.2.0 Oracle instances.

Example:

patchMaster.Oracleinstancenewlist=/scratch/newinst1,/scratch/newinst2

patchMaster.Oracleinstanceoldlist

List the paths to 11.1.1.1.0), Oracle instances corresponding to 11.1.1.2.0, Oracle instance paths.

Example:

patchMaster.Oracleinstanceoldlist=/scratch/oldinst1,/scratch/oldinst2

patchMaster.Oraclehomenew

Specify the path of 11.1.1.2.0 Oracle home.

Example:

patchMaster.Oraclehomenew=/scratch/myOhomenew

patchMaster.Oraclehomeold

Specify the Path of 11.1.1.1.0 Oracle home.

Example:

patchMaster.Oraclehomeold=/scratch/myOhome

Note: You can patch only one Oracle home at once. Do not specify multiple Oracle homes in the properties file for this entry.

patchMaster.Logdir

The default directory where the log file will be saved.

Example:

patchMaster.Logdir=${patchMaster.Dir}

patchMaster.Loglevel

Specify the logging level to be recorded in the log file. The default log level is info. The other options are error, warning, verbose, and debug.

Example:

patchMaster.Loglevel=info

patchMaster.Domainadminhost

This is either the 11.1.1.1.0 or 11.1.1.2.0 Administration Server host depending on the operation. It is used for starting or stopping domain and instance registration.

Example:

patchMaster.Domainadminhost=localhost

patchMaster.Domainadminport

This is either the 11.1.1.1.0 or 11.1.1.2.0 Administration Server port depending on the operation. It is used for starting or stopping domain and instance registration.

Example:

patchMaster.Domainadminport=7001

Note:
See Appendix B, "Sample Patch Master Properties File", for a sample patchMaster.properties file.

Product-Specific Properties Required in the patchMaster.properties File

Table 3-6 lists the properties required by Oracle Fusion Middleware components in the patchMaster.properties file.

Note:
Patch Assistant validates properties based on operations only. It does not validate properties at the individual product level.

Table 3-6 Properties Required in patchMaster.properties File

Product

Required Properties

Oracle Fusion Middleware Audit Framework

- patchMaster.Componentlist

- patchMaster.Schemaurl

- patchMaster.Schemauser

- patchMaster.Schemaprefix

Oracle Business Intelligence Discoverer

- patchMaster.Componentlist

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Statusfile

- patchMaster.Failonerror

Oracle Directory Integration Platform

- patchMaster.Componentlist

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Domainadminhost

- patchMaster.Domainadminport

Oracle Internet Directory

- patchMaster.Componentlist

- patchMaster.Schemaurl

- patchMaster.Schemauser

- patchMaster.Schemaprefix

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Failonerror

Oracle Virtual Directory

- patchMaster.Componentlist

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Failonerror

Oracle Java Required Files

- patchMaster.Componentlist

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

Oracle Metadata Services

- patchMaster.Componentlist

- patchMaster.Schemaurl

- patchMaster.Schemauser

- patchMaster.Schemaprefix

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Oraclehomenew

Oracle Platform Security Services

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainapplicationshomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Domainadminhost

- patchMaster.Domainadminport

Oracle Portal

- patchMaster.Componentlist

- patchMaster.Schemaurl

- patchMaster.Schemauser

- patchMaster.Schemaprefix

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Statusfile

- patchMaster.Failonerror

Oracle Reports

- patchMaster.Componentlist

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Failonerror

Oracle User Messaging Service

- patchMaster.Componentlist

- patchMaster.Schemaurl

- patchMaster.Schemauser

- patchMaster.Schemaprefix

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Statusfile

- patchMaster.Failonerror

Oracle Web Cache

- patchMaster.Componentlist

- patchMaster.Mwhomenew

- patchMaster.Mwhomeold

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Domainusername

- patchMaster.Oracleinstancenewlist

- patchMaster.Oracleinstanceoldlist

- patchMaster.Oraclehomenew

- patchMaster.Oraclehomeold

Oracle WebCenter

- patchMaster.Componentlist

- patchMaster.Schemaurl

- patchMaster.Schemauser

- patchMaster.Schemaprefix

- patchMaster.Domainhomeold

- patchMaster.Domainapplicationshomenew

Oracle Web Services Manager

- patchMaster.Componentlist

- patchMaster.Domainhomenew

- patchMaster.Domainhomeold

- patchMaster.Logdir

- patchMaster.Loglevel

- patchMaster.Statusfile

- patchMaster.Failonerror

3.5.6.1 Overriding Properties Set in the patchMaster.properties File

You can use the Ant command-line utility to override the properties set in the patchMaster.properties file. You must specify the required property on the command line as follows:

ant -D<property>=<value>

For example, to select components to patch, enter the following command on the command line:

ant -DpatchMaster.Componentlist=SOA,UMS,WebCenter
master-patch-schema

Note that master-patch-schema, in the above example, is the command that uses the new values.

Refer to Table 3-5 for complete information about properties that you can specify on the command line or in the patchMaster.properties file.

Note:
When you override the patchMaster.Schemauser property to specify the system user by using the command-line utility, ensure that you use double quotation marks, as in the following example:

ant -DpatchMaster.Schemauser="SYS AS SYSDBA"

Do not enter the double quotation marks if you edit the patchMaster.properties file directly.

3.5.7 Oracle Fusion Middleware Components Supported by Patch Assistant

Table 3-7 lists Oracle Fusion Middleware components that are supported by Patch Assistant.

Table 3-7 Oracle Fusion Middleware Components Supported by Patch Assistant

Component Name

Release

Oracle Fusion Middleware Audit Framework

11.1.1.2.0

Oracle BPEL Process Manager

11.1.1.2.0

Oracle Business Rules

11.1.1.2.0

Oracle Business-to-Business Integration

11.1.1.2.0

Oracle Business Activity Monitoring

11.1.1.2.0

Oracle Business Intelligence Discoverer

11.1.1.2.0

Oracle Internet Directory

11.1.1.2.0

Oracle Directory Integration Platform

11.1.1.2.0

Oracle Identity Federation

11.1.1.2.0

Oracle Virtual Directory

11.1.1.2.0

Oracle Directory Services Manager

11.1.1.2.0

Oracle Forms

11.1.1.2.0

Oracle Platform Security Services

11.1.1.2.0

Oracle Java Required Files

11.1.1.2.0

Oracle Metadata Services

11.1.1.2.0

Oracle Access Manager

11.1.1.2.0

Oracle TopLink

11.1.1.2.0

Oracle Dynamic Monitoring System (DMS)

11.1.1.2.0

Oracle Java Object Cache

11.1.1.2.0

Oracle Enterprise Manager Fusion Middleware Control

11.1.1.2.0

Oracle HTTP Server

11.1.1.2.0

Oracle Reports

11.1.1.2.0

Oracle Portal

11.1.1.2.0

Oracle Portlet Producers

11.1.1.2.0

Oracle User Messaging Service

11.1.1.2.0

Oracle Web Cache

11.1.1.2.0

Oracle WebCenter Spaces

11.1.1.2.0

Oracle WebCenter Discussions

11.1.1.2.0

Oracle WebCenter Portlets

11.1.1.2.0

Oracle WebCenter Wiki and Blogs

11.1.1.2.0

Oracle Content Server

10.1.3.5.1

Oracle WebLogic Server

10.3.1.0

Oracle Wallet Manager

11.1.1.2.0

Oracle Web Services Manager

11.1.1.2.0

4 Applying the Latest Oracle Fusion Middleware Patch Set

This chapter describes how to use the Patch Set Installers to patch your existing Oracle Fusion Middleware 11g (11.1.1.2.0) environment to make it an 11g (11.1.1.3.0) environment.

This chapter contains the following content:

- Section 4.1, "Summary of the Patch Set Installation Process"

- Section 4.2, "Before You Begin"

- Section 4.3, "Download and Start the Patch Set Installer"

- Section 4.4, "Patch Set Installer Instructions"

- Section 4.5, "Updating Your Schemas with Patch Set Assistant"

- Section 4.6, "Post-Patching Tasks"

- Section 4.7, "Optional Patching Procedures"

- Section 4.8, "Starting the Servers and Processes"

- Section 4.9, "Verifying Your Patch Installation"

4.1 Summary of the Patch Set Installation Process

Figure 4-1 shows the general patching procedure using the Patch Set Installer.

Figure 4-1 Patch Set Installer Procedural Overview and Roadmap

The following provides links to additional information for each of the patching steps.

1. Back up your Middleware home directory and all sub-directories, along with all of your Domain home and Oracle instance home directories.
For more information, see Section 4.2.1.1, "Back Up Your Middleware Home, Domain Home and Oracle Instances".

2. Stop all Managed Servers, the Administration Server, all system components, and node manager.
For more information, see Section 4.2.1.2, "Stop the Servers and Processes".

3. Run the Upgrade installer to update WebLogic Server to the latest version.
For more information, see Section 4.2.1.3, "Patch Oracle WebLogic Server".

4. Check to make sure there are no optional procedures you need to perform.
For more information, see Section 4.2.2, "Check for Optional Patching Tasks".

5. Run the Patch Set Installer to update the software in your Oracle home directory.
For more information, see Section 4.3, "Download and Start the Patch Set Installer" and Section 4.4, "Patch Set Installer Instructions".

6. If necessary, run the Patch Set Assistant to update the schemas on your database.
For more information, see Section 4.5, "Updating Your Schemas with Patch Set Assistant".

7. Perform any necessary post-patching tasks, then start all servers and processes in the domain.
For more information, see Section 4.6, "Post-Patching Tasks" and Section 4.8, "Starting the Servers and Processes".

8. Verify that your patch installation is complete.
For more information, see Section 4.9, "Verifying Your Patch Installation".

4.2 Before You Begin

This section describes tasks that should be completed before you run the Patch Set Installer:

- Section 4.2.1, "Perform General Pre-Patching Tasks"

- Section 4.2.2, "Check for Optional Patching Tasks"

4.2.1 Perform General Pre-Patching Tasks

This section describes tasks that should be completed before you patch your software:

- Section 4.2.1.1, "Back Up Your Middleware Home, Domain Home and Oracle Instances"

- Section 4.2.1.2, "Stop the Servers and Processes"

- Section 4.2.1.3, "Patch Oracle WebLogic Server"

4.2.1.1 Back Up Your Middleware Home, Domain Home and Oracle Instances

Before you begin your patch installation, you should back up your Middleware home directory, your Domain home directory, and your Oracle instances. If your patch installation in unexpectedly interrupted, or if you choose to cancel out of the installation before it is complete, you may not be able to install the patch unless you restore your environment to the previous configuration before running the Patch Set Installer again. There is no deinstallation option with the Patch Set Installer.

4.2.1.2 Stop the Servers and Processes

Before you run Patch Set Installer, you should stop all servers and processes.

Instructions for stopping an Oracle Fusion Middleware environment are provided in "Stopping an Oracle Fusion Middleware Environment" in Oracle Fusion Middleware Administrator's Guide.

If you are running Node Manager, you should also stop Node Manager. You can do this by closing the console window in which Node Manager is running, or by using the stopNodeManager WLST command.

See "stopNodeManager" in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for more information.

4.2.1.3 Patch Oracle WebLogic Server

Before you run the Patch Set Installer, make sure you have patched Oracle WebLogic Server to the latest version using the Upgrade installer. The Patch Set Installer requires Oracle WebLogic Server version 10.3.3.

1. Download the Upgrade installer from My Oracle Support.
For instructions, see "Downloading an Upgrade Installer From My Oracle Support" in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

2. Run the Upgrade installer in graphical mode to patch your WebLogic Server.
For instructions, see "Running the Upgrade Installer in Graphical Mode" in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

4.2.2 Check for Optional Patching Tasks

Depending on your specific configuration, you may be using some products that require information to be backed up prior to patching, and then restored after patching is complete.

Section 4.6, "Post-Patching Tasks" contains tasks that must be performed if you are patching certain products or combinations of products. If a specific procedure applies to you based on your products or environment, you must perform the task as described in order for your domain to function properly after patching. Some of these procedures require pre-patching tasks, so make sure you read the instructions carefully before proceeding.

Section 4.7, "Optional Patching Procedures" also contains tasks for specific products or combinations of products. However, if you choose to skip a task in this section, your domain will still function properly after you patch your software.

4.3 Download and Start the Patch Set Installer

To download and start the Patch Set Installer:

1. Download the patch set from the Oracle Technology Network, My Oracle Support, or Oracle E-Delivery.
For more information, see "Obtain the Oracle Fusion Middleware Software" in Oracle Fusion Middleware Installation Planning Guide.

2. Unpack the downloaded archive that contains the patch set that you want to install into a directory on the target computer.

3. Change directory to the Disk1 folder inside the unpacked archive folder.

4. Start the installer:
On UNIX operating systems:

./runInstaller

On Windows operating systems:

setup.exe

Depending on your system environment and product you are updating, you may be prompted to provide the location of a JRE/JDK on your system when you start the installer. When you installed Oracle WebLogic Server, a JRE was installed on your system. You can use this location (the location of the jre directory) to start the installer. The default location for the JRE is MW_HOME/jdk160_18 (on UNIX operating systems) or MW_HOME\jdk160_18 (on Windows operating systems), where MW_HOME is the Middleware home directory.

Make sure you specify the absolute path to your JRE/JDK location; relative paths are not supported.

If you plan to use a different JRE/JDK than the one included with Oracle WebLogic Server, you should refer to the Certification document to view the supported JDKs:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

4.4 Patch Set Installer Instructions

After you have started the Patch Set Installer, follow the instructions in Table 4-1 to patch your Oracle Fusion Middleware components.

If you need additional help with any of the installation screens, refer to Appendix A, "Patch Set Installer Screens" or click Help to access the online help.

Table 4-1 Installation Flow for Patch Set Installer

No.

Screen

When Does This Screen Appear?

Description and Action Required

1

Welcome Screen

Always.

Click Next to continue.

2

Specify Installation Location Screen

Always.

Specify your existing Oracle Middleware home and product Oracle home locations.

Click Next to continue.

3

Specify Security Updates Screen

Only if you have not previously registered for security updates for the following products only:

- Oracle Web Tier

- Oracle Identity Management

- Oracle Portal, Forms, Reports and Discoverer

Specify your existing Oracle Middleware home and product Oracle home locations.

Click Next to continue.

4

Installation Summary Screen

Always.

Verify the installation about to be performed.

Click Install to continue.

5

Installation Progress Screen

Always.

This screen shows the progress of the installation.

Click Next when the installation is 100% complete.

6

Installation Complete Screen

Always.

Click Finish to dismiss the screen.

If you are a new Oracle Fusion Middleware user, your next step is to create and configure a WebLogic domain. Return to your product installation guides for domain configuration and creation information.

If you are an existing Oracle Fusion Middleware user, go to Section 4.5, "Updating Your Schemas with Patch Set Assistant" and continue with this document.

4.5 Updating Your Schemas with Patch Set Assistant

The following schemas must be updated with Patch Set Assistant to match the new software version number:

- Oracle Portal (PORTAL)

- Oracle Identity Management (OID)

- SOA Infrastructure (SOAINFRA)

- Audit Services (IAU)

For more information, see Chapter 5, "Updating Your Schemas with Patch Set Assistant".

If the product you are patching does not use one of these schemas, you can skip this section and proceed to Section 4.6, "Post-Patching Tasks".

4.6 Post-Patching Tasks

This section contains information about manual tasks that must be performed after the patch installation is complete. Some of the tasks may not apply to your environment as you may not be using the products in question. However, if you are, then the manual steps must be performed in order for your domain to work correctly.

The following topics are covered:

- Section 4.6.1, "Post-Patching Tasks for System Components"

- Section 4.6.2, "Post-Patching Task for Oracle Identity Management"

- Section 4.6.3, "Post-Patching Task for Oracle Web Tier"

- Section 4.6.4, "Post-Patching Tasks for Oracle SOA Suite"

- Section 4.6.5, "Post-Patching Tasks for Oracle Portal and Oracle WebCenter"

4.6.1 Post-Patching Tasks for System Components

Oracle Fusion Middleware system components include the following:

- Oracle HTTP Server

- Oracle Web Cache

- Oracle Internet Directory

- Oracle Virtual Directory

- Oracle Forms Services

- Oracle Reports

- Oracle Business Intelligence Discoverer

- Oracle Business Intelligence

If you have patched one or more of these components, the tasks in this section must be performed. For more information about system components, refer to "Understanding Key Oracle Fusion Middleware Concepts" in Oracle Fusion Middleware Administrator's Guide.

The following tasks must be performed:

- Section 4.6.1.1, "Redeploying Your System Components"

- Section 4.6.1.2, "Upgrading the Version Number String Shown in Oracle Enterprise Manager"

- Section 4.6.1.3, "Updating File System Permissions to Allow for Privileged Port Access"

4.6.1.1 Redeploying Your System Components

After you have patched your system components and started all services, you must manually redeploy your system components. To do so, follow the instructions below:

Note:
This procedure is not required for Oracle Internet Directory and Oracle Virtual Directory.

1. Make sure the Administration Server is up and running.

2. Run the opmnctl unregisterinstance command.

3. Run the opmnctl redeploy command.

4. Run the opmnctl registerinstance command.

For more information about opmnctl commands, see "opmnctl usage" in Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide.

4.6.1.2 Upgrading the Version Number String Shown in Oracle Enterprise Manager

After you have patched your system component software, use the opmnctl updatecomponentregistration command to manually update the version number string that is shown in Oracle Enterprise Manager. Below is the syntax for this command:

Note:
Before running the opmnctl updatecomponentregistration command, make sure the Administration Server is up and running.
OPMN does not need to be started in order to run the opmnctl updatecomponentregistration command.

opmnctl updatecomponentregistration -componentName component_name -Sport ssl_port_number -Port non_ssl_port_number

For example, to update the version number string for an Oracle Internet Directory component called my_oid (you will be prompted for the login and password to the Administration Server):

opmnctl updatecomponentregistration -componentName my_oid -Sport 3131 -Port 3060

Command requires login to weblogic admin server (adminserver.mydomain.com):
Username: weblogic
Password:

Updating component registration on admin server.Command succeeded.

Some system components do not require port numbers to be specified. For example, to update the version string number for the Oracle Virtual Directory instance named ovd1:

opmnctl updatecomponentregistration -componentName ovd1

After running the opmnctl updatecomponentregistration command, you must start the instance and restart the Administration Server. For more information on how to use the opmnctl updatecomponentregistration command, refer to:

- "Updating the Component Registration of an Oracle Instance Using OPMNCTL" in Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

- "updatecomponentregistration" in Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide.

4.6.1.3 Updating File System Permissions to Allow for Privileged Port Access

On UNIX operating systems, if your system components are configured to use privileged port numbers (port numbers less than 1024), some of your file system permissions may be reset after patching your software. This section contains information describing how to reset your file system permissions after patching your software.

4.6.1.3.1 Restoring File Permissions for Oracle Internet Directory

If you have configured privileged ports for Oracle Internet Directory, the Patch Set Installer overrides the file permissions for some of the files.

To restore the file permissions, run the oidRoot.sh script as root user. This script is located in the Oracle home directory.

4.6.1.3.2 Reconfiguring Oracle Web Cache for Privileged Ports

When you patch an Oracle Fusion Middleware 11g (11.1.1.2.0) environment that uses Oracle Web Cache, the Oracle Web Cache binaries are relinked implicitly. If you have a configuration with privileged ports, you must re-run the setroot command of the webcache_setuser.sh script.

See "Configuring Root Privilege for Privileged Ports and More than 1,024 File Descriptors" in the Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache for instructions.

4.6.1.3.3 Restoring the File Permissions for Oracle HTTP Server

If you have installed Oracle HTTP Server (either the stand-alone version through the Oracle Web Tier installation or the embedded version through the Oracle Portal, Forms, Reports and Discoverer installation), its permissions are changed when you patch the software.

To enable your Oracle HTTP Server to use privileged ports, use the following commands to change permissions:

chown root ORACLE_HOME/ohs/bin/.apachectl
chmod 6750 ORACLE_HOME/ohs/bin/.apachectl

4.6.2 Post-Patching Task for Oracle Identity Management

After installing the patch set for Oracle Internet Directory, the replication status shown in Enterprise Manager may be incorrect. To get the correct replication status, you must run the oidtdip.sql and ldapxgrt.sql scripts. These script are located in the IM_ORACLE_HOME/ldap/admin (on UNIX operating systems) or IM_ORACLE_HOME\ldap\admin (on Windows operating systems) directory. You must run these scripts as the Oracle Internet Directory (ODS) schema user on the database where the ODS schema is installed.

4.6.3 Post-Patching Task for Oracle Web Tier

For each Web Tier instance that is associated with a WebLogic Server (managed by Oracle Enterprise Manager), you will need to do the following after patching your Web Tier Oracle home:

1. Update the NonJ2EEManagement application installed on the WebLogic Server.
On UNIX operating systems:

INSTANCE_HOME/bin/opmnctl redeploy

On Windows operating systems:

INSTANCE_HOME\bin\opmnctl redeploy

2. Re-register the instance so that component property information (such as component version) are updated.
On UNIX operating systems:

INSTANCE_HOME/bin/opmnctl unregisterinstance
INSTANCE_HOME/bin/opmnctl registerinstance

On Windows operating systems:

INSTANCE_HOME\bin\opmnctl unregisterinstance
INSTANCE_HOME\bin\opmnctl registerinstance

For more information about the opmn unregisterinstance command, see "unregisterinstance" in Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide.

For more information about the opmn registerinstance command, see "registerinstance" in Oracle Fusion Middleware Oracle Process Manager and Notification Server Administrator's Guide.

The following example series of commands is used to update the Oracle HTTP Server version number shown in Enterprise Manager:

opmnctl redeploy
opmnctl unregisterinstance -instanceName ohs1 -adminHost myHost -adminPort 7001
opmnctl registerinstance -adminHost myHost -adminPort 7001

3. Restart the Administration Server and the log in to Enterprise Manager.

4.6.4 Post-Patching Tasks for Oracle SOA Suite

This section contains the following topics:

- Section 4.6.4.1, "Saving and Restoring XEngine Customizations for Oracle B2B"

- Section 4.6.4.2, "Updating the Oracle Data Integrator Clients if BAM-ODI Integration is Enabled"

4.6.4.1 Saving and Restoring XEngine Customizations for Oracle B2B

The procedure in this section is needed only if you use custom XEngine configurations in cases where B2B server is integrated with B2B EDI endpoints. In such cases, all B2B domains created from the same installation share the a single XEngine configuration stored within the MW_HOME/SOA_ORACLE_HOME/third_party/edifecs/XEngine (on UNIX operating systems) or MW_HOME\SOA_ORACLE_HOME\third_party\edifecs\XEngine (on Windows operating systems) directory.

To preserve your XEngine customizations:

1. Prior to patching Oracle SOA Suite, back up all contents in the MW_HOME/SOA_ORACLE_HOME/third_party/edifecs/XEngine (on UNIX operating systems) or MW_HOME\SOA_ORACLE_HOME\third_party\edifecs\XEngine (on Windows operating systems) directory.
For example, on a UNIX operating system:

cp -pr SOA_Oracle_Home/soa/thirdparty/edifecs/XEngine backup_location

2. Run the Patch Set Installer to update the software.

3. Unzip the XEngine ZIP file in the MW_HOME/SOA_ORACLE_HOME/third_party/edifecs/XEngine (on UNIX operating systems) or MW_HOME\SOA_ORACLE_HOME\third_party\edifecs\XEngine (on Windows operating systems) directory.
For example, on a UNIX operating system:

cd SOA_Oracle_Home/soa/thirdparty/edifecs
gunzip XEngine.tar.gz
tar -xvf XEngine.tar

4. Restore only the customized configuration files from your backup location.
For example, if you made changes to the XERegistry.xml file on a UNIX operating system:

cp backup_location/config/XERegistry.xml SOA_Oracle_Home/soa/thirdparty/edifecs/XEngine/config

4.6.4.2 Updating the Oracle Data Integrator Clients if BAM-ODI Integration is Enabled

If you are currently using Oracle BAM and Oracle Data Integrator (ODI) integration, you must re-run an installation script to update your Oracle ODI clients after running the Patch Set Installer to update your software.

The Oracle BAM interface used by ODI has undergone some changes between releases which require an update by all ODI client endpoints. This manual step is only required for domains where a BAM-ODI integration has been configured.

For each such domain, do the following:

1. Using the Middleware home directory under which Oracle BAM is installed, generate a wlfullclient.jar file by using the instructions in "Using the WebLogic JarBuilder Tool" in Oracle Fusion Middleware Programming Stand-alone Clients for Oracle WebLogic Server.

2. Copy wlfullclient.jar to the ODI_HOME/lib/weblogic directory.

3. Copy the following Oracle BAM .jar files to the ODI_HOME/lib directory:

SOA_ORACLE_HOME/bam/modules/oracle.bam_11.1.1/oracle-bam-common.jar
SOA_ORACLE_HOME/bam/modules/oracle.bam_11.1.1/oracle-bam-etl.jar
SOA_ORACLE_HOME/bam/modules/oracle.bam_11.1.1/oracle-bam-adc-ejb.jar
SOA_ORACLE_HOME/bam/modules/oracle.bam.thirdparty_11.1.1/commons-codec-1.3.jar
SOA_ORACLE_HOME/bam/modules/oracle.bam.thirdparty_11.1.1/xstream-1.3.1.jar
oracle_common/modules/oracle.odl_11.1.1/ojdl.jar
oracle_common/modules/oracle.jps_11.1.1/jps-api.jar
oracle_common/modules/oracle.dms_11.1.1/dms.jar
oracle_common/modules/org.jaxen_1.1.1.jar

4. Copy the following Oracle BAM Knowledge Modules from the SOA_ORACLE_HOME/bam/ODI/knowledge_modules directory to the ODI_HOME/lib directory:

KM_CKM Get Oracle BAM Metadata.xml
KM_IKM SQL to Oracle BAM (delete).xml
KM_IKM SQL to Oracle BAM (insert).xml
KM_IKM SQL to Oracle BAM (looksert natural).xml
KM_IKM SQL to Oracle BAM (looksert surrogate).xml
KM_IKM SQL to Oracle BAM (update).xml
KM_IKM SQL to Oracle BAM (upsert).xml
KM_LKM Get Source Metadata.xml
KM_LKM Oracle BAM to SQL.xml
KM_RKM Oracle BAM.xml

5. Backup the following ODI_HOME configuration files:

ODI_HOME/lib/bam_odi.logging.properties
ODI_HOME/lib/config/BAMODIConfig.xml

6. Copy the new version of the ODI configuration files from the SOA_ORACLE_HOME/bam/ODI directory to the ODI_HOME directory as follows:

SOA_ORACLE_HOME/bam/ODI/config/bam_odi.logging.properties to ODI_HOME/lib/bam_odi.logging.properties
SOA_ORACLE_HOME/bam/ODI/config/BAMODIConfig.xml to ODI_HOME/lib/config/BAMODIConfig.xml

4.6.5 Post-Patching Tasks for Oracle Portal and Oracle WebCenter

This section contains the following topics:

- Section 4.6.5.1, "Saving and Restoring OmniPortlet and WebClipping Customizations for Oracle Portal and Oracle WebCenter"

- Section 4.6.5.2, "Updating Oracle WebCenter Wiki and Blog Server Files"

- Section 4.6.5.3, "Enabling Process Spaces in a WebCenter Domain"

4.6.5.1 Saving and Restoring OmniPortlet and WebClipping Customizations for Oracle Portal and Oracle WebCenter

This procedure is only needed if you are using OmniPortlet and WebClipping customizations, and they are being used with a file-based preferences store. By default, in Oracle WebCenter and Portal, file-based preferences store is not used. Such stores are only used by default for 11g Release 1 (11.1.1) Portal environments that were upgraded from their 10g versions.

When you apply the Oracle Fusion Middleware 11.1.1.3.0 patch set, both the Omniportlet and WebClipping applications are re-deployed and all customizations and configuration data are lost. Therefore, before running Patch Set Installer, you must save the OmniPortlet and WebClipping configuration and customizations to ensure that customizations are not lost after applying the patch set.

4.6.5.1.1 Saving Your Customizations

To save and backup your customizations, you must first find the following directories:

- path_to_war_directory/WEB-INF/providers/omniPortlet

- path_to_war_directory/WEB-INF/providers/webclipping/

The path_to_war_directory refers to the following path on a UNIX operating system:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_version/randomly_generated_directory/war

DOMAIN_HOME is the domain home locations for your Oracle Portal or Oracle WebCenter domain, as specified on the "Specify Domain Name and Location" screen in the Configuration Wizard.

After you locate the omniportlet directory, you can use the following command to back up the directory:

cp -fr path_to_war_directory/WEB-INF/providers/omniPortlet backup_location

4.6.5.1.2 Restoring Your Customizations

To restore OmniPortlet and WebClipping configuration and customizations:

1. Find out the path to the following directories:

- path_to_war_directory/WEB-INF/providers/omniPortlet

- path_to_war_directory/WEB-INF/providers/webclipping/

- path_to_war_directory/WEB-INF/providers/omniPortlet

- path_to_war_directory/WEB-INF/providers/webclipping/

The path_to_war_directory refers to the following path on a UNIX operating system:

DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/portalTools_version/randomly_generated_directory/war

DOMAIN_HOME is the domain home locations for your Oracle Portal or Oracle WebCenter domain, as specified on the "Specify Domain Name and Location" screen in the Configuration Wizard.

Note:
Since the Patch Set Installer re-deployed the OmniPortlet and WebClipping applications, the new path may be different than the path from where you backed up customizations.

2. Replace these directories with their backed up copies.
For example, to restore the omniportlet directory, you can use the following command:

cp -fr backup_location path_to_war_directory/WEB-INF/providers/omniPortlet

3. In the Oracle Portal domain, restart the Managed Server WLS_PORTAL.

4. In the Oracle WebCenter domain, restart the Managed Server WLS_Portlet.

4.6.5.2 Updating Oracle WebCenter Wiki and Blog Server Files

If you are using wiki and blog capabilities with Oracle WebCenter, you must copy the updated wiki and blog files to your applications home directory (by default, MW_HOME/user_projects/applications on a UNIX operating system or MW_HOME\user_projects\applications on a Windows operating system) in order for wiki and blogs to work after you have patched the software. This applications home directory is where all the applications you created in your WebCenter domain reside.

To copy updated wiki and blog files:

- Back up your wiki configuration file, application_config.script located at:

APPLICATION_HOME/domain_name/owc_wiki/WEB-INF/classes/application_config.script

- Copy files from Oracle WebCenter Wiki and Blog Server's deployment directory in ORACLE_HOME/wikiserver/owc_wiki to your WebCenter APPLICATION_HOME/domain_name directory.
For example, on a UNIX operating system:

cp -r /home/Oracle/Middleware/Oracle_WC1/wikiserver/owc_wiki /home/Oracle/Applications/wc_domain/.

4.6.5.3 Enabling Process Spaces in a WebCenter Domain

This manual step should be followed if you would like to add Process Spaces BPM functionality – which is an integration between WebCenter and a BPM enabled SOA domain - to a WebCenter domain. This procedure must be performed regardless of whether the domain was an existing Release 11.1.1.2.0 domain which was updated to Release 11.1.1.3.0 or whether it is a brand new domain created with a brand new Release 11.1.1.3.0 installation.

To learn more about Process Spaces functionality, refer to "Understanding Oracle Business Process Management Process Spaces" in Oracle BPEL Process Manager User's Guide.

1. Find the Process Portal installation package. This is a file called processportal.zip file located in the SOA_ORACLE_HOME/bpm (on UNIX operating systems) or SOA_ORACLE_HOME\bpm (on Windows operating systems) directory. After locating this file, unzip it within any given directory on a machine where you have an Oracle WebCenter installation.

2. Within the exploded directory, edit the process-portal-install.properties file and fill in all fields to provide the required Oracle BPM database, BPM and WebCenter domain, and Oracle WebCenter installation information.

3. Establish domain trust between the SOA domain where the BPM server is running and your WebCenter domain by setting their domain trust password to the same value.

4. Modify the install.xml script to set the domain password for Oracle WebCenter:
If Oracle Content Server and Oracle Discussions connections are already configured in Oracle WebCenter:

1. Set the wcConfigServices property to false in the process-portal-install.properties file.

2. Run the following ant command:

ant -f install.xml

3. Start the Administration Server and WebCenter Spaces.

If Oracle Content Server and Oracle Discussions connections are not configured in Oracle WebCenter:

1. Set the wcConfigServices property to true in the process-portal-install.properties file.

2. Run the following ant command:

ant -f install.xml

3. Start the Administration Server and WebCenter Spaces.

4. Run the following ant command:

ant -f install.xml post-install -DpiArgs="-importGSOnly"

4.7 Optional Patching Procedures

This section contains information about procedures that should be followed depending on whether or not you utilize and/or customize certain products. If you choose to skip these procedures, your domain will still work correctly.

The following topics are covered:

- Section 4.7.1, "Enabling WS-AtomicTransaction in JRF"

- Section 4.7.2, "Updating the Oracle Virtual Directory Version Number in Oracle Directory Service Manager"

- Section 4.7.3, "Securing UMS JMS Resources"

- Section 4.7.4, "Adding New OWSM Pre-Defined Policies"

4.7.1 Enabling WS-AtomicTransaction in JRF

WS-AtomicTransaction is a new feature of JRF web services as of 11g Release 11.1.1.3.0. Domains created in earlier Oracle Fusion Middleware releases will not have the required entry in policy-accessor-config.xml and will therefore not have WS-AtomicTransaction enabled for JRF web services and web service clients.

To enable WS-AtomicTransaction, do the following:

1. Edit the following file.
On UNIX operating systems:

DOMAIN_HOME/domain_name/config/fmwconfig/policy-accessor-config.xml

On Windows operating systems:

DOMAIN_HOME\domain_name\config\fmwconfig\policy-accessor-config.xml

2. In the Interceptors section, add the following code:

<interceptor name="ClientWSATInterceptor“
class="oracle.j2ee.ws.client.transaction.ClientWSATInterceptor"
category="transaction" />
<interceptor name="ServerWSATInterceptor“
class="oracle.j2ee.ws.server.transaction.ServerWSATInterceptor"
category="transaction" />

3. In the Interceptor Chains section, add the following code:

<interceptor-ref name="ServerWSATInterceptor"/>
<interceptor-ref name="ClientWSATInterceptor"/>

4.7.2 Updating the Oracle Virtual Directory Version Number in Oracle Directory Service Manager

To update the Oracle Virtual Directory version number string in Oracle Directory Service Manager:

1. Set the JAVA_HOME and ANT_HOME environment variables.
For example, on a UNIX operating system, set the JAVA_HOME as shown below:

export JAVA_HOME=/home/Oracle/Middleware/jdk160_18

The ANT_HOME should be set to MW_HOME/modules/org.apache.ant_1.7.1 (on UNIX operating systems) or MW_HOME\modules\org.apache.ant_1.7.1 (on Windows operating systems). Below is an example on a UNIX operating system:

export ANT_HOME=/home/Oracle/Middleware/modules/org.apache.ant_1.7.1

2. On UNIX operating systems, add JAVA_HOME/bin and ANT_HOME/bin to the PATH environment variable. On Windows operating systems, add JAVA_HOME\bin and ANT_HOME\bin to the PATH environment variable.
For example, on a UNIX operating system:

export PATH=$ANT_HOME/bin:$PATH

3. Go to the ORACLE_HOME/ovd/patchset (on UNIX operating systems) or ORACLE_HOME\ovd\patchset (on Windows operating systems) directory and run the following command:

ant updateOVDVersion -Dovd_instance=ovd_instance_location

For example, on a UNIX operating system:

ant updateOVDVersion -Dovd_instance=/home/Oracle/Middleware/asinst_1

4. Restart the Oracle Virtual Directory instance.

4.7.3 Securing UMS JMS Resources

If you are using User Messaging Service (UMS) capabilities of Oracle SOA Suite, you must secure your UMS JMS resources to ensure that anonymous clients are not able to access these resources and therefore send unintended notifications to UMS configured endpoints.

The following procedure must be performed on each domain that is using these capabilities:

1. Apply Oracle WebLogic Server authorization policies to your UMS JMS resources to protect them from anonymous access. For instructions, see "Securing User Messaging Service" in Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.

2. To ensure that the UMS application has the appropriate permissions to access the protected JMS resources, the UMS domain's policies need to be updated by executing the ps2Upgrade() WLST command which adds new policies from the installation directory to the UMS domain's policy store.
The syntax for the ps2Upgrade() command is shown below:

ps2Upgrade(ps1Config="full_path_to_11.1.1.2.0_jps-config.xml_file", ps2JaznData="full_path_to_11.1.1.3.0_system-jazn-data.xml_file")

Below is an example of this command:

ps2Upgrade(
ps1Config="/home/data/domains/WLS_SOAWC/config/fmwconfig/jps-config.xml",
ps2JaznData="/home/Oracle/Middleware/oracle_common/modules/oracle.jps_11.1.1/domain_config/system-jazn-data.xml")

You can also run this command in scripting mode:

ps2Upgrade.py
-ps1Config full_path_to_11.1.1.2.0_jps-config.xml_file
-ps2JaznData full_path_to_11.1.1.3.0_system-jazn-data.xml_file)

For example:

ps2Upgrade.py
-ps1Config /home/data/domains/WLS_SOAWC/config/fmwconfig/jps-config.xml
-ps2JaznData /home/Oracle/Middleware/oracle_common/modules/oracle.jps_11.1.1/domain_config/system-jazn-data.xml)

After running the command, you should restart all your servers for the changes to take effect.

For more information about WLST commands, refer to Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

4.7.4 Adding New OWSM Pre-Defined Policies

Each new patchset of Oracle Web Services Manager (OWSM) can contain new pre-defined web services policies. If you would like to take advantage of such new policies for an existing domain, you must run the upgradeWSMPolicyRepository() WLST command as described in "Upgrading the Oracle WSM Policies in the MDS Repository" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

4.8 Starting the Servers and Processes

After you have finished patching your software and performing any necessary post-patching tasks, you are ready to start the servers and processes.

Instructions for starting an Oracle Fusion Middleware environment are provided in "Starting an Oracle Fusion Middleware Environment" in Oracle Fusion Middleware Administrator's Guide.

You can start Node Manager as described in "Starting Node Manager" in Oracle Fusion Middleware Node Manager Administrator's Guide for Oracle WebLogic Server.

4.9 Verifying Your Patch Installation

To verify the installation, start your browser and enter the following URLs:

- To access the Administration Server console:

http://host:admin_server_port/console

- If you configured your Administration Server to accept SSL connection, use the following URL to access the Administration Server console in secure mode:

https://host:secure_admin_server_port/console

- To access Enterprise Manager:

http://host:admin_server_port/em

5 Updating Your Schemas with Patch Set Assistant

The Patch Set Assistant is used in patch set releases only to update the database schema of an Oracle Fusion Middleware component. This tool updates the 11g Release 1 (11.1.1.2.0) version of the schema to 11g Release 1 (11.1.1.3.0). If you are interested in creating new schemas or dropping existing schemas, you must use the Repository Creation Utility (RCU). Information is provided in Oracle Fusion Middleware Repository Creation Utility User's Guide.

The following component schemas must be updated with the Patch Set Assistant in order to update them to 11g Release 1 (11.1.1.3.0):

- Oracle Portal (PORTAL)

- Oracle Identity Management (OID)

- SOA Infrastructure (SOAINFRA)

- Audit Services (IAU)

Note:
Only Oracle Database and Microsoft SQL Server Database versions of these schemas are updated; IBM DB2 Databases were not supported in 11g Release 1 (11.1.1.2.0) and earlier.

This chapter contains the following topics:

- Section 5.1, "Before You Begin"

- Section 5.2, "Running the Patch Set Assistant"

- Section 5.3, "Patch Set Assistant Log Files"

5.1 Before You Begin

This section contains information about things you should check before you run the Patch Set Assistant:

- Section 5.1.1, "Back Up Your Database and Database Schemas"

- Section 5.1.2, "Check Your Database and Schemas"

- Section 5.1.3, "Check the aq_tm_processes Value for Oracle Portal"

5.1.1 Back Up Your Database and Database Schemas

Before running Patch Set Assistant, you should perform a physical backup of your database. Refer to your database documentation for more information.

If you run the Patch Set Assistant to upgrade an existing schema and it does not succeed, you must restore the original schema before you can try again. Make sure you backup your existing database schemas before you run the Patch Set Assistant.

5.1.2 Check Your Database and Schemas

Before running Patch Set Assistant, you should check to make sure that your database is up and running and that the schemas you want to update exist in the database. For example, on Oracle databases, use SQL*Plus to login as user prefix_schemaname to verify that the schema exists.

5.1.3 Check the aq_tm_processes Value for Oracle Portal

If you are running the Patch Set Assistant for the Oracle Portal schema on an Oracle database, make user that the aq_tm_processes value in your database is greater than 0. To check, use the following command after connecting to the database:

show parameter aq_tm_processes;

If the value returned is 0, use the following command to change the value to 1:

alter system set aq_tm_processes=1 scope=both;

5.2 Running the Patch Set Assistant

The Patch Set Assistant is installed into the ORACLE_HOME/bin (on UNIX operating systems) or ORACLE_HOME\bin (on Windows operating systems) directory by the Sparse Installer (see Chapter 4, "Applying the Latest Oracle Fusion Middleware Patch Set").

You can only use the Patch Set Assistant to patch a component schema if the schema matches the product type in the Oracle home from which the Patch Set Assistant started. In other words, if you run the Patch Set Assistant from an Oracle home containing Oracle SOA Suite, you cannot patch your existing Oracle Portal schema; you would have to run the Patch Set Assistant from an Oracle home that contained Oracle Portal.

Below is the error message you would see if you tried to update the Oracle Portal schema from an Oracle home that did not contain Oracle Portal:

PSA-02002: unsupported Oracle home type for patching component PORTAL
The command failed to complete successfully

5.2.1 Starting Patch Set Assistant

To start Patch Set Assistant, go to the ORACLE_HOME/bin (on UNIX operating systems) or ORACLE_HOME\bin (on Windows operating systems) directory for the product schema you want to patch, then run the following command:

On UNIX operating systems:

./psa

On Windows operating systems:

psa.bat

5.2.2 Command Line Syntax

The full command line syntax for the Patch Set Assistant is shown below:

./psa (or psa.bat)
-dbType database_type
-dbConnectString 'database_connection_URL'
-dbaUserName dba_user_name
-schemaUserName schema_user_name
[-logLevel log_level]
[-invPtrLoc inventory_location]

See Table 5-1 for descriptions for these parameters.

Table 5-1 Patch Set Assistant Command Line Parameters

Parameter

Description

-dbType

Database type. Only "Oracle" or "Microsoft" are supported. The default is "Oracle."

-dbConnectString

Database connection URI.

For Oracle databases:

'//host:port/service_name'

For Microsoft SQL Server databases:

'//host:port;DatabaseName=dbname'

Note that the connection URI must be enclosed by a single quote (') character.

For Oracle RAC databases, you only need to specify the connection URI for a single instance.

-dbaUserName

Database administrator user name. For Oracle databases, this is usually SYS or SYSTEM; for Microsoft SQL Server databases, this is usually sa.

You will be prompted for the database administrator password from the command line.

-schemaUserName

User name of the schema being upgraded (for example, PORTAL, ODS, SOAINFRA, or IAU). ODS is the default schema name for Oracle Internet Directory.

This name must match one of the version 11.1.1.2.0 schema names that was created using Repository Creation Utility (RCU).

In addition, you must specify the schema user name in all CAPS for Microsoft SQL Server databases; this is because Microsoft SQL Server is case-sensitive and RCU creates schema names using all CAPS.

-logLevel

Logging level. One of the following:

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

- TRACE

The default logging level is NOTIFICATION.

-invPtrLoc

Alternate Oracle inventory location (UNIX operating systems only).

-help

View all of the command line options.

5.2.3 Sample Commands

Below is an example command that will update the DEV_PORTAL schema in an Oracle database on a UNIX operating system:

./psa -dbType Oracle -dbConnectString '//myOracleDB:1521/orcl.us.oracle.com' -dbaUserName sys -schemaUserName DEV_PORTAL

Below is an example command that will update the DEV2_ODS schema in an Oracle database on a UNIX operating system:

./psa -dbType Oracle -dbConnectString '//myOracleDB:1522/orcl2.us.oracle.com' -dbaUserName sys -schemaUserName DEV2_ODS

Below is an example command that will update the DEV_SOAINFRA schema in a Microsoft SQL Server database on a Windows operating system:

psa.bat -dbType Microsoft -dbConnectString '//mySQLDB:1433;DatabaseName=MyDatabase' -dbaUserName sa -schemaUserName DEV_SOAINFRA

5.2.4 Verifying the Update

You can use the SQL command below to verify that the schema version in schema_version_registry has been properly updated:

SELECT version, status FROM schema_version_registry WHERE owner='schema_name';

Replace schema_name with the value supplied in the -schemaUserName parameter from the command line. The version number should appear as "11.1.1.3.0" and the status should appear as "VALID."

For Oracle databases, if there are any objects that appear as "INVALID," be sure to recompile database objects after running the Patch Set Assistant by connecting to the database as SYS and running the following from SQL*Plus:

SQL> @?/rdbms/admin/utlrp.sql

This will compile the database objects that were updated by Patch Set Assistant.

Then issue to following query to ensure there are no longer any invalid database objects:

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

None of the database objects for the updated schema should be invalid at this point.

5.3 Patch Set Assistant Log Files

The Patch Set Assistant writes log files to the following locations:

On UNIX operating systems:

ORACLE_HOME/upgrade/logs/psatimestamp.log

On Windows operating systems:

ORACLE_HOME\upgrade\logs\psatimestamp.log

Some components will create a second log file called psatimestamp.out, also in the same location.

The timestamp will reflect the actual date and time that Patch Set Assistant was run.

Should any failures occur when running Patch Set Assistant, these log files will be needed to help diagnose and correct the problem; do not delete them. You can alter the contents of your log files by specifying a different -logLevel from the command line.

6 Patching an 11g (11.1.1.2.0) Oracle Identity Management High Availability Environment with 11g (11.1.1.3.0)

This chapter describes how to patch your existing Oracle Identity Management 11.1.1.2.0 high availability environment to 11.1.1.3.0. To do so, complete the following tasks:

See:
Types of Oracle Identity Management Environments in the Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management for information on the topologies.

- Task 1: Stopping Servers and System Components

- Task 2: Updating Oracle WebLogic Server 10.3.2 to Oracle WebLogic Server 10.3.3

- Task 3: Updating the Oracle Identity Management Oracle Home using the Oracle Identity Management Patch Set Installer

- Task 4: Updating the Oracle HTTP Server Oracle Home Using the Oracle Web Tier Patch Set Installer

- Task 5: Updating the Oracle Identity Management Repository using Patch Set Assistant

- Task 6: Starting System Components and Servers

- Task7: Updating the Version Number String Shown in Oracle Enterprise Manager

- Task 8: Updating the Oracle Virtual Directory Version String in the Oracle Directory Service Manager

Note:
Back up your Oracle software, inventory, schema, and domain before applying this patch set, or before making any other changes to your existing Oracle software. Refer to your product administrator's guide for instructions on backing up your Oracle software and inventory. For more information, see the "Advanced Administration: Backup and Recovery" part in the Oracle Fusion Middleware Administrator's Guide.

6.1 Task 1: Stopping Servers and System Components

Before migrating Oracle Identity Management, you must stop the following servers and components:

- Stopping Managed Servers

- Stopping the Administration Server

- Stopping the Node Manager

- Stopping the Oracle Management Agent

- Stopping the System Components

- Special Consideration for Patching OID Replication Environments

6.1.1 Stopping Managed Servers

You must stop the WLS_ODS1 and WLS_ODS2 Managed Servers running on IDMHOST1 and IDMHOST2 by using the Oracle WebLogic Server Administration Console. For more information, see the "Starting and Stopping Oracle Fusion Middleware" section in the Oracle Fusion Middleware Administrator's Guide.

6.1.2 Stopping the Administration Server

You must stop the IDMHOST1 Administration Server, for more information see the "Starting and Stopping Administration Servers" in the Oracle Fusion Middleware Administrator's Guide.

6.1.3 Stopping the Node Manager

Stop the Node Manager running on IDMHOST1 and IDMHOST2 by closing the command shell in which it is running or terminate the Node Manager Process. For example in UNIX, run the command kill -9 pid, where pid is the process id of the Node Manager process.

6.1.4 Stopping the Oracle Management Agent

To stop the Oracle Management Agent running on IDMHOST1 and IDMHOST2, run the following command:

opmnctl stopall

6.1.5 Stopping the System Components

You must stop all system components and processes running on Oracle Internet Directory (running on OIDHOST1 and OIDHOST2), Oracle Virtual Directory (running on OVDHOST1 and OVDHOST2), and Oracle HTTP Server (running on WEBHOST1 and WEBHOST2) by using the opmnctl command-line tool:

opmnctl stopall

6.1.6 Special Consideration for Patching OID Replication Environments

If OID replication was configured in 11.1.1.2.0 then stop the replication server on all the nodes of Directory Replication Group (DRG), patch one node at a time to 11.1.1.3.0 using the Patch Set Installer and restart the replication server after patching all the nodes of DRG.

6.2 Task 2: Updating Oracle WebLogic Server 10.3.2 to Oracle WebLogic Server 10.3.3

If Oracle WebLogic Server is installed in Oracle Identity Management 11.1.1.2.0, then you must migrate the Oracle WebLogic Server from 10.3.2 to 10.3.3 on IDMHOST1, IDMHOST2, OIDHOST1, OIDHOST2, OVDHOST1 and OVDHOST2.

In order to update your WebLogic Server, you must have a My Oracle Support account. There are two ways for you to update your WebLogic Server:

- Use the Smart Update tool. For more information, see "Downloading and Installing Maintenance Packs" in Oracle Smart Update Installing Patches and Maintenance Packs.

- Use the upgrade installers. For more information, see "Downloading an Upgrade Installer From My Oracle Support" in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

6.3 Task 3: Updating the Oracle Identity Management Oracle Home using the Oracle Identity Management Patch Set Installer

You must migrate the Oracle Identity Management ORACLE_HOME from 11.1.1.2.0 to 11.1.1.3.0 on IDMHOST1, IDMHOST2, OIDHOST1, OIDHOST2, OVDHOST1, and OVDHOST2 by using the Patch Set Installer for Oracle Identity Management.

For instructions, see Chapter 4, "Applying the Latest Oracle Fusion Middleware Patch Set".

After the installation is complete, the oracleRoot.sh confirmation dialog box is displayed. This dialog box advises you to run configuration scrip as root before the installation can proceed. Leaving the confirmation dialog box open, open another shell window, log in as root, and run the oracleRoot.sh script file.

Note:
If upgrade of your existing 10g Release 2 (10.1.2) or 10g (10.1.4) Oracle Identity Management to Oracle Identity Management 11g was performed to create an 11.1.1.2.0 Oracle home, then you must also run the oidRoot.sh script.

After the script completes, click OK on the Confirmation Dialog box.

6.4 Task 4: Updating the Oracle HTTP Server Oracle Home Using the Oracle Web Tier Patch Set Installer

If Oracle HTTP Server is configured in the ORACLE_INSTANCE, then you must migrate the Oracle HTTP Server ORACLE_HOME from 11.1.1.2.0 to 11.1.1.3.0 on WEBHOST1 and WEBHOST2 by using the Patch Set Installer for Oracle Web Tier.

For instructions, see Chapter 4, "Applying the Latest Oracle Fusion Middleware Patch Set".

6.5 Task 5: Updating the Oracle Identity Management Repository using Patch Set Assistant

You must run Patch Set Assistant to update the database schema for Oracle Internet Directory 11.1.1.2.0 to 11.1.1.3.0. Patch Set Assistant performs an in-place schema update on an existing 11.1.1.2.0 schema.

For instructions, see Chapter 5, "Updating Your Schemas with Patch Set Assistant".

Note:
You must update the schema once for the entire topology.

6.6 Task 6: Starting System Components and Servers

You must start the following:

- Starting System Components

- Starting Node Manager

- Starting the Oracle WebLogic Administration Server

- Starting the Managed Server

- Starting Oracle Management Agent

6.6.1 Starting System Components

You must start the following system components:

- Starting Oracle Internet Directory Processes

- Starting Oracle Virtual Directory Processes

- Starting Oracle HTTP Server

Note:
If you have not started OPMN, then you must start OPMN by running the following command:

opmnctl start

6.6.1.1 Starting Oracle Internet Directory Processes

To start the Oracle Internet Directory processes, use the following OPMN command:

opmnctl startproc ias-component=oid_component_name

To verify that the Oracle Internet Directory Instances have started, run the following opmnctl status command:

opmnctl status

Example:

Processes in Instance: oid_inst1---------------------------------+--------------------+---------+---------ias-component                    | process-type       |     pid | status---------------------------------+--------------------+---------+---------oid1                             | oidldapd           |   31522 | Aliveoid1                             | oidldapd           |   31520 | Aliveoid1                             | oidmon             |   31449 | AliveEMAGENT                          | EMAGENT            |   31448 | Alive

6.6.1.2 Starting Oracle Virtual Directory Processes

To start the Oracle Virtual Directory processes, use the following OPMN command:

opmnctl startproc ias-component=<ovd_component_name>

To verify that the Oracle Virtual Directory Instances have started, run the following opmnctl status command:

opmnctl status

Example:

[abcd@strasha11 bin]$ /u01/app/oracle/ps1/admin/ovd_inst1/bin/opmnctl status

Processes in Instance: ovd_inst1
---------------------------------+--------------------+---------+---------
ias-component                    | process-type       |     pid | status
---------------------------------+--------------------+---------+---------
ovd1                             | OVD                |   31658 | Alive
EMAGENT                          | EMAGENT            |   31657 | Alive

6.6.1.3 Starting Oracle HTTP Server

If Oracle HTTP Server is configured in the ORACLE_INSTANCE, then start it using the following command:

opmnctl startproc ias-component=ohs_component_name

To verify that the Oracle HTTP Server instances have started, run the following OPMN command:

opmnctl status

Example:

[abcd@stajz13 Disk1]$ /u01/app/oracle/ps1/admin/ohs_inst1/bin/opmnctl status

Processes in Instance: ohs_inst1
---------------------------------+--------------------+---------+---------
ias-component                    | process-type       |     pid | status
---------------------------------+--------------------+---------+---------
ohs1                             | OHS                |    7144 | Alive

6.6.2 Starting Node Manager

You must start Node Manager, running on IDMHOST1 and IDMHOST2, by using the startNodeManager.sh script (UNIX, located at WL_HOME/server/bin directory) or startNodeManager.cmd script (Windows, located at WL_HOME\server\bin directory) as follows:

On UNIX operating systems:

MW_HOME/wl_server_n/server/bin/startNodeManager.sh

On Windows operating systems:

MW_HOME\wl_server_n\server\bin\startNodeManager.cmd

6.6.3 Starting the Oracle WebLogic Administration Server

You must start the IDMHOST1 Administration Server by running the following command:

On UNIX operating systems:

MW_HOME/user_projects/domains/domain_name/bin/startWebLogic.sh         -Dweblogic.management.username=weblogic         -Dweblogic.management.password=password         -Dweblogic.system.StoreBootIdentity=true

On Windows operating systems:

MW_HOME\user_projects\domains\domain_name\bin\startWebLogic.cmd         -Dweblogic.management.username=weblogic         -Dweblogic.management.password=password         -Dweblogic.system.StoreBootIdentity=true

6.6.4 Starting the Managed Server

You must start Node Manager, running on IDMHOST1 and IDMHOST2. For more information see "Starting and Stopping Managed Servers Using Fusion Middleware Control" in Oracle Fusion Middleware Administrator's Guide.

6.6.5 Starting Oracle Management Agent

To start the Oracle Management Agent for the Oracle WebLogic Server running on IDMHOST1 and IDMHOST2, use the following OPMN command:

opmnctl startproc ias-component=EMAGENT

To verify that the Oracle Management Agent Instances have started, run the following opmnctl status command:

opmnctl status

Example:

Processes in Instance: wls_ods1---------------------------------+--------------------+---------+---------ias-component                    | process-type       |     pid | status---------------------------------+--------------------+---------+---------EMAGENT                          | EMAGENT            |   10971 | Alive

6.7 Task7: Updating the Version Number String Shown in Oracle Enterprise Manager

If you are using Oracle Internet Directory or Oracle Virtual Directory components from 11.1.1.2.0 and you have patched those components to11.1.1.3.0, you must use the opmnctl updatecomponentregistration command to manually update the version number string that is shown in Oracle Enterprise Manager.

For instructions, see Section 4.6.1.2, "Upgrading the Version Number String Shown in Oracle Enterprise Manager".

6.8 Task 8: Updating the Oracle Virtual Directory Version String in the Oracle Directory Service Manager

To update the Oracle Virtual Directory version string in the Oracle Directory Service Manager, follow the instructions in Section 4.7.2, "Updating the Oracle Virtual Directory Version Number in Oracle Directory Service Manager".

7 Patching Oracle Enterprise Content Management 11g (11.1.1.2.0) with 11g (11.1.1.3.0)

This chapter is for Oracle Enterprise Content Management Suite users who installed and configured Oracle Enterprise Content Management Suite 11g (11.1.1.2.0). It describes how to update your installation to the new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0).

This chapter contains the following sections:

- Differences Between Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) and 11g (11.1.1.3.0)

- Starting Points for the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

- Summary of the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

7.1 Differences Between Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) and 11g (11.1.1.3.0)

Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) included the following Oracle Enterprise Content Management Suite components:

- Oracle Imaging and Process Management 11g (11.1.1.2.0)

- Oracle Information Rights Management 11g (11.1.1.2.0)

Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) includes the following components:

- Oracle Imaging and Process Management 11g (11.1.1.3.0)

- Oracle Information Rights Management 11g (11.1.1.3.0)

- Oracle Universal Content Management 11g (11.1.1.3.0)

- Oracle Universal Records Management 11g (11.1.1.3.0)

- Oracle Inbound Refinery 11g (11.1.1.3.0)

7.2 Starting Points for the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

The procedures described in this chapter assume you are starting from the following Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) configuration:

- You have installed Oracle Imaging and Process Management (Oracle I/PM) and Oracle Information Rights Management (Oracle IRM) 11g (11.1.1.2.0) in a single Oracle WebLogic Server domain.

- You have optionally installed Oracle SOA Suite 11g (11.1.1.2.0) in a separate Oracle WebLogic Server domain.

- You have optionally configured Oracle Imaging and Process Management to use an existing Oracle Universal Content Management 10g repository.

7.3 Summary of the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

Table 7-1 provides an overview of the procedure for updating your Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) environment.

Table 7-1 Summary of the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Update Procedure

Step #

Step

Section

1

Perform the required prerequisite tasks.

Section 7.3.1, "Before You Begin Updating Your Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) Environment"

2

Install Oracle WebLogic Server 11g (11.1.1.3.0) and create a new Middleware home.

"Installing Oracle WebLogic Server in a Middleware Home" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite

3

Install Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) in the Middleware home.

"Installing Oracle Enterprise Content Management Suite in Oracle Fusion Middleware" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite

4

Configure Oracle I/PM and Oracle IRM 11g (11.1.1.3.0) in a new Oracle Enterprise Content Management Suite domain.

Optionally, configure Oracle UCM and Oracle URM 11g (11.1.1.3.0) in the same domain.

Section 7.3.2, "Configuring the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Domain"

5

Perform the steps to move configuration settings from Oracle I/PM 11g (11.1.1.2.0) to Oracle I/PM 11g (11.1.1.3.0).

Section 7.3.3, "Moving Configuration Information from Oracle I/PM 11g (11.1.1.2.0) to 11g (11.1.1.3.0)"

6

Perform the steps to move configuration settings from Oracle IRM 11g (11.1.1.2.0) to Oracle IRM 11g (11.1.1.3.0)

Section 7.3.4, "Moving Configuration Information from Oracle IRM 11g (11.1.1.2.0) to 11g (11.1.1.3.0)"

7.3.1 Before You Begin Updating Your Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) Environment

Before you start the upgrade process, be sure to review the following important prerequisites:

- Stopping the Input Agents in the 11g (11.1.1.2.0) Environment

- Ensuring That All Active Processes Have Completed

7.3.1.1 Stopping the Input Agents in the 11g (11.1.1.2.0) Environment

To stop the Oracle I/PM Input Agents:

1. Log in to the Oracle Enterprise Manager Fusion Middleware Control for the 11g (11.1.1.2.0) domain.

2. From the navigation pane, expand the farm, then expand WebLogic Domain.

3. Expand the Oracle Enterprise Content Management Suite domain and select the Oracle I/PM managed server (called IPM_server1 by default).

4. From the WebLogic Server menu, select System MBean Browser.

5. In the MBean browser, navigate to oracle.imaging/Server:IPM_server1/config/config.

6. Delete the userid in the AgentUserproperty.

7.3.1.2 Ensuring That All Active Processes Have Completed

To ensure that all active processes have completed, you can use Oracle WebLogic Server Administration Console to monitor the processes and identify when they are all complete:

1. Log in to the Oracle WebLogic Server Administration Console for the 11g (11.1.1.2.0) domain.

2. Navigate to the JMS Servers page for the domain (Services > Messaging > JMS Servers).

3. Select the Monitoring tab.

4. Periodically refresh the display until the Messages Current and Messages Pending values have dropped to zero (0).

7.3.2 Configuring the Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Domain

To configure the new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) domain, use the instructions in the chapter, "Configuring Oracle Enterprise Content Management Suite" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

However, be sure to note the following as you enter information on each screen of the Oracle Fusion Middleware Configuration Wizard:

- When you enter a name for the WebLogic Server administrator; be sure to use the same name that you used when configuring Oracle I/PM and Oracle IRM11g (11.1.1.2.0).

- When you enter the information required to connect to the Oracle I/PM and Oracle IRM database connections, use the same connection information you used when configuring Oracle I/PM 11g (11.1.1.2.0).

- When configuring the administration server, managed servers, cluster, and node managers, use the same settings that you used when you configured Oracle I/PM and Oracle IRM 11g (11.1.1.2.0). You can change the physical identifiers, if necessary, but not the other configuration settings.
In particular, be sure to use the same Oracle I/PM port to maintain the integrity of the document URLs.

7.3.3 Moving Configuration Information from Oracle I/PM 11g (11.1.1.2.0) to 11g (11.1.1.3.0)

The following sections describe the steps you must perform to move your Oracle I/PM 11g (11.1.1.2.0) configuration information to the new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) domain:

- Task 1: Start the Administration Server and Node Manager in the New Domain

- Task 2: Update the Security Settings in the New Domain

- Task 3: Configure the Credentials and Create a Workflow Connection for the New Domain

- Task 4: Configure the Policy Stores in the New Domain

- Task 5: Update the Input Agent Directories in the New Domain

- Task 6: Update the Oracle I/PM Configuration Settings in the New Domain

- Task 7: Configure Oracle UCM for the New Oracle I/PM Instance

- Task 8: Upgrade Oracle UCM 10g to Oracle UCM 11g

- Task 9: Verify Any Oracle I/PM Integrations

7.3.3.1 Task 1: Start the Administration Server and Node Manager in the New Domain

To start the Administration Server and the node manager for the new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) domain, refer to the following sections of the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite:

- Starting the Administration Server

- Starting Node Manager

7.3.3.2 Task 2: Update the Security Settings in the New Domain

The procedure for updating the security settings in your new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) domain vary, depending on whether you are using the default Oracle WebLogic Server security provider or an external LDAP provider.

If you are using an external LDAP provider, see "Reassociating the Identity Store with an External LDAP Authentication Provider" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite for information on associating the new domain with your existing external LDAP provider.

If you are using the default Oracle WebLogic Server security provider, use the instructions see "Configure the embedded LDAP server" in the Oracle WebLogic Server Administration Console online help, and add the following accounts that are currently defined in the Oracle I/PM 11g (11.1.1.2.0) domain:

- The Oracle I/PM administrator account. This is the user that first signed in to the Oracle I/PM 11g (11.1.1.2.0) system after it was installed.

- At least one user or group corresponding to the users or groups that have the grant access document permission within each Application.

After entering all of the required users and groups in the embedded LDAP server, run the following WLST commands:

1. Change directory to the ORACLE_HOME/common/bin directory.

2. Start the Weblogic Scripting Tool (WLST):
For example, on a UNIX operating system, enter ./wlst.sh.

3. Enter the following WLST command:

connect('AdminUser', 'AdminUser_Password', 't3://localhost:16000')

4. Enter the following WLST command:

refreshIPMSecurity()

Note:
User preferences for local users are not retained. Users will need to reconfigure their settings. Preferences are retained for users in external provider.

7.3.3.3 Task 3: Configure the Credentials and Create a Workflow Connection for the New Domain

If you configured Oracle I/PM 11g (11.1.1.2.0) with an Oracle BPEL server, note that the workflow connection information is stored in the Oracle I/PM database. As a result, if you configured your new Oracle I/PM environment to use the same database, then these connections will work as they did in the original environment.

However, before Oracle I/PM can connect to the workflow server, you must configure your new Oracle I/PM installation with the required credentials.

For more information, see "Configuring a Workflow Connection CSF Credential" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

7.3.3.4 Task 4: Configure the Policy Stores in the New Domain

Oracle Web Services Manager policies are configured using Oracle WebLogic Server deployment plans. If the Oracle I/PM 11g (11.1.1.2.0) environment was configured to use deployment plans to apply policies to the Web services, then you must apply the same policies to the new 11g (11.1.1.3.0) environment.

The steps you take depend on how the Oracle I/PM application was deployed.

- If the Oracle I/PM application was deployed with only the default policies, then no further action is necessary, because the default policies were set up by the installation in the new environment.

- If the Oracle I/PM application was deployed using one of the deployment plans packaged with Oracle I/PM, you must perform the same tasks you performed when deploying the application in the original environment.
For more information, see "Setting Policies on Services" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

- If the Oracle I/PM application was deployed using a custom set of policies, you must move the policies to the new environment, using the following steps:
Copy the Plan.xml file that was created in the original environment, along with its associated directories, to the same location in the new environment.

Update the Oracle I/PM application deployment to use this deployment plan, as described in the section, "Setting Policies on Services" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

7.3.3.5 Task 5: Update the Input Agent Directories in the New Domain

When you are updating your configuration to use a new Oracle I/PM 11g (11.1.1.3.0) environment, you must ensure that the input directories used by the Input Agent are properly configured for the new environment.

During the installation of Oracle I/PM 11g (11.1.1.2.0), the default input directory used by the Input Agent is set to the following local file path:

MW_HOME/user_projects/domains/domain_name/IPM/InputAgent/Input

This location is usually used for simpler, single-computer installations; however, you can also change it to an external location to better facilitate sharing by clustered Oracle I/PM instances and to simplify input file placement from external scanning solutions.

Depending upon whether or not you changed the default location in 11g (11.1.1.2.0), note the following:

- If you configured Oracle I/PM 11g (11.1.1.2.0) to use a custom, central location for the input directories, then that location will be preserved for the new 11g (11.1.1.3.0) instance, as long as you configured Oracle I/PM 11g (11.1.1.3.0) to use the same Oracle I/PM database. This is because the input directories location is stored with the other Oracle I/PM configuration settings in the Oracle I/PM database.
Note that if some aspect of that path has changed as part of the update to 11g (11.1.1.3.0), then you must update the InputDirectories property of the Imaging config MBean, accordingly. For more information, see "Configuring MBeans" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

- If you did not change the Oracle I/PM 11g (11.1.1.2.0) default input directory configuration, then you must move any unfinished input activity to the new 11g (11.1.1.3.0) Middleware home.
To do this, copy the entire Input directory from the Oracle Enterprise Content Management Suite 11g (11.1.1.2.0) Middleware home to the same location in the new 11g (11.1.1.3.0) Middleware home. You can find the default directory and all of its subdirectories in the following location of the 11g (11.1.1.2.0) Middleware home:

MW_HOME/user_projects/domains/domain_name/IPM/InputAgent/Input

Note that input files often reference document images to be ingested, using a file path. These path references must remain valid after the update to 11g (11.1.1.3.0). For example, if any of the document references include host names, or other physical identities that might change, you must update those references in the input files.

7.3.3.6 Task 6: Update the Oracle I/PM Configuration Settings in the New Domain

The Oracle I/PM Mbean configuration settings are preserved within the Oracle I/PM database. As a result, as long as the new 11g (11.1.1.3.0) environment has been configured to connect to the same Oracle I/PM database, then the same configuration will be available when the new environment is started.

However, you should review your MBean configuration settings to verify that they are still correct after the upgrade. If any MBean values need to be changed, see "Configuring MBeans" in the Oracle Fusion Middleware Administrator's Guide for Oracle Imaging and Process Management.

On the new system, set the Listen address for the managed server that contains Oracle Application Extension Framework (AXF):

1. Log in to the Oracle WebLogic Server Administration Console for the new 11g (11.1.1.3.0) domain.

2. Navigate to the Oracle I/PM managed server (Environment > Servers > ipm_server1)

3. In the Listen Address field, enter the same name as you used for the original 11g (11.1.1.2.0) Oracle I/PM server. For example, enter the fully qualified domain name or the load balancer name.

4. Restart the Oracle I/PM managed server.

7.3.3.7 Task 7: Configure Oracle UCM for the New Oracle I/PM Instance

If you configured Oracle I/PM 11g (11.1.1.2.0) with an Oracle Universal Content Management 10g instance, then note that the Oracle UCM connection information is stored in the Oracle I/PM database. As a result, if you configured your new Oracle I/PM environment to use the same database, then these connections will work as they did in the original environment.

However, you must update Oracle UCM with information about the new Oracle I/PM 11g (11.1.1.3.0) instance:

1. In a Web browser, log in to the Oracle UCM 10g Web client as a system administrator.

2. Disable the Oracle I/PM 11g (11.1.1.2.0) repository component:

1. Under Administration, select Admin Server.

2. Click idc.

3. Select Component Manager from the navigation panel.

4. Select IpmRepository from the enabled components list and disable it.

3. Navigate to the Start/Stop Server page and restart the Content Server.

4. Uninstall the Oracle I/PM 11g (11.1.1.2.0) repository component:

1. Navigate back to the Component Manager page.

2. Select the IpmRepository component and select Uninstall.

3. Click OK and return to Component Manager page.

5. Install and enable the new Oracle I/PM 11g (11.1.1.3.0) repository component:

1. Click Browse and navigate to the following directory in the new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) Middleware home:

ECM_ORACLE_HOME/ipm/lib

2. Select the IpmRepository.zip file, and then click Install.

3. Click Continue.

4. Select the option to enable the component.

6. Navigate to the Start/Stop Server page and restart the Content Server.

7. Verify that Oracle I/PM 11g (11.1.1.3.0) is connected successfully to the Oracle UCM 10g instance.

7.3.3.8 Task 8: Upgrade Oracle UCM 10g to Oracle UCM 11g

After you have verified that Oracle I/PM 11g (11.1.1.3.0) is connected successfully to your existing Oracle UCM 10g installation, you can then upgrade Oracle UCM 10g to Oracle UCM 11g (11.1.1.3.0).

For complete information about upgrading to Oracle UCM 11g (11.1.1.3.0), see the Oracle Fusion Middleware Upgrade Guide for Oracle Enterprise Content Management Suite.

7.3.3.9 Task 9: Verify Any Oracle I/PM Integrations

Oracle I/PM 11g (11.1.1.3.0) introduces minor changes to the Oracle I/PM application programming interface (API). As a result, you should verify that your Oracle I/PM applications work successfully with the new API.

For more information, see Oracle Fusion Middleware Oracle Imaging and Process Management Java API Reference.

7.3.4 Moving Configuration Information from Oracle IRM 11g (11.1.1.2.0) to 11g (11.1.1.3.0)

The following sections describe the steps you must perform to move your Oracle IRM 11g (11.1.1.2.0) configuration information to the new Oracle Enterprise Content Management Suite 11g (11.1.1.3.0) domain:

- Task 1: Move the Oracle IRM Configuration File to the New Domain

- Task 2: Copy Oracle IRM Key Store to the New Domain

- Task 3: Copy the Oracle IRM Key Store Credentials to the New Domain

7.3.4.1 Task 1: Move the Oracle IRM Configuration File to the New Domain

To move your Oracle IRM configuration settings from the 11g (11.1.1.2.0) domain to the new 11g (11.1.1.3.0) domain:

1. Locate the XML file that contains the Oracle IRM configuration settings in the 11g (11.1.1.2.0) domain.
The file is called irm-config.xml and it is located in the following directory inside the domain home:

DOMAIN_HOME/config/fmwconfig/irm-config.xml

2. Copy the Oracle IRM 11g (11.1.1.2.0) irm-config.xml file to the same location in the new 11g (11.1.1.3.0) domain home:

DOMAIN_HOME/config/fmwconfig/irm-config.xml

7.3.4.2 Task 2: Copy Oracle IRM Key Store to the New Domain

To copy the Oracle IRM 11g (11.1.1.2.0) key store to the new 11g (11.1.1.3.0) domain:

1. Locate the Oracle IRM 11g (11.1.1.2.0) key store file.
The Oracle IRM 11g (11.1.1.2.0) installation instructions suggest that you store the key store in the following location in the domain home; however, it can actually be stored in any location on the Oracle IRM host:

DOMAIN_HOME/config/fmwconfig/

The name of the file is usually irm.jks or irm.jceks, but there are no restrictions on the naming of the file.

You can find the exact location and file name of the key store in one of two ways:

- In Oracle Enterprise Manager Fusion Middleware Control, navigate to the IRM home page and select Administration > General Settings from the IRM menu.

- Use the getIRMKeyStore() WebLogic Scripting Tool (WLST) command. For more information, see "getIRMKeyStore" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

2. Copy the key store file to the equivalent location in the Oracle IRM 11g (11.1.1.3.0) domain.

7.3.4.3 Task 3: Copy the Oracle IRM Key Store Credentials to the New Domain

To copy the Oracle IRM key store credentials to the Oracle IRM 11g (11.1.1.3.0) domain:

1. Verify that the Administration server in the Oracle IRM 11g (11.1.1.3.0) domain is up and running.

2. Change directory to the following location in the Oracle IRM 11g (11.1.1.3.0) domain:

MW_HOME/Oracle_ECM1/common/bin

3. Start the WLST shell, connect to the Administration server, and use the createCred command to configure the credentials in the new Oracle IRM 11g (11.1.1.3.0) domain.
For example:

connect("weblogic", "welcome1", "adminserver.example.com:7001")
createCred("IRM", "keystore:irm.jceks", "user", "password")
createCred("IRM", "key:irm.jceks:oracle.irm.wrap", "user", "password")

In the previous example:

- Replace irm.jceks with the actual name of the Oracle IRM key store.

- Replace user and password with the key store username and password.

For more information, see:

- "createCred" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference

- "Adding Key Store Passwords to the Credential Store" in the Oracle Fusion Middleware Installation Guide for Oracle Enterprise Content Management Suite.

A Patch Set Installer Screens

This appendix contains screenshots and descriptions for the Patch Set Installer screens:

Note:
There are separate Patch Set Installers for each Fusion Middleware product. The screens in this appendix are from the Oracle SOA Suite Patch Set Installer.
The Specify Security Updates Screen screenshot is from the Web Tier Patch Installer.

- Welcome Screen

- Specify Installation Location Screen

- Specify Security Updates Screen

- Installation Summary Screen

- Installation Progress Screen

- Installation Complete Screen

A.1 Welcome Screen

The Welcome screen is displayed each time you start the installer.

A.2 Specify Installation Location Screen

In the Oracle Middleware Home field, specify the absolute path to your existing Oracle Middleware Home directory; this is the directory that was created when you installed Oracle WebLogic Server. If you do not know the full path to your Middleware Home, you can click Browse to select an existing directory in your system.

In the Oracle Home Directory field, specify the existing product Oracle home directory inside the Oracle Middleware Home. This is the directory that will be patched with this installation.

Note:
If you are performing an installation on a Windows operating system, be sure that your directory paths are valid and do not contain double backslashes (\\).

If you specify an Oracle home directory that does not contain the same product you are patching (for example, you are running the Patch Set Installer for Oracle SOA Suite but you have specified an Oracle home that contains Oracle Web Tier), you will receive a warning message but will be allowed to continue if you choose. In such cases, only the oracle_common directory and any components which the two products have in common are patched.

Note:
If you specify an Oracle home directory that has already been patched, then you will receive a warning message and the installation will not continue. Re-patching an Oracle home is not supported.

A.3 Specify Security Updates Screen

If you are running the Patch Set Installer for Oracle Web Tier, Oracle Identity Manager, or Oracle Portal, Forms, Reports and Discoverer, and you did not already register for security updates in your previous installation, you will see this screen.

Enter your E-mail address if you want to receive the latest product information and security updates. If you have a My Oracle account and wish to receive updates via this mechanism, select I wish to receive security updates via My Oracle Support, then enter your account password.

If you do not wish to register for security updates, leave all the fields on this screen blank. You will be prompted to confirm your selection with the following screen:

Click Yes to confirm that you do not want to register for any security updates.

A.4 Installation Summary Screen

Review the information on this screen, and click Install to begin the installation. The operations summarized on this page will be performed when you click Install.

If you want to make any changes to the configuration before starting the installation, use the navigation pane and select the topic you want to edit.

If you want to save this configuration to a text file, click Save. This file can be used later if you choose to perform the same installation from the command line.

For more information about silent installation, refer to Oracle Fusion Middleware Installation Planning Guide.

A.5 Installation Progress Screen

This screen shows you the progress of the installation.

If you want to quit before the installation is completed, click Cancel. Doing so will result in a partial installation; the portion of the software that was installed on your system before you click Cancel will remain on your system, and you will have to remove it manually.

A.6 Installation Complete Screen

This screen summarizes the installation that was just completed.

If you want to save this summary information to a text file for future reference, click Save.

B Sample Patch Master Properties File

This appendix shows a sample patchMaster.properties file.

# This is the property file for the 11gR1-11ps1 patchMaster.
# Set values for the properties below to the desired value.
# If a property is not needed, it must be commented out.

# Description: List of components to patch from 11gR1 to 11ps1
# Example: patchMaster.Componentlist=Audit,BAM,DIP,Discoverer,Discussions,Forms,JPS,JRF,MDS,Modplsql,OAM,OCServer,ODL,ODSM,OHS,OID,OIF,Opmn,OVD,OWSM,Portal,Portlet,Reports,SOA,UMS,WebCenter,Webcache,Webservices,Wiki
patchMaster.Componentlist=Audit,BAM,DIP,Discoverer,Discussions,Forms,JPS,JRF,MDS,Modplsql,OAM,OCServer,ODL,ODSM,OHS,OID,OIF,Opmn,OVD,OWSM,Portal,Portlet,Reports,SOA,UMS,WebCenter,Webcache,Webservices,Wiki

# Description: Connection string to a single repository being patched.
# Example: patchMaster.Schemaurl=jdbc:oracle:thin:@localhost:1521:orcl
patchMaster.Schemaurl=jdbc:oracle:thin:@<host>:<port>:<sid>

# Description: A system user for the repository specified by patchMaster.Schemaurl
# Example: patchMaster.Schemauser=SYS AS SYSDBA
# patchMaster.Schemauser=<Value Unspecified>

# Description: The optional repository schema metadata namespace.
# Example: patchMaster.Schemaprefix=DEV
# patchMaster.Schemaprefix=<Value Unspecified>

# Description: Fusion Middleware 11ps1 home.
# Example: patchMaster.Mwhomenew=/scratch/newhome
# patchMaster.Mwhomenew=<Value Unspecified>

# Description: Fusion Middleware 11gR1 home.
# Example: patchMaster.Mwhomeold=/scratch/oldhome
# patchMaster.Mwhomeold=<Value Unspecified>

# Description: WLS domain 11ps1 home.
# Example: patchMaster.Domainhomenew=/scratch/newhome/user_projects/domains/newDomain
# patchMaster.Domainhomenew=<Value Unspecified>

# Description: WLS domain applications 11ps1 home.
# Example: patchMaster.Domainapplicationshomenew=/scratch/newhome/user_projects/applications/newDomain
# patchMaster.Domainapplicationshomenew=<Value Unspecified>

# Description:  WLS domain 11gR1 home.
# Example: patchMaster.Domainhomeold=/scratch/oldhome/user_projects/domains/oldDomain
# patchMaster.Domainhomeold=<Value Unspecified>

# Description: WLS domain username.
# Example: patchMaster.Domainusername=currentuser
# patchMaster.Domainusername=<Value Unspecified>

# Description: List paths to 11ps1 Oracle instances.
# Example: patchMaster.Oracleinstancenewlist=/scratch/newinst1,/scratch/newinst2
# patchMaster.Oracleinstancenewlist=<Value Unspecified>

# Description: List paths to 11gR1 Oracle instances corresponding to 11ps1 Oracle instance paths.
# Example: patchMaster.Oracleinstanceoldlist=/scratch/oldinst1,/scratch/oldinst2
# patchMaster.Oracleinstanceoldlist=<Value Unspecified>

# Description: Path to 11ps1 Oracle home.
# Example: patchMaster.Oraclehomenew=/scratch/mynewOhome
# patchMaster.Oraclehomenew=<Value Unspecified>

# Description: Path to 11gR1 Oracle home.
# Example: patchMaster.Oraclehomeold=/scratch/myOhome
# patchMaster.Oraclehomeold=<Value Unspecified>

# Description: Specifies the directory where the log files go if a custom
#              location is desired.
# Example: patchMaster.Logdir=/scratch/patchMasterDir
# patchMaster.Logdir=<Value Unspecified>

# Description: Specifies the logging level to be recorded in the log file
# Values={error|warning|info|verbose|debug}  Default=info
patchMaster.Loglevel=info

# Description: WLS domain Adminserver hostname.  This is *either* the R1 or PS1 Adminserver host
# depending the operation.  Used for start/stop domain and instance registration.
# Example: patchMaster.Domainadminhost=localhost
# patchMaster.Domainadminhost=<Value Unspecified>

# Description: WLS domain Adminserver port number.  This is *either* the R1 or PS1 Adminserver port
# depending the operation.  Used for start/stop domain and instance registration.
# Example: patchMaster.Domainadminport=7001
# patchMaster.Domainadminport=<Value Unspecified>

C Migrating the Oracle Portal Schema Located in a Customer Database

This appendix details the steps for upgrading a portal schema residing in a customer database configuration outside the Oracle Metadata Repository. To upgrade the portal schema residing in a customer database, you must use the upgrade.bat (on Windows operating systems) or upgrade (on UNIX operating systems) script. Perform the following steps to upgrade the portal schema residing in a customer database:

1. Set the ORACLE_HOME environment variable to the Oracle home of the middle tier.

2. Add the Transparent Network Services (TNS) entry of the database containing portal schema to ORACLE_INSTANCE\config (on Windows operating systems) or ORACLE_INSTANCE/config (on UNIX operating systems).

3. On UNIX operating systems, set the TNS_ADMIN environment variable to the following location: ORACLE_INSTANCE/config.

4. Ensure that you are able to connect to database using the Portal schema.

5. Verify if you can connect to the Portal schema in the database Oracle home by specifying the schema password and the TNS name using SQL*Plus.
For example on UNIX operating systems:

sqlplus portal/portal@orcl

6. Change the directory to ORACLE_HOME/upgrade/portal/admin/plsql (on UNIX operating systems).

7. Stop all Oracle Fusion middleware services in the middle-tier Oracle homes that are associated with the portal schema being migrated. For this, stop WLS_PORTAL through the Oracle WebLogic Server Administration Console, and run ORACLE_INSTANCE/bin/opmnctl stopall (on UNIX operating systems).

8. Verify that Oracle Internet Directory associated with the portal schema is up and running.

9. Run the upgrade script in precheck mode.
On UNIX operating systems, run the script as follows:

ORACLE_HOME/upgrade/portal/admin/plsql/upgrade -precheck

When -precheck is specified, only the pre-upgrade checks are done and the upgrade exits after that. In this mode, the upgrade is not immediately terminated if a precheck fails. Instead, the errors for all prechecks are consolidated in the upgrade.log file. This file is generated in the ORACLE_HOME/upgrade/portal/admin/plsql (on UNIX operating systems) directory. Look at the end of the log file to see a list of checks that failed. Run the upgrade in this mode until none of the prechecks fails. In this mode, the schema is not altered, so restoring from your backup is not necessary between runs.

Look up any errors found in the precheck log file. Contact Oracle Support Services for any errors that are not documented or that cannot be resolved by following documented actions.

10. After resolving all warnings and errors from the precheck.log file, run the upgrade script without any parameters.
On UNIX operating systems, run the script as follows:

ORACLE_HOME/upgrade/portal/admin/plsql/upgrade

The script prompts you for information about the system setup. Your answers are echoed for verification at the end of the script. However, if you discover that you have entered incorrect information before the end of the script, then you can exit before any changes are made by answering n to the last script inquiry.

The following are the questions from the script. Default answers to the questions are given in brackets.

- Have you backed up your database (y|n)? [y]:
If you have not backed up the database, then answer n, back up the database, and restart the script. If you have backed up the database, then answer y.

- Enter the name of the schema you would like to upgrade [portal]:
If the schema name is different from the default Oracle Infrastructure installation schema name of Portal, then enter the schema name.

- Enter the password of the schema you would like to upgrade [portal]:
If the password is not the same as the schema name, then enter the portal schema password.

- Enter the password for the SYS user of your database [change_on_install]:
If the password is not change_on_install, then enter the database SYS password.

- Enter the TNS connect string to connect to the database [orcl]:
Provide the TNS connect string. This can be found in the ORACLE_INSTANCE/config/tnsnames.ora file (on UNIX operating systems).

11. When the script is complete, examine the upgrade log files in the current directory to make sure there are no errors reported at the end.

12. Now start the middle tiers associated with this repository. Check that Oracle Portal is accessible.

Index
A  D  E  H  I  L  M  N  O  P  R  S  T  U  V  W

A

accessibility, Preface

aq_tm_processes value for Oracle Portal schema, 5.1.3

D

documentation accessibility, Preface

E

environment variables for OPatch, 2.2.3

H

high availability

Oracle Identity Management

upgrading from Release 11.1.1.2.0 to Release 11.1.1.3.0, 6

I

installation

definition of, 1.1.4

L

listen address

how to set, 2.5.2.2

log files for Patch Set Assistant, 5.3

M

machine name

how to set, 2.5.2.2

Middleware Home

specifying location of, A.2

migrating from Release 11.1.1.1.0 to Release 11.1.1.2.0, 3.3 migrating the Oracle Portal schema that resides in a customer database, C migration

definition of, 1.1.2

migration process, 3.3 My Oracle Support, A.3

N

Node Manager

setting the StartScriptEnabled property, 2.5.2.1

O

obtaining patches, 2.2.2

OID replication

special considerations for upgrading, 6.1.6

OPatch, 1.2

-auto option, 2.4.1.2

commands, 2.4

environment variables, 2.2.3

property file, 2.4.1.1

running, 2.4

troubleshooting, 2.5

types of patches that can be used with OPatch, 2.1.1

where to obtain, 2.2.1

where to obtain patches, 2.2.2

opmnctl updatecomponentregistration command, 6.7 Oracle Fusion Middleware, Preface Oracle Home

specifying location of, A.2

Oracle Identity Management

upgrading in a high availability environment, 6

Oracle Portal schema

migrating, C

Oracle SOA Suite

verifying the installation, 4.9

Oracle WebLogic Server

patching, 4.2.1.3

P

Patch Assistant, 3.2

patch set

definition of, 3.1

Patch Set Assistant, 1.2, 4.5, 5, 6.5

command line syntax, 5.2.2

components with schemas that need to be patched, 5

how to run, 5.2.1

log files, 5.3

Patch Set Installer, 1.2

specifying the installation directories, A.2

Patch Set Installer screens, A patching

definition of, 1.1.1

patching Oracle WebLogic Server, 4.2.1.3 patching scenario, 2.3.1 patching tools, 1.2 patchMaster.properties file, B post-patching tasks, 4.6 pre-patching tasks, 4.2

R

related documents, Preface

replication for OID, 6.1.6

response files

creating, A.4

root access, Preface

S

sample patchMaster.properties file, B

schemas that need to be patched for Release 11.1.1.3.0, 5

Security Updates, A.3

Smart Update, 1.2

StartScriptEnabled property for Node Manager, 2.5.2.1

T

tasks you should complete after you patch, 4.6

tasks you should complete before you patch, 4.2

terminology for patching and upgrade, 1.1

tools for patching and upgrade, 1.2

troubleshooting OPatch, 2.5

types of patches, 2.1.1

typical patching scenario, 2.3.1

U

updating schemas with Patch Set Assistant, 4.5

updating the Oracle Virtual Directory Version String in Oracle Directory Service Manager, 6.8

updating the version number string in Oracle Enterprise Manager, 6.7

upgrade

definition of, 1.1.3

Upgrade Assistant, 1.2 upgrade tools, 1.2

V

verifying the installation, 4.9

version number string

updating, 6.7

W

where to obtain patches, 2.2.2

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

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.

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

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on 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. 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.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction 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.