| Oracle® Fusion Applications Installation Guide 11g Release 6 (11.1.6) Part Number E16600-22 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Installation Guide 11g Release 6 (11.1.6) Part Number E16600-22 |
|
|
PDF · Mobi · ePub |
This chapter describes in detail the tasks necessary to perform a physical installation, configuration, and deployment of the product offerings that you specified in your response file.
This chapter includes the following sections:
In the response file that you created, you specified the configuration details necessary to run a physical installation of Oracle Fusion Applications product offerings. For full-scale environments, typically the offerings must be provisioned on multiple hosts, and the installation must be run from a shared drive that is accessible to all hosts.
The installation process is run in phases, in an assigned order. You must complete each phase, in order, on each host, before you move to the next phase. All phases must be completed successfully on all the hosts in your environment to create a fully operational applications environment.
The number of hosts and their purpose determines the order in which you provision the applications environment.
Provisioning provides scripts that read from the response file and take action for each installation phase (target). As each phase is run, its progress is tracked on a related screen in the Provisioning Wizard user interface.
Note:
Run the Provisioning Wizard on the primordial host to create a provisioning response file. If you run the Provisioning Wizard on a non-primordial host to create a provisioning response file, the validation assumes that the host is the primordial host. Ensure that you interpret the validation errors correctly as they may not be applicable to the non-primordial host.
When provisioning a new environment, you should only run the Provisioning Wizard on the primordial host and the Provisioning Command-line Interface on non-primordial hosts.
Installation phases and the names of the tracking screens are as follows:
Preverify: Checks to see that all prerequisites are present. Tracked on the Prerequisite Checks screen.
Install: Installs applications, middleware, and database components. Creates the applications Oracle home directory. Tracked on the Installation screen.
Preconfigure: Prepares application and middleware components for deployment and creates appid users and groups. Modifies the Oracle Application Development Framework (ADF) configuration file to use the database, based on Oracle Metadata Services (MDS) in the applications enterprise archive (EAR) files. Also updates the connections.xml file in all applications EAR files with endpoint information. Tracked on the Preconfigure screen.
Configure: Creates and configures Oracle WebLogic Server domains, Managed Servers, and clusters; applies templates; creates and configures data sources, queues, and topics; configures middleware (wiring); and deploys applications product offerings to domains. Tracked on the Configure screen.
Configure-secondary: Performs the configure actions on a primary or secondary host or both. If there is no primary or secondary host, or if there is only a primary host, this phase runs, but takes no action. Tracked on the Configure Primary/Secondary screen.
Postconfigure: Performs online tasks, such as configuring the Node Manager, deploying the service-oriented architecture (SOA) composite, establishing Oracle HTTP Server wiring, seeding policies, and setting up postdeployment security configuration. Tracked on the Postconfigure screen.
Startup: Starts the Administration Server and Managed Servers for each domain on the host where you are running this phase. Tracked on the Startup screen.
Validate: Performs a variety of postprovisioning validations, such as server and application availability, successful loading of identity credentials, and validation of data source. Tracked on the Validation screen.
Note:
Actions related to Oracle Identity Management components are performed only in specific phases. See Section 5.1.3 for details.
A cleanup and restore phase runs automatically if a failure occurs:
Cleanup: Shuts down processes started during a failed phase and performs the necessary cleanup actions. If the automated cleanup fails, you must manually stop all processes except the Node Manager on all hosts including OPMN and Java EE processes before you can run the restore action. Note, however, that you must stop all processes if you are running the cleanup action on the configure phase.
Restore: The necessary restore actions required for a given provisioning phase. This action deletes and restores the instance directory, and, if necessary (and available), restarts the Common domain Administration Server and Oracle HTTP Server.
See Section 5.5.3 for more information about cleanup and restore actions.
During installation, the Provisioning Wizard performs actions that are associated with the Oracle Identity Management components you installed previously. This section contains a summary of those actions, arranged by the installation phase where the action is performed.
Provisioning phases
The wizard performs the following actions:
Preverify phase
Verifies the existence of the system administrators group (if it was declared as existing during the wizard interview) and the existence of the designated super user in the identity store.
Preconfigure phase
Prepares the Oracle Identity Management components for configuring as follows:
Uploads the LDIF files to the identity store. These files contain entries that represent the application administrator groups used to update the identity store.
Creates the system administrator group (according to what is indicated in the interview).
Makes the super user a member of the administrators group and all the application family directory groups.
Seeds the bootstrap of AppID and gives it membership in the system administrator group.
Configure phase
Configures the Oracle Identity Management components as follows:
Creates the Oracle Fusion Applications domains using the default Oracle WebLogic Server template, with the bootstrap AppID as an administrator.
Disables the default authenticator and enables the LDAP authenticator.
Starts the Oracle WebLogic Server domain using the bootstrap AppID.
Postconfigure phase
Following configuration, the system administrator groups are assigned the appropriate enterprise roles at the product family level. As a result, the super user has:
Administrator privileges for all Oracle WebLogic Server domains and all middleware
Functional setup privileges for all Oracle Fusion Applications offerings
Administration privileges to Oracle Fusion Applications offerings, excluding transactional privileges
To provision a new environment, you start the Provisioning Wizard on the primordial host, make a selection from the options menu, and indicate the location of the response file. The wizard presents a review of the details in the response file on a series of interview screens.
You can make changes to most of the response file details on the interview screens. However, you cannot make any changes to the product offerings. You must create a new response file to change the offering mix.
Once you have completed the preverify phase successfully on all the hosts in your environment, and clicked Next to start the install phase on the primordial host, you can no longer modify any sections of the response file.
Run the phases in order, and complete each phase on all hosts in your environment before you begin the next phase. The Provisioning Wizard enables you to monitor the progress and success of each phase across all hosts.
Note:
If you set up a separate DMZ host for your web tier, you must open a separate terminal session for that host and run all provisioning phases (except the preverify phase). To ignore preverify phase errors, use the command line argument '-ignoreSysPrereqs true' in the runProvisioning command. You cannot view the build processes on the DMZ host on the primordial host interface because the DMZ host does not have access to the shared network drive.
For example, if you have three hosts — Host A (primordial host), Host B (primary host) and Host C (secondary host) — the process of provisioning those hosts works like this:
Open a terminal session on Host A, Host B, and Host C. Log in to each host.
Start the Provisioning Wizard on Host A, select Provision an Applications Environment, and specify the location of the response file.
Page through the wizard screens and make any necessary changes to the response file details displayed. If you selected to view individual domain details on the Provisioning Configuration screen, those screens are also added to the interview. Review the summary of installation actions that will be taken for this response file.
When you click Next on the Summary screen, the wizard initiates the preverify phase on Host A and displays the Prerequisite Checks screen. You can track the progress of this phase on this screen.
From the command line on the Host B and Host C terminal sessions, enter the syntax to run the preverify phase. (You do not have to wait for a phase to run to completion on the primordial host before you start the same phase on any of the other hosts.)
View the results of the preverify phase for all hosts on the Prerequisite Checks screen. The Next button will not be enabled until the preverify phase has been completed successfully on all hosts. Click Back to navigate through previous screens to fix errors. You must resolve all errors before you can continue.
Note:
Once you click Next to move to the Installation screen (the install phase), you can no longer go back to previous screens.
When there are no errors, click Next to initiate the install phase on Host A.
From the command line on the Host B and Host C terminal sessions, enter the syntax to run the install phase.
View the results on the Installation screen on Host A. When the phase has been completed successfully on all hosts, click Next on the Installation screen to initiate the next phase and display the next tracking screen. The phases are listed in Section 5.1.2.
Repeat this process for the remaining phases until all have been completed successfully.
Note:
A full backup of the provisioning and configuration state is performed automatically at the end of each successfully completed phase. The backup is saved in APPLICATIONS_BASE/restart/.
You may want to perform a manual backup, for example, if the automated backup after a phase should fail.
Note: Run these commands for each phase, preverify through postconfigure, and for each host in the environment.
For Linux x86-64:
/bin/tar -C $APPLICATIONS_CONFIG/instance -cf $APPLICATIONS_CONFIG/restart/backup_phase_name/instance.tar .
If local configuration is enabled, also run these commands for each host:
/bin/tar -C $LOCAL_CONFIG/domains -cf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/domains/localdomains.tar . /bin/tar -C $LOCAL_CONFIG/applications -cf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hosthame/applications/localapplications.tar . /bin/tar -C $LOCAL_CONFIG/biinst -cf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/biinst/BIInstance.tar .
For Microsoft Windows x64 (64-Bit):
cd $APPLICATIONS_CONFIG/instance
$REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_phase_name\instance.zip .
If local configuration is enabled, also run these commands for each host:
cd $APPLICATIONS_CONFIG\domains\ $REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_local_phase_name\hostname\domains\localdomains.zip . cd $APPLICATIONS_CONFIG/applications\ $REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_local_phase_name\hostname\applications\localapplications.zip . cd $APPLICATIONS_CONFIG/biinst\ $REPOSITORY\provisioning\util\zip.exe -r $APPLICATIONS_CONFIG\restart\backup_local_phase_name\hostname\biinst\BIInstance.zip .
For Oracle Solaris:
/bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_phase_name/instance.tar -C $APPLICATIONS_CONFIG/instance .
If local configuration is enabled, also run these commands for each host:
/bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/domains/localdomains.tar -C $LOCAL_CONFIG/domains . /bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/applications/localapplications.tar -C $LOCAL_CONFIG/applications . /bin/tar -cEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/biinst/BIInstance.tar -C $LOCAL_CONFIG/biinst .
For IBM AIX on POWER Systems (64-Bit):
cd $APPLICATIONS_CONFIG
/usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_phase_name/instance.pax -x pax $APPLICATIONS_CONFIG/instance .
If local configuration is enabled, also run these commands for each host:
/usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/domains/localdomains.pax $LOCAL_CONFIG/domains . /usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/applications/localapplications.pax $LOCAL_CONFIG/applications . /usr/bin/pax -wEf $APPLICATIONS_CONFIG/restart/backup_local_phase_name/hostname/biinst/BIInstance.pax $LOCAL_CONFIG/biinst .
The installation phases on the primary and secondary hosts are run from the command line, using specific arguments to further define the necessary actions.
Table 5-1 shows valid arguments used when running installation phases.
Table 5-1 Command-Line Syntax for Phase Arguments
| Syntax | Description |
|---|---|
|
|
Directory path to the location of the build scripts. This directory was set up when you installed the provisioning framework, for example |
|
|
You must provide the location of a previously saved response file. Input is:
|
|
|
Indicates that the script should run a specific installation phase (target). Any |
|
- |
Options: Default: Adding this argument disables validation for database, schema, and hosts, and enables you to progress to the install phase without having to fix failure issues. Checks continue to be performed, but failures are ignored. Can be used as an argument with both the If you specify this argument for the preverify phase, you must specify it for all the remaining phases (install, preconfigure, configure, configure-secondary, postconfigure, startup, and validate). If it is not specified for the remaining phases, a phase guard exception will be raised. |
|
- |
Specifies the location of the Oracle Inventory directory, which is used by the installers to keep track of which Oracle products are installed on a host. See Section 2.4.2. For example, the (UNIX) |
Note that the -plan argument in previous releases was replaced by the -responseFile argument.
Table 5-2 shows the command-line syntax for running the various installation phases. Ensure that provisioning on Microsoft Windows platforms is performed from a Run as Administrator console. By default, the command prompt has the necessary privilege set. If not, you can run the Run as Administrator option by right-clicking the Command Prompt from the Start menu.
Note:
In the command syntax, ensure that path_to_script is a local drive and not an UNC path.
Table 5-2 Installation Phase Syntax
| Phase (Target) | Command Syntax |
|---|---|
|
Preverify |
(UNIX) (Windows) |
|
Install |
(UNIX) (Windows) |
|
Preconfigure |
(UNIX) (Windows) |
|
Configure |
(UNIX) (Windows) |
|
Configure-secondary |
(UNIX) (Windows) |
|
Postconfigure |
(UNIX) (Windows) |
|
Startup |
(UNIX) (Windows) |
|
Validate |
(UNIX) (Windows) |
|
Cleanup-phase_name |
(UNIX) (Windows) Note: Substitute phase_name with the appropriate provisioning phase (install, preconfigure, configure, configure-secondary, or postconfigure) to perform a cleanup action. |
|
Restore-phase_name |
(UNIX) (Windows) Note: Substitute phase_name with the appropriate provisioning phase (install, preconfigure, configure, configure-secondary, or postconfigure) to perform a restore action. |
Before you begin the physical installation, ensure that you have completed:
All setup details as described in Chapter 2
All installation tasks associated with your transaction database as described in Chapter 3
A response file with the required configuration details as described in Chapter 4
(For Linux and Solaris platforms only)
Copy the required GCC library for your hardware platform to the repository_location/installer/webgate directory. Follow the instructions in "Installing Third-Party GCC Libraries (Linux and Solaris Operating Systems Only)" in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management 11g Release 1 (11.1.1).
In addition, you must be able to employ enough terminal sessions to enable you to move between running each phase on the primordial host (using the Provisioning Wizard) and running the phases on the primary and secondary hosts (using the command line).
To provision your environment, you start the Provisioning Wizard and page through the installation screens to initiate each phase and monitor the build processes. Note that Oracle Fusion Middleware Oracle homes and Oracle Fusion Applications Oracle home are read only and customers are not expected to update or install any components manually to these home directories. These home directories can be updated only by Oracle Fusion Applications lifecycle tools, such as Provisioning, RUP Installer, and Patch Manager.
Note:
If you ignored any warnings during the creation of the response file, you must fix all issues stated in the warnings before you can successfully provision an environment. You can make those changes in this installation interview. The wizard saves the changes to your original response file and proceeds with the new instructions. All validations must pass before you can run the install phase.
Ensure that you created the inventory pointer file (oraInst.loc) when you installed the provisioning framework. If you created the file in /etc, you can ignore the -invPtrLoc command line argument. If you created the file in another location, you must add the -invPtrLoc argument to the command line syntax and indicate the location of the inventory. See Section 2.4.2 and Section 5.2.
To start provisioning your new environment:
Open a terminal session and log in to the primordial host.
Open a terminal session and log in to each of the other hosts in your environment, including the DMZ host (if present).
Set the JAVA_HOME environment variable to point to the JDK location in the provisioning repository. For example:
(UNIX)
export JAVA_HOME=repository_location/jdk6
export PATH=$JAVA_HOME/bin:$PATH
(AIX)
export JAVA_HOME=repository_location/jdk6
export PATH=$JAVA_HOME/bin:$PATH
export SKIP_ROOTPRE=TRUE
(Windows)
set JAVA_HOME=repository_location\jdk6
set PATH=%JAVA_HOME%\bin;%PATH%
Note:
Verify the system path (PATH) to ensure the reference to the directory "Program Files (x86)" is replaced with its corresponding short path name so that the required tools pick it up properly. If there are references to "Program Files (x86)" (due to the extra space), the Provisioning Configure phase will fail on Microsoft Windows 7 and Windows 2008 Server R2.
Verify that the LIBPATH value is null.
Run the following command on the primordial host:
(UNIX)
cd framework_location/provisioning/bin
./provisioningWizard.sh
On Solaris, use bash provisioningWizard.sh instead of ./provisioningWizard.sh.
(Windows)
cd framework_location\provisioning\bin
provisioningWizard.bat
Note:
Ensure that provisioning on Microsoft Windows platforms is performed from a Run as Administrator console. By default, the command prompt has the necessary privilege set. If not, you can run the Run as Administrator option by right-clicking the Command Prompt from the Start menu.
Note:
For Microsoft Windows platforms, ensure that the Provisioning Wizard is started from the following location: framework_location\provisioning\bin. If the Provisioning Wizard is not run from this location, you will encounter errors for backup operations initiated during the provisioning process.
Table 5-3 illustrates the steps required to provision a new environment on multiple hosts. Notice that once you run the first phase (preverify) on all hosts, the steps to run the remaining phases are the same. Move to each subsequent phase, in the assigned order.
Note:
In the table, UI denotes a step performed in the Provisioning Wizard, and CLI denotes a step performed on the command line.
For help with any of the Provisioning Wizard screens, see Appendix E or click Help on any Provisioning Wizard interview screen.
Note:
Ensure that provisioning on Microsoft Windows platforms is performed from a Run as Administrator console. By default, the command prompt has the necessary privilege set. If not, you can run the Run as Administrator option by right-clicking the Command Prompt from the Start menu.
Table 5-3 Provisioning a New Applications Environment
| Interface (UI or CLI) | Action Required |
|---|---|
|
UI: Welcome Screen |
No action is required on this read-only screen. Click Next to continue. |
|
UI: Specify Central Inventory Location |
This screen displays only if one or more of the following conditions are not met:
Specify the location of the Central Inventory Directory that meets the previous criteria. The For non-Windows platforms, in the Operating System Group ID field, select or enter the group whose members will be granted access to the inventory directory. All members of this group can install products on this host. Click OK to continue. The Inventory Location Confirmation dialog prompts you to run the If you do not have root access on this host but want to continue with the installation, select Continue installation with local inventory and click OK to proceed with the installation. For Windows platforms, this screen displays if the inventory directory does not meet requirements. For more information about inventory location files, see "Oracle Universal Installer Inventory" in the Oracle Universal Installer and OPatch User's Guide. Click Next to continue. |
|
UI: Installation Options Screen |
Presents the list of valid installation options that you can perform using the Provisioning Wizard. Select Provision an Applications Environment. Enter the path in the Response File field to the response file you want to use to provision the environment. Or click Browse to navigate to the response file location. Click Next to continue. |
|
UI: Response File Description Screen |
This is the information you entered when you initially created the response file. It is not associated in any way with the executable plan file, or the summary file, that you saved when you finished creating this response file. You can change the response file name, version, and description before you run provisioning, if you like.
Click Next to continue. |
|
UI: Installation Location Screen |
Displays the credentials for the Node Manager and the directory locations you entered in the response file. If these values have changed, make corrections on this screen. See Section 5.4.3 for details. Click Next to continue. |
|
UI: Review Provisioning Configuration Screen |
Lists the wizard interview screens where you originally specified domain-specific parameters for this response file. You can make changes to this information if necessary. Note: If you ignored any warnings during the creation of this response file, you must fix all issues stated in the warnings before you can successfully provision an environment. Select any of the screens displayed here to make changes for a product domains with warnings. All validations must pass before you can run the install phase. You cannot add or delete product offerings to this response file. To change product offerings, you must create a new response file. Select one or more options from the list. When you click Next, the screens you select are added to the flow. Note that if you return to this screen after running the preverification checks, those verification checks are invalidated. You must run the preverify phase again. Click Next to continue. |
|
UI: Summary Screen |
Review the information displayed to ensure that the installation details are what you intend. To make changes, click Back to return to previous screens in the interview. Click Next to initiate the preverify phase on the primordial host. The wizard displays the Prerequisite Checks screen. It also creates a current copy of this response file and saves it in the directory indicated in the message pane. Click Next to continue. |
|
UI: Prerequisite Checks Screen |
The preverify phase performs prerequisite checks for Oracle Fusion Applications provisioning on the primordial host. The host is marked with a Home symbol in the Host column. The Domains column lists the domains that are being deployed. Once you initiate this phase on the primary and secondary hosts (from the command line), the build processes for those hosts are also shown. The Status column indicates the progress of each phase for each host:
Click an x or a Restricted symbol to display messages about failures. Click the host-level Log file for details about this phase. Click a build Log file to see details specific to that build. You can make changes to the interview screens and rerun the preverify phase as many times as it is necessary. Note that when you make changes to the response file and rerun preverify, Oracle Fusion Applications Provisioning requires that the application configuration directory be empty. Click Retry to rerun this phase if errors are reported. You must fix all errors before you continue. See Section 5.5.3 for details. |
|
CLI and UI: Run the preverify phase on primary and secondary hosts from the command line and monitor progress in the UI. |
In the terminal session for the primary and secondary host, run the preverify phase with this command: (UNIX) (Windows) Note: The same provisioning phases can be run in parallel on all hosts simultaneously as long as the provisioning process has been started in the primordial host first. However, each new provisioning phase must be run in the specific order listed in section Section 5.1.2, "Installation Phases"; that is, you cannot start a new phase until the previous one has been completed successfully on all the hosts in your environment. Monitor the progress of the preverify phase using the Prerequisite Checks screen on the primordial host. Click Retry to rerun this phase if errors are reported. See Section 5.5.3 for details. When this phase is complete with no errors on all hosts, click Next. The wizard starts the install phase on the primordial host and displays the Installation screen. When the preverify phase is successful on the primoridal host, place a copy of the response file and the generated provisioning plan (<APPLICATIONS_BASE>/provisioning/plan/provisioning.plan) on the DMZ host. Note: Once you click Next, you can no longer modify the response file. |
|
UI: Installation Screen |
Displays the progress of the install phase on the primordial host. Build messages and Log icons track the progress for all phases in the same manner as described for the preverify phase. |
|
CLI and UI: Run the install phase on the primary, secondary, and DMZ (if present) hosts and monitor the progress in the UI. |
In the terminal session, run the install phase on the primary, secondary, and the DMZ host (if present) with this command: (UNIX) (Windows) Monitor the progress on the Installation screen on the primordial host. |
|
CLI and UI: Copy the webtier_dmz_artifacts.zip file to the DMZ host (if present). |
After the install phase response files complete, copy the webtier_dmz_artifacts.zip file from Click Next to initiate the preconfigure phase on the primordial host. The wizard displays the Preconfigure screen. |
|
UI: Preconfigure Screen |
Displays the progress of the preconfigure phase on the primordial host. |
|
CLI and UI: Run the preconfigure phase on the primary, secondary, and DMZ (if present) hosts and monitor the progress in the UI. |
In the terminal session, run the preconfigure phase on the primary, secondary, and the DMZ host (if present) with this command: (UNIX) (Windows) Monitor the progress on the Preconfiguration screen on the primordial host. |
|
UI and CLI: Initiate the remaining phases (in order) on the primordial, primary, secondary, and DMZ (if present) hosts. |
Once the preconfigure phase reports a successful completion on each host in your environment, return to the primordial host and click Next to initiate the next phase. As each new phase is started on the primordial host, on the command line, enter the command to run that phase on the primary, secondary, and DMZ host (if present) on the command line. See Table 5-2 for a list of all the phases, and the command-line syntax. The associated screens, in phase order, are as follows:
Once the phases are complete with no errors, click Next on the Startup screen to initiate the validate phase and then start this phase on the other hosts. |
|
UI: Validation |
When the validate phase is complete with no errors on all hosts, click Next. |
|
UI: Installation Complete |
This screen displays the configuration of the new environment. Click Finish. The wizard automatically saves a summary file that describes this installation. The file is saved to the response file directory as follows:
|
Note that if you are provisioning a new environment on a single host, you can ignore the steps that run from the command line. Each phase starts automatically on the primordial host when you click Next.
The wizard displays the Node Manager credentials and the locations of the various directories you entered when you created this response file. You can change these values, if necessary.
Node Manager Credentials
User Name: Specify a user name for the Node Manager role.
Password: Specify a password for the Node Manager and retype it in the Confirm Password field.
Provide locations of various directories that the administrator needs access to.
Installation and Configuration
Installers Directory Location: Enter the path to the repository_location directory you created when you downloaded the provisioning repository. For Windows, the location must be a symbolically linked directory. See Section 2.2.9 for additional details. Note that a symbolic link is not necessary if the repository and the database are on the same node.
Applications Base: Enter the directory path to the Oracle home that you specified when you installed the provisioning framework. This is the Fusion Applications Oracle home. It is the root directory for all Oracle Fusion Applications and Oracle Fusion Middleware products.
The applications base directory must not be set to the system root directory or set to the root directory of a logical drive. Some lifecycle management tools compute directory names by backing up one directory level from the applications base directory and then appending the appropriate subdirectory name. These tools will fail if the applications base directory is set to the system root directory or set to the root directory of a logical drive because it is not possible to back up one directory level from the system root directory or from the root directory of a logical drive.
In a Unix environment, this name cannot exceed 59 characters.
In a Windows environment, this name cannot exceed eight characters, and must be a symbolically linked directory. See Section 2.2.9 for additional details.
Applications Configuration: This directory is automatically populated based on the value you specify in the Applications Base field. It is the path to the directory where the configuration files for the domain will be written. For Windows, the location must be a symbolically linked directory. See Section 2.2.9 for additional details.
Enable Local Applications Configuration: Select this check box to run the Managed Servers from a non-networked (local) disk on the host, visible only to the processes running on that host. If you enable this option, the wizard copies the domain configuration from the shared location and places it on the local disk you specify. This configures all Managed Servers to run from the non-networked location.
Local Applications Configuration: Specify the location for the local domain directory you want to set up. This field is required if you selected Enable Local Applications Configuration. The specified directory must initially be empty.
Middleware Dependencies
Font Directory: Appears only if you have selected Oracle Sales, Oracle Marketing, or Oracle Financials offerings. Enter the directory where the TrueType fonts are installed. The location varies on different operating systems, but is typically found here:
Microsoft Windows x64 (64-Bit): C:\WINDOWS\Fonts
Linux x86-64: /usr/X11R6/lib/X11/fonts/TTF
Oracle Solaris: /usr/X11R6/lib/X11/fonts/TrueType
IBM AIX on POWER Systems (64-Bit): /usr/X11R6/lib/X11/fonts/TrueType
Some systems may not have TrueType fonts installed. If you cannot locate the fonts on your system, verify that they have been installed. In addition, you can use the fonts directory shipped as part of the JRE installed in the repository. Regardless of which path you specify, you must have access to .ttf (.TTF) files.
Oracle Business Intelligence Repository Password
RPD Password: Specify and Confirm a password to allow access to the metadata repository (RPD) for both Oracle Business Intelligence Applications and Oracle Transactional Business Intelligence. The password must be between 8 and 30 characters and contain at least one digit. It can include letters, numbers, pound sign (#), dollar sign ($), or underscore (_). If you want to include two consecutive dollar signs ($$) in the RPD password, enter one additional dollar sign ($) as the escape character before the second dollar sign in the password. This means you need to enter three dollar signs ($$$) for this field in the Provisioning Wizard to indicate two consecutive dollar signs. Provisioning sets up this password, but does not actually access the repository.
If the environment created is Windows-based, the wizard prompts for these values:
Windows Domain\Windows User Name: Specify a user name to use for running provisioning.
Windows Domain Password: Specify a password for running provisioning. Retype the password to Confirm it.
There are various resources available to help with errors that occur during the provisioning of a new Oracle Fusion Applications environment.
If you encounter an error during the creation of applications schemas and tablespaces:
Oracle Fusion Applications release notes may contain additional information about the latest updates.
This release of Oracle Fusion Applications relies on certified versions of supported platforms documentation for Oracle Fusion Applications for details about hardware and software, minimum disk space and memory requirements, required system libraries, packages, or patches, and minimum database requirements.
If you entered incorrect information on one of the installation screens, return to that screen by clicking Back until you see the screen.
When you provision an environment, provisioning writes debug information to the debug directory (APPLICATIONS_BASE/provisioning/debug).
Do not delete any files from this directory.
You can troubleshoot errors using the files in this directory.
Log files contain information about both normal and problematic events. They can help you diagnose and address some problems yourself. For example, log messages that state that a service cannot be reached might indicate a hardware failure.
If you discover a more complex issue, My Oracle Support personnel may use log files to trace the execution code paths of relevant requests as part of diagnosing the problem. Log files are particularly helpful if your Oracle Fusion Applications environment contains custom code that needs debugging, especially when using a debugger is not feasible (such as on a production system).
During each provisioning phase, the Provisioning Wizard writes the actions of the build processes to a log file created for each domain. Click the Log file icon to see details and error messages. In the log file, you can search for a specific text string, or move forward and backward through the content. The wrap feature enables text to be easily printed, or even forwarded by email.
Provisioning writes log files to the following location:
(UNIX)
APPLICATIONS_BASE/logs/provisioning/host_name
(Windows)
APPLICATIONS_BASE\logs\provisioning\host_name
This shared location is accessible from all hosts, and contains the following log files:
runProvisioning-default-main.log: The main log file.
runProvisioning-phase_name.log: The main log file for a given phase, containing the output and error streams. These logs are used by the wizard to keep track of internal information. For example, for runProvisioning-preverify.log, each provisioning thread then writes its own log to runProvisioning-product_family-phase_name.log.
runProvisioning-product_family-phase_name.log: Displayed in the Provisioning Wizard as a Log icon for preconfigure, configure, configure-secondary, postconfigure, and startup phases. The files contain detailed information about the phase. For example, runProvisioning-fin-preverify.log contains information about the preverify actions taken while creating the Oracle Fusion Financials domain.
Note:
Because all reference roles must be provided in each product log file, you should expect to see duplicate reference role entries.
Provisioning also relies on the Oracle Universal Installer (OUI), which writes log files as follows:
(UNIX)
Oracle_Inventory_Location/logs
(Windows)
C:\Program Files\Oracle\Inventory\logs.
If you do not know the location of the Oracle Inventory directory, you can find it at /etc/oraInst.loc (UNIX) or (Windows) C:\Program Files\Oracle\Inventory\logs. For Windows, if the Oracle folder is not present in the program files, the inventory log files are generated under the Oracle Home for the database that is started.
Note that APPLICATIONS_BASE is the root directory under which the provisioned environment resides. With the exception of the web tier host, this physical location must be on a shared drive.
In addition to log file locations discussed in this section, note these log file locations associated only with the preconfigure, configure, configure-secondary, postconfigure, and startup phases:
Oracle WebLogic Server:
(UNIX) app.config.dir/domains/host_name/domain_name/servers/server_name/logs
(Windows) app.config.dir\domains\host_name\domain_name\servers\server_name\logs
Oracle WebLogic Server Node Manager:
(UNIX) APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/nodemanager/host_name/
(UNIX) APPLICATIONS_BASE\fusionapps\wlserver_10.3\common\nodemanager\host_name\
The default log level for provisioning is TRACE:1 and NOTIFICATION:1 for messages written to provisioning log files and console, respectively. The definition of loggers controlling the log level for provisioning log files and console are described as:
<logger name="runProvisioning-default-main" level="TRACE:1">
<handler name="default-main"></handler>
</logger>
<logger name="runProvisioning-console" level="NOTIFICATION:1">
<handler name="prov-cons-handler"></handler></logger>
</loggers>
To change the log level, modify the corresponding logger definition in the framework_location/provisioning/bin/prov-logging-config.xml file.
For more information about log level attributes, see "Setting the Level of Information Written to Log Files" in the Oracle Fusion Middleware Administrator's Guide.
The default log level for standard out, that is, output to the command line console, for managed servers is set to NOTIFICATION to provide additional information when investigating issues, particularly around start up for managed servers.
The wizard performs automated cleanup and recovery actions. If those processes cannot clean up and restore your session, you can perform the actions manually.
See "Starting and Stopping Components in the Oracle Fusion Applications Environment" in Oracle Fusion Applications Administrator's Guide for complete instructions for stopping and starting components.
Recovery is intended to be systemwide. If a failure occurs on one server, cleanup and recovery steps must be performed on all servers, including the hosts on which the phase completed successfully. During the installation, errors may occur during the running of any of the installation phases. If you must use the abort feature, you may need to perform some cleanup tasks as well.
A Retry button is available on each provisioning phase interview screen to initiate cleanup on the primordial host for that phase, or on a non-primordial host if that is where you started provisioning. Initiating the retry operation affects the full phase, beginning with the primordial host or the host from which you started provisioning. The Retry UI explicitly tells you on which hosts you should execute cleanup, and specifies the command to use to run cleanup. A message displays that tells you which host the cleanup target is being run on. If additional cleanup is required on other hosts, those host names are specified after the cleanup target completes. The wizard indicates what cleanup tasks are required, enables the Continue button, and waits for you to click Continue after you complete the additional cleanup. Clicking the Continue button initiates a process to confirm whether the cleanup is complete. If no additional cleanup is required, the Continue button remains disabled, and the wizard starts executing the restore action.
When the restore completes on the current host, a message again displays that tells you which hosts you must execute restore, along with the command to run. The OK button is enabled when the restore is done on the current host. When you click OK, a process checks again to confirm whether the restore is complete and an error message displays if the restore is not complete. When the restore is done, the phase restarts on the current host if needed. If the phase does not need to run, the retry window closes and the information from the previous run of the phase displays. In the hosts table at the top of the screen, all hosts that were either in a failed or aborted state before you started the retry, will be reset when the retry window closes. Then you must restart the phase from the command line for all hosts with a reset status.
The wizard detects hosts that require cleanup and displays a message informing you of the host names. You must perform the cleanup action from the command line on these hosts before you can initiate any restore action. Command-line syntax for the cleanup action takes the following form:
(UNIX) path_to_script/runProvisioning.sh -responseFile provisioning_response_file_location -target cleanup-phase_name
(Windows) path_to_script\runProvisioning.bat -responseFile provisioning_response_file_location -target cleanup-phase_name
The command-line syntax for the restore action takes the following form:
(UNIX) path_to_script/runProvisioning.sh -responseFile provisioning_response_file_location -target restore-phase_name
(Windows) path_to_script\runProvisioning.bat -responseFile provisioning_response_file_location -target restore-phase_name
These actions are available for the preverify, install, preconfigure, configure-secondary, postconfigure, startup, and validate phases. They are also available for shutdown and deinstall actions.
When a failure occurs during one of the provisioning phases, you must fix the cause of the error and then retry the provisioning phase on the hosts that previously failed using the Provisioning Wizard and the provisioning command-line interface if the failed hosts are primary or secondary hosts.
To retry a provisioning phase, you initiate it starting with the primordial host by clicking the Retry button on the Provisioning Wizard. The wizard starts the cleanup phase on the primordial host.
When prompted, you must execute a cleanup phase from the command line on each of hosts that failed the provisioning phase. You can do so simultaneously on all failed hosts. You can skip executing the cleanup phase on a host if the previous provisioning phase was successful.
You do not need to retry the provisioning phase on the hosts that were successful even though the Provisioning Wizard may prompt you to run cleanup and restore targets on these hosts.
Once the cleanup phase completes successfully on all the hosts, continue with the restore phase followed by a retry of the provisioning phase. You can skip executing the restore phase on a host if the previous provisioning phase was successful. Once the restore phase is successful on all hosts, you can rerun the failed provisioning phase.
When a failure occurs during one of the provisioning phases, do the following:
Click Retry to run the cleanup action on the primordial host (Common domain host).
If your environment contains additional hosts, the wizard displays a message giving you the names of the other hosts.
Run the cleanup action from the command line on the other hosts in the terminal session. This can be done in parallel.
(UNIX) path_to_script/runProvisioning.sh -responseFile provisioning_response_file_location -target cleanup-phase_name
(Windows) path_to_script\runProvisioning.bat -responseFile provisioning_response_file_location -target cleanup-phase_name
Click Continue. If all cleanup steps are completed on all hosts where required, the wizard starts the restore action on the primordial host or prompts you to complete steps that have not been completed. Click Continue again when finished to start the restore action on the primordial host.
If your environment contains other hosts, the wizard displays a message giving you the names of the other hosts.
Note:
On Windows, do not open files in the top-level provisioning directory or any of its descendent directories before you run the restore action.
Run the restore action from the command line on the other hosts from the terminal session for each host. This action can run in parallel.
(UNIX) path_to_script/runProvisioning.sh -responseFile provisioning_response_file_location -target restore-phase_name
(Windows) path_to_script\runProvisioning.bat -responseFile provisioning_response_file_location -target restore-phase_name
Click OK on the primordial host to start the next phase. The wizard displays the same messages as described in Step 4 if all additional hosts have not been restored.
The automated cleanup and restore actions cannot handle every type of failure. Sometimes manual steps are needed. This is true, for example, when the configure phase fails and any of the following situations exists:
Node Manager is not yet configured
Node Manager is configured with an invalid trust key
Administration Server is not yet registered with the Node Manager
Administration Server is not running
Under any of these circumstances, the Node Manager will not be able to shut down the Administration Server and the Managed Servers during cleanup-phase_name. You must manually shut down all servers before you continue with the restore-phase_name.
Shut down web tier processes, if any, with this command: (UNIX) WT_CONFIG/bin/opmnctl shutdown. To remove the Windows Service, run C:\sc delete OracleProcessManager_CommonDomain_webtier.
Note: Applies to cleanup-configure, cleanup-configure-secondary, and cleanup-postconfigure.
Shut down BI processes, if any, by running (UNIX) BI_CONFIG_HOME/bin/opmnctl shutdown. To remove the Windows Service, run C:\sc delete OracleProcessManager_BIInstance. See "Using the OPMN Command Line to Start, Stop, Restart, and View the Status of System Components" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition for more information.
Note: This applies to cleanup-configure, cleanup-configure-secondary, and cleanup-postconfigure.
Shut down Global Order Promising (GOP) (if provisioned) with this command: (UNIX) gop_instance_base/bin/opmnctl shutdown. To remove Windows service, run: (Windows) sc delete GlobalOrderPromisingServer1.
Note: This applies to cleanup-postconfigure.
Shut down Informatica Identity Resolution (IIR) processes, if any, by running these two scripts in the order listed:
APPLICATIONS_BASE/informaticaIR/bin/idsdown
APPLICATIONS_BASE/informaticaIR/bin/lidown
Note: This applies to cleanup-postconfigure, if IIR is provisioned.
Shut down Java EE processes using the method recommended for the Oracle WebLogic Server. See "Starting and Stopping Java EE Applications Using WLST" in Oracle Fusion Applications Administrator's Guide for details.
Note: This applies to cleanup-configure, cleanup-configure-secondary, and cleanup-postconfigure.
You do not have to shut down the Node Manager unless it was not configured properly.
Errors during cleanup of a target produce messages that inform you of the error and display the contents of the associated log file. If you scroll through a message, you can view additional messages, including the manual steps that you should take to fix the problem.
Note that failures during cleanup-install require specific cleanup tasks as follows:
Run the Oracle Universal Installer deinstall process for each component against the same oraInventory that provisioning uses. See the Oracle Universal Installer and OPatch User's Guide for information.
Delete the install phase guards. You can find them under APPLICATIONS_BASE/instance/phaseguards/.
(Windows) Delete the following key from the Windows registry before re-running provisioning:
HKEY_LOCAL_MACHINE/SOFTWARE\Wow6432Node\oblix\oblixNetPoint\10.1.4\ WebGate\install_directory
If this step is not completed, WebGate will not be installed properly and will generate the following error during the configure-secondary phase:
webgate-build.xml:928: The directory appbase\webgate\access\oblix\apps\common\bin does not exist.
Provisioning cannot reliably stop all grandchild processes associated with failures during the running of a phase. Occasionally, remnant processes are present after a failure. Oracle recommends that you manually check and stop all remnant processes that start from the APPLICATIONS_BASE and the framework_location/provisioning folder, except for Node Manager and the Provisioning Wizard.
Take this action after you complete the cleanup action for any phase, and before you run a restore action for that phase. Without this additional cleanup action, you may experience unwanted interference with the restore action and subsequent rerun logic. This is especially true for long-running child processes such as LDAP policy migration.
You can identify remnant processes in the APPLICATIONS_BASE as follows:
(Linux) ps -ef | grep APPLICATIONS_BASE/folder_name
(Windows) wmic process get Processid,Commandline,Description | find APPLICATIONS_BASE/folder_name
You can identify remnant processes in the framework_location/provisioning folder as follows:
(Linux) ps -ef | grep framework_location/provisioning/folder_name
(Windows) wmic process get Processid,Commandline,Description | find framework_location/provisioning/folder_name
Remember, do not stop the Node Manager and UI processes.
If the automated restore operation fails, you must complete these manual steps for all phases, except as noted:
Delete the restart phase guard (phase_name.grd) file associated with the failure. It is located under APPLICATIONS_BASE/restart/.
You must restore the instance/ directory from the backup, located as follows:
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/instance.tar
(Windows) APPLICATIONS_BASE \restart\backup_phase_name\instance.zip
(IBM AIX on POWER Systems (64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/instance.pax
Follow these steps to restore the instance/ directory:
(UNIX)
rm -rf CONFIG_HOME
mkdir CONFIG_HOME
tar -xfv path_to_instance.tar/instance.tar -C CONFIG_HOME
(Windows)
rm -rf CONFIG_HOME
mkdir CONFIG_HOME
cd CONFIG_HOME
framework_location\provisioning\util\unzip.exe path_to_instance.zip\instance.zip -d .
(IBM AIX on POWER Systems 64-Bit)
rm -rf CONFIG_HOME
mkdir CONFIG_HOME
cd $CONFIG_HOME
pax -rEf path_to_instance.pax/instance.pax -x pax -p e
When a local application configuration has been enabled, you must manually restore the localdomains and localapplications configuration directories on every local_application_config_host:
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localdomains.tar and...
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localapplications.tar
(Windows) APPLICATIONS_BASE\restart\backup_phase_name\local_application_config_host\localdomains.zip and...
(Windows) APPLICATIONS_BASE\restart/backup_phase_name\local_application_config_host\localapplications.zip
(IBM AIX on POWER Systems 64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localdomains.pax and...
(IBM AIX on POWER Systems 64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/local_application_config_host/localapplications.pax
In addition, restore the following file related to Oracle Business Intelligence:
(UNIX) APPLICATIONS_BASE/restart/backup_phase_name/local application_config_host/biinst/BIInstance.tar
(Windows) APPLICATIONS_BASE\restart\backup_phase_name\local application_config_host\biinst\BIInstance.zip
(IBM AIX on POWER Systems 64-Bit) APPLICATIONS_BASE/restart/backup_phase_name/local application_config_host/biinst/BIInstance.pax
For restore-configure-secondary and restore-postconfigure only, start the CommonDomain Administration Server. See "Starting an Administration Server Using WLST and Node Manager" in Table 3-1 of Oracle Fusion Applications Administrator's Guide for complete instructions for stopping and starting components.
For restore-postconfigure only, start Oracle HTTP Server by running WT_CONFIG_HOME/bin/opmnctl startall. Oracle HTTP Server must be started from the host where it is installed. It cannot be started from any other host.
For restore-configure and restore-postconfigure, check the restore logs to see if the BI schema restore operation is complete. Perform the restore operation for the database contents first.
To restore the BI schema from backup, perform the following actions:
Drop all tables in FUSION_BIPLATFORM, if you have not done so already. Drop only the tables — not the schema user.
Run the following stored procedure as the FUSION_BIPLATFORM user. For restore-configure, use biplatform-preconfigure.dmp as the v_dump_file_name. For restore-postconfigure, use biplatform-configure-sec.dmp:
DECLARE
v_schema_name VARCHAR2(30) := 'FUSION_BIPLATFORM';
v_directory VARCHAR2(30) := 'FUSIONAPPS_PROV_RECOVERY_DIR';
v_dump_file_name VARCHAR2(30) := <biplatform-preconfigure.dmp or
biplatform-configure-sec.dmp>;
v_unique_job_name VARCHAR2(50) := <unique identifying job name e.g. Manual BI
Schema Restore>;
v_temp_schema_name VARCHAR2(40) := 'IN (''' || v_schema_name || ''')';
v_handle NUMBER;
v_job_state VARCHAR2(30);
BEGIN
v_handle :=
DBMS_DATAPUMP.open('IMPORT','TABLE',NULL,v_unique_job_name,'COMPATIBLE');
DBMS_DATAPUMP.add_file(v_handle,v_dump_file_name,v_directory);
DBMS_DATAPUMP.metadata_filter(v_handle,'SCHEMA_EXPR',v_temp_schema_name);
DBMS_DATAPUMP.start_job(v_handle);
DBMS_DATAPUMP.wait_for_job(v_handle,v_job_state);
DBMS_DATAPUMP.detach(v_handle);
END;
If LDAP cleanup fails, perform the following manual tasks:
For the preconfigure phase, complete these tasks:.
Undo member assignments on Administrators, Operators, and Monitors group nodes.
Remove AppIDUsers node under user base distinguished name.
Remove AppIDGroups node under group base distinguished name.
Remove FusionGroups node under group base distinguished name.
Remove Administrators, Operators, and Monitors groups under group base distinguished name (if you created them in the response file).
Remove jpsroot (if you enable it in the response file).
For the configure phase, remove the cn=JPSContext node (with its children) under the jpsroot node from the policy store LDAP if seeding is enabled. Perform this task on the primordial host.
For the postconfigure phase, remove all nodes under jpsroot and recreate the container nodes as well as OPSS credentials that were created in the configure phase:
Remove all nodes under jpsroot node.
Create a temporary bootstrap domain and bring up its Administration Server.
Run reassociateSecurityStore for that domain with join=false to create a fresh policy domain on LDAP.
Since the work completed in the configure phase is undone by the deletion of the policy domain during cleanup, seed OPSS credentials.
Bring down the bootstrap domain's Administration Server and delete the domain from the file system.
You cannot register this domain with Node Manager. Use the command line to bring up this server.
Rerun restore-postconfigure after you fix any issues. If this does not resolve the issues, you should start from the beginning.
If you need to manually start Node Managers on the provisioning hosts, for example, when the hosts are restarted due to error or maintenance, refer to Task 3 in section 3.3.2.1 "Starting an Oracle Fusion Applications Environment" of Oracle Fusion Applications Administrator's Guide for complete instructions for starting Node Manager. The Node Manager is started by provisioning at the beginning of a configure phase. You need to ensure that the Node Manager is running prior to performing a cleanup/restore action for configure-secondary and later phases.
You may encounter some errors during the preverify phase. This section details troubleshooting information for the preverify phase errors.
When there is a build error in the preverify phase in the primordial host, not all validation errors in the non-primordial hosts may be accounted for in the Provisioning Wizard. This is because a build error, a much more severe error than validation, occurs in the primordial host before the logic to count validation errors. After fixing the issue causing the build error and rerunning preverify phase, the validation errors are counted and displayed correctly. This is normal and expected.
Resolve the issue causing the build error in the primordial host first and rerun preverify phase to find out if there are other validation errors among the hosts. Fix the validation errors where appropriate until validation errors are resolved before proceeding to the next phase.
During the preverify phase, you may see an error saying provisioning requires more free space for the local application configuration directory in the current host like the log below:
[2012-02-03T23:11:27.659-08:00] [runProvisioning-preverify] [NOTIFICATION] [] [runProvisioning-preverify] [tid: 12] [ecid: 0000JL7CzeGBDCAnv^n3F11FBDbj000003,0] [logStatus] STATE=BUILD_ERROR!TIMESTAMP=2012-02- 03 23:11:27PST!TARGET=private-preverify-filesystem-Free-space!CATEGORY=BUILD_ERROR!DOMAIN=NONE!HOSTNAME=adcdk16!PRODUCTFAMILY=orchestration!PRODUCT=orchestration!TASK=validateFileSystem!TASKID=orchestration.orchestration.BUILD_ERROR.private-preverify-filesystem-free-space.validateFileSystem!MESSAGE=The file system /scratch/aime/rc4 only has 44271 MB, but 76800 MB is needed! DETAIL=The file system /scratch/aime/rc4 only has 44271 MB, but 76800 MB is needed!BUILDFILE=/net/adcgei13/scratch/aime/rc4/FAINTEG_MAIN_PLATFORMS_120131.1600/provisioning/provisioning-build/common-preverify-build.xml!LINENUMBER=1392! [2012-02-03T23:11:27.698-08:00] [runProvisioning-preverify] [ERROR] [FAPROV-01045] [runProvisioning-preverify] [tid: 12] [ecid: 0000JL7CzeGBDCAnv^n3F11FBDbj000003,0] *** Validation Error! ***[[ ]]
After provisioning completes, you may find that only a fraction of the required file system is being used. This is normal. The 77 GB free space is the Oracle recommended value derived from the performance benchmark. It includes projection of disks required for storing diagnostic logs and other information in the local domain over a long period of time.
During the Install phase on IBM AIX POWER systems (64 bit), the following warning from installation of WebGate appears in the provisioning log even if the provisioning host already meets the supported AIX platform requirement.
Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. Reading response file.. Expected result: One of 5300.08,6100.02 Actual Result: 7100.00 Check complete. The overall result of this check is: Failed <<<< Problem: This Oracle software is not certified on the current operating system. Recommendation: Make sure you are installing the software on the correct platform. Warning: Check:CertifiedVersions failed.
You can ignore the warning and continue with provisioning process.
You may encounter the following error while running the preverification phase on Windows systems:
"C:\repository_location/installers/database/Disk1/setup.exe": CreateProcess error=740, The requested operation requires elevation at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
If you receive this error, disable User Access Control (UAC) or log in as a Local Administrator to the machine where the Provisioning Wizard is not functioning properly.
See http://technet.microsoft.com/en-us/library/dd759070.aspx for information about disabling UAC.
During the provisioning of a new Oracle Fusion Applications environment, you may encounter the following errors in the provisioning log:
OAM_Validation: Cannot perform OAM Validation as null
OAM11G_OAM_ADMIN_USER : Could not validate OAM Admin user
For example, the error log will be displayed as follows:
[2012-04-23T10:36:36.040-07:00] [runProvisioning-preverify] [ERROR] [FAPROV-01045] [runProvisioning-preverify] [tid: 13] [ecid: 0000JRWHGNRFk3A5JbWByf1F_P9m000004,0] *** Validation Error! ***[[ ]] [2012-04-23T10:36:36.040-07:00] [runProvisioning-preverify] [ERROR] [] [runProvisioning-preverify] [tid: 13] [ecid: 0000JRWHGNRFk3A5JbWByf1F_P9m000004,0] List of failed Validation in OIM[[1. OAM_Validation : Cannot perform OAM Validation as null]] [logStatus] STATE=BUILD_ERROR!TIMESTAMP=2012-07-02 10:32:09 PDT!TARGET=common-preverify-security!CATEGORY=BUILD_ERROR!DOMAIN=CommonDomain! HOSTNAME=<host>!PRODUCTFAMILY=fs!PRODUCT=Functional-Setup!TASK=validateOam!TASKID=fs.Functional-Setup.BUILD_ERROR.common-preverify-security.validateOam!MESSAGE=Error 1 : OAM11G_OAM_ADMIN_USER : Could not validate OAM Admin user. !DETAIL=Error 1 : OAM11G_OAM_ADMIN_USER : Could not validate OAM Admin user
Workaround:
Exit the current Provisioning Wizard.
To restart the Provisioning Wizard, add the '-ignoreSysPrereqs true' option to the provisioningWizard.sh command. This enables you to proceed to the next provisioning phase after you have resolved all other errors identified by the preverify phase.
If you also see this error on the non-primordial hosts, add the '-ignoreSysPrereqs true' option before running the runProvisioning.sh command.
For all subsequent provisioning phases, you must use the '-ignoreSysPrereqs true' option in the provisioningWizard.sh and runProvisioning.sh commands.
Cancelling an Installation in Progress: You can interrupt the installation process while it is in progress by clicking Cancel, or by clicking the x icon next to a build that has failed. If you click Cancel, all processes running in the background are terminated and put in a Failed status.
You can start the wizard again after you initiate a Cancel action. The wizard detects that the installation has been partially completed, and presents you with two options:
Resume from where you left off. The wizard asks if you want to resume. Click Yes.
The wizard takes you to the screen where you clicked Cancel and created the failure. Restart the installation at that point by clicking the Retry button. The wizard performs cleanup and recovery actions for you.
Clean up the errors manually and rerun the Provision a New Applications Environment option for the response file from the beginning.
During the Validate phase, you will encounter WebGate validation errors and the error messages in the provisioning log are as follows:
[2012-11-18T19:06:13.323-08:00] [runProvisioning-validate] [NOTIFICATION] [] [runProvisioning-validate] [tid: 11] [ecid: 0000JgMcCTD9lZOLIih8if1GeQ7k000002,0] [logStatus] STATE=BUILD_ERROR!TIMESTAMP=2012-11-18 19:06:13 PST!TARGET=private-validate!CATEGORY=BUILD_ERROR!DOMAIN=CommonDomain!HOSTNAME=<host>!PRODUCTFAMILY=fs!PRODUCT=WebGate!TASK=validate WebPageStatus!TASKID=fs.WebGate.BUILD_ERROR.private-validate.validate WebPageStatus!MESSAGE=The HTTP request to http://<host>:<port>/oberr.cgi?progid=1 returned status: 404.!DETAIL=The HTTP request to http://<host>:<port>/oberr.cgi?progid=1 returned status: 404.!BUILDFILE=<framework_location>/provisioning/provisioning-build/webgate-build.xml!LINENUMBER=992!
[2012-11-18T19:06:52.116-08:00] [runProvisioning-validate] [NOTIFICATION] [] [runProvisioning-validate] [tid: 11] [ecid: 0000JgMcCTD9lZOLIih8if1GeQ7k000002,0] [logStatus] STATE=BUILD_ERROR!TIMESTAMP=2012-11-18 19:06:51 PST!TARGET=private-validate!CATEGORY=BUILD_ERROR!DOMAIN=FinancialDomain!HOSTNAME=<host>!PRODUCTFAMILY=fin!PRODUCT=WebGate!TASK=validateWebPageStatus!TASKID=fin.WebGate.BUILD_ERROR.private-validate.validateWebPageStatus!MESSAGE=The HTTP request to http://<host>:<port>/oberr.cgi?progid=1 returned status: 404.!DETAIL=The HTTP request to http://<host>:<port>/oberr.cgi?progid=1 returned status: 404.!BUILDFILE=<framework_location>/provisioning/provisioning-build/webgate-build.xml!LINENUMBER=992!
These WebGate web page validation errors can be ignored. If there are any other validation errors you must resolve them before proceeding to the Summary phase. After resolving all validation errors, if the Next button on the Provisioning Wizard is not enabled, perform these steps from the command line to enable it:
cd <APPLICATIONS_CONFIG>/phaseguards.
rm validate-<host>--FAILED.grd.
touch validate-<host>-COMPLETED.grd. Note: Use the same host name as specified in Step 2.
The Next button should be enabled on the Provisioning Wizard.
WARNING:
Deleting and creating files in the phase guard directory should be used as a workaround to resolve validation phase issues ONLY if none of the other options work. In any other case, you should never modify or make changes to the phase guard files.
Once you have successfully completed the installation phases on all the hosts in your environment, perform the following required manual steps.
Some components in the Oracle Fusion Applications environment are dependent on one another. Therefore, it is important to start and stop components in the proper order. In the course of normal IT operations, common operations include shutting down computers and starting them back up. Therefore, it is crucial to start and stop Oracle Fusion Applications in a sequential manner. For more information, see "Starting and Stopping the Entire Oracle Fusion Applications Environment" in Oracle Fusion Applications Administrator's Guide.
Refer to Oracle Fusion Applications release notes for mandatory postinstallation steps, including the application of all mandatory patches. For general information about applying patches to an applications environment, see Oracle Fusion Applications Patching Guide.
The TCP/IP port numbers are special in that only processes with root privileges are allowed to listen on those ports. By default, Oracle HTTP Server runs as a non-root user (the user that installed Oracle Fusion Middleware). Since Oracle Fusion Applications Provisioning cannot be run as root, you should not use a port number. For more information, see "Changing the Oracle HTTP Server Listen Ports" in the Oracle Fusion Middleware Administrator's Guide.
Create a file called upgradeLDAPUsersForSSO.props with the following contents. This file is only for the IDSTORE user.
IDSTORE_DIRECTORYTYPE: OID IDSTORE_HOST: idstore.mycompany.com IDSTORE_PORT: 3060 IDSTORE_ADMIN_USER: cn=IDRWUSER,cn=users,dc=mycompany,dc=com IDSTORE_USERSEARCHBASE: cn=Users,dc=mycompany,dc=com IDSTORE_GROUPSEARCHBASE: cn=groups,dc=mycompany,dc=com IDSTORE_LOGINATTRIBUTE: uid PASSWORD_EXPIRY_PERIOD: 7300
Note:
The PASSWORD_EXPIRY_PERIOD is calculated as number of days. For more information, see "Updating Existing LDAP Users with Required Object Classes" in the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition).
The IDRWUser is the read-write user created for provisioning:
IAM_ORACLE_HOME/idmtools/bin/idmConfigTool.sh -upgradeLDAPUsersForSSO input file=upgradeLDAPUsersForSSO.props log_file=upgradeLDAPUsersForSSO.out.
Additional privileges must be given to the entities that are created during provisioning for the IDStore and the Policy Store. To add these privileges, following these steps from the IDM domain:
Set the environment variables: MW_HOME, JAVA_HOME, IDM_HOME, and ORACLE_HOME. Set IDM_HOME to IDM_ORACLE_HOME. Set ORACLE_HOME to IAM_ORACLE_HOME.
Create a properties file as follows and replace the values accordingly:
IDSTORE_HOST: idstore.mycompany.com IDSTORE_PORT: 3060 IDSTORE_BINDDN: cn=orcladmin IDSTORE_USERSEARCHBASE: cn=Users,DC=mycompany,dc=com IDSTORE_SEARCHBASE: dc=mycompany,dc=com IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=mycompany,dc=com POLICYSTORE_HOST: policystore.mycompany.com POLICYSTORE_PORT: 389 POLICYSTORE_BINDDN: cn=orcladmin POLICYSTORE_CONTAINER: cn=FAPolicies POLICYSTORE_READWRITEUSER: cn=PolicyRWUser,cn=Users,dc=us,dc=oracle,dc=com OIM_T3_URL : t3://idstore.mycompany.com:14000 OIM_SYSTEM_ADMIN : xelsysadm OVD_HOST: idstore.mycompany.com OVD_PORT: 6501 OVD_BINDDN: cn=orcladmin
Perform postprovisioning configuration as follows:
(Linux x86-64)
idmConfigTool.sh -postProvConfig input_file=idm.props
(Windows)
idmConfigTool.bat -postProvConfig input_file=idm.props
Your new Oracle Fusion Applications environment is complete and operational. You must now perform the necessary implementation and functional setup tasks.
For complete information about setting up and managing passwords for your new environment, see "Securing Oracle Fusion Applications" and "Provisioning Identities" in Oracle Fusion Applications Administrator's Guide
Before you can start using any of the product offerings you have installed, you must complete some common implementation tasks and enable the functionality of the offerings in your environment.
A large library of product-related documentation is available for use after provisioning. Some of the guides that you will find useful are listed here:
Oracle Fusion Applications Common Implementation Guide
Oracle Fusion Applications Post-Installation Guide
Product-specific Oracle Fusion Applications implementation guides
Oracle Enterprise Manager Cloud Control (Cloud Control) is a system management software that delivers centralized monitoring, administration, and life cycle management functionality for the complete Oracle Fusion Applications IT infrastructure from one single console. For example, you can monitor all the Oracle WebLogic Server domains for all the product families from one console.
See the following documentation to install Cloud Control:
Oracle Enterprise Manager Cloud Control Basic Installation Guide
Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|