16 Complete Conditional Common Post-Installation Tasks

For Oracle Fusion Applications modules that are implemented using PL/SQL, when a diagnostic.log file reaches a specific size, the diagnostic.log file is automatically renamed, and a new diagnostic.log file is created. If the AFLOG_PLSQL_FILENAME profile option is set so that the logging framework uses a log file name other than diagnostic.log, then the file name that the profile option specifies is used, instead of diagnostic.log.

Use the following profile options settings to specify the maximum log file size:

(KSQ: revisit this section: is ordered list procedure needed? Looks like FAC for profile option changing, yes?)

• AFLOG_MAX_FILE_SIZE: This setting specifies the size in megabytes beyond which a PL/SQL log file name is automatically renamed and a new log file is started. The default value is 10 megabytes.

  If the AFLOG_BUFFER_MODE profile option is set to a value larger than 0, enabling asynchronous buffering of PL/SQL log entries, then the actual maximum size of any single PL/SQL log file is the value of AFLOG_MAX_FILE_SIZE plus the number of megabytes that are flushed from the buffer. This value is approximate, because the amount of information that can accumulate in the buffer is set using the AFLOG_BUFFER_SIZE setting, which specifies a specific number of log records, rather than a specific number of megabytes.

• AFLOG_NUMBER_OF_LOG_FILES: This setting specifies the maximum number of PL/SQL log files the system keeps at any one time. The default value is 10 files.

PL/SQL log rotation is currently done only on the basis of file size, not on the basis of the passage of a specified amount of time.

When a PL/SQL log file is renamed, the new name depends on whether the AFLOG_PLSQL_FILENAME profile option is set:

• If the profile option is set, then the new log file name is of the format AFLOG_PLSQL_FILENAME_value-n.log, where n is a positive integer.

• If the profile option is not set, then the new log file name is of the format diagnostic-n.log, where n is a positive integer.

The value of n depends on the names of the log files that are already present in the directory. If the directory contains no previously renamed log files, then the first renamed log file is called diagnostic-1.log or AFLOG_PLSQL_FILENAME_value-1.log. If other log files exist, then n is set to the next higher integer after the highest integer that is already in use. For example, if the directory contains diagnostic-1.log through diagnostic-8.log at the time when the diagnostic.log file surpasses the size limit set in the AFLOG_MAX_FILE_SIZE profile option, then the diagnostic.log file is renamed to diagnostic-9.log.

When the number of log files reaches the value specified using the AFLOG_NUMBER_OF_LOG_FILES profile option, then older log files are deleted automatically, to prevent the disk space usage of the log file directory from getting too large.

Over time, the value of n in diagnostic-n.log or AFLOG_PLSQL_FILENAME_value-n.log can become large enough to cause usability challenges or exceed the number of characters that the operating system allows in a file name. To have the value of n start over at 1, move all existing log files except the currently active diagnostic.log file or AFLOG_PLSQL_FILENAME_value.log file into another directory. When the active file surpasses the size limit and the log rotation code finds no previously renamed log files in the directory, the active file is renamed using a value of 1 for n.

If the Oracle Fusion Applications environment includes multiple database nodes such as Oracle Real Application Clusters (RAC), then each database node corresponds to a server instance that has its own location for log files.

If an incident is created, then the server instance that creates the incident handles all subsequent jobs related to that incident. Identifiers for incidents are unique within a specific instance, but not across instances. For more information about working with incidents, see Prepare to Troubleshoot Using Incidents, Logs, QuickTrace, and Diagnostic Tests in the Oracle Fusion Applications Administrator's Guide.

(KSQ: consider moving this info to the troubleshooting chapter, since it seems more useful for troubleshooting than normal operation?)

Oracle developers create diagnostic tests that can be used to help diagnose and resolve Oracle Fusion application problems.

Oracle developers use mechanisms such as application programming interface (API) calls in Oracle Fusion Applications code to record application operations in log files and to provide error messages as appropriate. A diagnostic test may or may not be associated with a particular error message.

If an Oracle Fusion application handles a particular error in a way that triggers the creation of an incident, then any diagnostic tests that are associated with the error message for the incident run automatically. Oracle developers accomplish this by setting the value of each diagnostic test's APPS_MSG_ID tag to match the identifier of any error message that should trigger the automatic execution of that test. There is no configuration setting for disabling this automatic execution of diagnostic tests.

The results of any automatically run diagnostic test are automatically associated with the related incident, and the identity of the user who received the error message is recorded.

For more information about using diagnostic tests and log files to help diagnose a problem, see Prepare to Troubleshoot Using Incidents, Logs, QuickTrace, and Diagnostic Tests in the Oracle Fusion Applications Administrator's Guide.

It is important to be familiar with the following additional concept that Seed data is information that Oracle provides in the form of database records. Diagnostic tests are included in seed data.

Under normal circumstances, the following administrative tasks are associated with Oracle Fusion Applications diagnostic tests:

• Configuring security to provide appropriate access to diagnostic tests. Job roles can be assigned to particular users to grant those users the ability to perform various diagnostic operations.

  In the current release, a job role for diagnostic operations grants the user the ability to perform the specified operations for all diagnostic tests that are provided with Oracle Fusion Applications. When choosing whether to grant a diagnostic job role to specific users, be aware that some diagnostic tests may include sensitive information in their results.

  (Writer note: this information is current as of early December 2010. Depending on technical and scheduling constraints, future releases may or may not add the ability to control access to individual diagnostic tests.

• Running diagnostic tests. Diagnostic tests can be used for the following purposes:

  • Routinely checking the health of the Oracle Fusion applications

  • Troubleshooting a problem with an Oracle Fusion application

  • Collecting detailed data that may help Oracle Support to resolve a problem

Some diagnostic tests require a specific Oracle Fusion application to be running while the test is performed—these diagnostic tests are called internal diagnostic tests. Other diagnostic tests can perform their functions even if the Oracle Fusion application to be tested is not running—these tests are called external diagnostic tests.

(Writer note: PM says customer administrators do not need to know the technical differences between what internal means for Java tests and what it means for PL/SQL tests. I.e., a Java internal diagnostic test reuses or refers to code modules, entity objects, or view objects from a Fusion application, but a PL/SQL internal diagnostic test runs using the data security context of the Fusion application.)

The distinction between internal and external tests is important because it affects both when the tests can be run and which interfaces can be used to run the tests. The Diagnostic Testing Framework provides two interfaces:

• The Oracle Fusion Applications Diagnostic Dashboard application (Diagnostic Dashboard) provides a graphical user interface that allows to perform the following tasks:

  • Execute and monitor both internal and external diagnostic tests for Oracle Fusion applications

  • Purge diagnostic test results

  • Register any special-purpose diagnostic tests that Oracle Support may provide

  • Work with categorization tags to keep the diagnostic tests organized

    (Writer note: references to custom tags hidden for v1 per PM request, as we do not yet have a supported migration path for custom tags.)

• The diagctl command-line interface allows to perform the following tasks:

  • Execute external diagnostic tests (tests that do not require a specific Oracle Fusion application to be running)

    Technical constraints prevent the diagctl command-line interface from returning useful results for internal diagnostic tests (tests that require a specific Oracle Fusion application to be running when the test is performed). Use Diagnostic Dashboard to run any internal diagnostic tests.

    Use also Diagnostic Dashboard to determine whether a particular test is an internal or an external test.

  • View diagnostic test results

  • Register any special-purpose diagnostic tests that Oracle Support may provide

1. Decide which users need the capabilities of each of the four preconfigured job roles for diagnostic operations.
2. Use Oracle Identity Manager to assign the appropriate job role to each user.
3. For each external role that was created or found in Step 2, use Oracle Authorization Policy Manager to map the external role to the specific diagnostic duty role that allows the needed operations.

1. Log in to the Oracle Access Manager Console as the Oracle Access Manager administration user.
2. Click the System Configuration tab.
3. Expand Access Manager Settings - SSO Agents.
4. Click the Agents icon.
5. In the Search window, click Search.
6. Click an Agent, for example: IAMSuiteAgent.
7. Set the Security radio button to OAM Transfer mode in the OAM Configuration screen of the Oracle Identity Management Provisioning Wizard, as described in Create an Oracle Identity Management Provisioning Profile.

   Click Apply.

8. Restart the managed servers WLS_OAM1 and WLS_OAM2 as described in Start and Stop Components.

1. In the Oracle Access Manager Console, click the Agents icon.
2. On the displayed search page, click Search to perform an empty search.
3. Click the Agent Webgate_IDM_11g.
4. In the User Defined Parameters box, set client_request_retry_attempts to 11.
5. If the following Logout URLs are not listed, add them:

   • /oamsso/logout.html

   • /console/jsp/common/logout.jsp

   • /em/targetauth/emaslogout.jsp

6. Click Apply.
7. Repeat Steps 5 and 6 for the following agents: OraFusionApp_11AG and OSN_Agent (if it exists).

1. Run stopall.sh in Linux as described in Start and Stop Components.
2. Edit the oif_startup.conf file to automatically start Oracle Identity Federation. This file is located in the directory: IDM_CONFIG/scripts.

   #
   # OIF is enabled OOTB for Shared IDM
   #
   # OIF_ENABLED indicates whether or not OIF should be started/stopped
   # as part of the startoif.sh/stopoif.sh scripts. Valid values are true or false
   # If false, the OIF will not be started or stopped
   OIF_ENABLED=true
   # OPMN_EMAGENT_MANAGED_BY_OIF_SCRIPT indicates whether or not OPMN and
   # the EMAgent components for the OIM domain should be started, when OIF is enabled.
   # Valid values are true or false. If false, OPMN and the EMAgent components will not
   # be started or stopped when OIF is enabled.
   # If OIF is disabled, OPMN and the EMAgent components will not be started or stopped
   OPMN_EMAGENT_MANAGED_BY_OIF_SCRIPT=true
   

   Save the file.

3. Run startall.sh in Linux as described in Starting and Stopping Components.

1. On IDMHOST1, access the SP metadata by going to:

   http://IDMHOST1.mycompany.com:14100/oamfed/sp/metadata

2. On IDMHOST2, access the SP metadata by going to:

   http://IDMHOST2.mycompany.com:14100/oamfed/sp/metadata

In Service Provider (SP) mode, Oracle Access Manager delegates user authentication to Oracle Identity Federation, which uses the Federation Oracle Single Sign-On protocol with a remote Identity Provider. Once the Federation Oracle Single Sign-On flow is performed, Oracle Identity Federation will create a local session and then propagates the authentication state to Oracle Access Manager, which maintains the session information.

This section provides the steps to integrate Oracle Identity Federation with Oracle Identity Manager in authentication mode and SP mode.

MANDATORY: Federation Trust must be established prior to enabling Oracle Identity Federation.

This section contains the following topics:

• Enable Oracle Identity Federation

• Disable Oracle Identity Federation

Oracle Virtual Directory communicates with other directories through adapters.

The procedure is slightly different, depending on the directory to be connected to. The following sections show how to create and validate adapters for supported directories:

• Remove Existing Adapters

• Create an Oracle Virtual Directory Adapter for Active Directory

• Validate the Oracle Virtual Directory Adapters

Prepare Active Directory as described in the following sections:

• Configure Active Directory for Use with Oracle Access Manager and Oracle Identity Manager

• Create Users and Groups

• Create Access Control Lists in Non-Oracle Internet Directory Directories

1. Log in to the OIM Console at the URL listed in About Oracle Identity Management Console URLs.
2. Click Advanced on the top of the right pane.
3. Click Search System properties.
4. On the navigation bar in the left pane, search on Username Generation.
5. Click Default Policy for Username Generation.
6. In the Value field, update the entry from oracle.iam.identity.usermgmt.impl.plugins.DefaultComboPolicy to oracle.iam.identity.usermgmt.impl.plugins.FirstNameLastNamePolicyForAD.
7. Click Save.

Node Manager enables to start and stop the Administration Server and the Managed Servers.

1. Edit the file nodemanager.properties.
2. Change the line SecureListener=false to SecureListener=true.
3. Save the file.
4. Restart Node Manager by killing the nodemanager process, and restart by running the following command:

   startNodeManagerWrapper.sh
   

1. Log in to the WebLogic Administration console as the user weblogic_idm. Console URLs are provided in About Oracle Identity Management Console URLs.
2. Select IDMDomain, Environment, Machines from the Domain Structure menu.
3. Click on Lock and Edit.
4. Click on one of the machines, for example idmhost1.mycompany.com.
5. Click on the Node Manager tab.
6. Change Type from Plain to SSL.
7. Click Save.
8. Repeat Steps 4-7 for each machine.
9. Click Activate Changes.

1. Locate the line in the file that starts with nmConnect.
2. Change the last parameter from plain to SSL.

   For example, in start_adminserver_template.py, change the line:

   nmConnect('admin', nmpwd, 'localhost', '5556', 'IDMDomain' , '/u01/oracle/config/domains/IDMDomain' , 'Plain')
   

   to

   nmConnect('admin', nmpwd, 'localhost', '5556', 'IDMDomain' , '/u01/oracle/config/domains/IDMDomain' , 'SSL')
   

3. Save the file.

This section describes how to set up host name verification certificates for communication between Node Manager and the Administration Server. It consists of the following steps:

• Generate Self-Signed Certificates Using the utils.CertGen Utility

• Create an Identity Keystore Using the utils.ImportPrivateKey Utility

• Create a Trust Keystore Using the Keytool Utility

• Configure Node Manager to Use the Custom Keystores

• Configure Managed Oracle WebLogic Servers to Use the Custom Keystores

• Change the Host Name Verification Setting for the Managed Servers

1. Run the following commands to start Node Manager.

   cd IDM_CONFIG/nodemanager/hostname
   ./startNodeManagerWrapper.sh
   

<Loading identity key store:
  FileName=IDM_CONFIG/domains/IDMDomain/keystores/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true>

1. Ensure there is access to the Oracle Fusion Applications NLS release notes from the current release.
2. Ensure that the steps in Download Language Pack Software have been followed.

1. Set the APPLICATIONS_BASE environment variable to point to the directory that contains Oracle Fusion Applications. For example, if Oracle Fusion Applications is installed in /server01/APPLICATIONS_BASE/fusionapps, then set the APPLICATIONS_BASE environment variable to /server01/APPLICATIONS_BASE.

   Examples follow:

   UNIX:
   setenv APPLICATIONS_BASE /server01/APPTOP/
   

2. Run Health Checker. Note that this is one command.

   UNIX:
   $APPLICATIONS_BASE/fusionapps/applications/lcm/hc/bin/hcplug.sh -manifest
   $APPLICATIONS_BASE/fusionapps/applications/lcm/hc/config/LanguagePackReadinessHealthChecks.xml [-DlogLevel=log_level]
   

1. Set the APPLICATIONS_BASE environment variable to point to the directory that contains Oracle Fusion Applications. For example, if Oracle Fusion Applications is installed in /server01/APPLICATIONS_BASE/fusionapps, then set the APPLICATIONS_BASE environment variable to /server01/APPLICATIONS_BASE.

   Examples follow:

   UNIX:
   setenv APPLICATIONS_BASE /server01/APPTOP/
   

2. Run Health Checker. Note that this is one command.

   UNIX:
   $APPLICATIONS_BASE/fusionapps/applications/lcm/hc/bin/hcplug.sh -manifest
   $APPLICATIONS_BASE/fusionapps/applications/lcm/hc/config/GeneralSystemHealthChecks.xml [-DlogLevel=log_level]
   

1. Create a response file named silent.rsp to be used in silent mode. This file can be located in any directory that is accessible while launching Language Pack Installer. An example follows:

   ORACLE_HOME=/u01/APPLICATIONS_BASE/fusionapps/applications
   CRM_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   FSCM_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   HCM_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY  
   OBI_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   UCM_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   BPM_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   SOA_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   B2B_SELECTED_JAZN_MIGRATION_TYPE=PATCH_POLICY
   

   The stripe_SELECTED_JAZN_MIGRATION_TYPE properties allow to choose which deployment method Language Pack Installer uses for policy store changes to each stripe. The following choices are available:

   • PATCH_POLICY: Apply safe changes only. This is the recommended deployment method. Choose this method if there are no conflicts.

   • MIGRATE_POLICY_OVERRIDE: Apply all changes and overwrite customizations.

   • MIGRATE_POLICY_NO_OVERRIDE: Append additive changes.

   • MIGRATE_POLICY_APM: Manually resolve conflicts and upload changes using Authorization Policy Manager (APM).

   If PATCH_POLICY or MIGRATE_POLICY_NO_OVERRIDE are chosen, then the results of the analysis must be reviewed to manually upload any changes not applied by Language Pack Installer, based on the selected choice, after the installation is complete. If MIGRATE_POLICY_OVERRIDE was chosen, then the customizations that are overwritten after the installation is complete may need to be reapplied.

   If MIGRATE_POLICY_APMis chosen, the installation must be paused while bringing up the APM application and uploading the changes.

   Note the location of the following files:

   • Baseline file: FA_ORACLE_HOME/admin/JAZN/stripe/baseline

   • Patch file for fscm, crm, and hcm stripes: FA_ORACLE_HOME/stripe/deploy/system-jazn-data.xml

   • Patch file for the obi, ucm, bpm, b2b, and soa stripes: FA_ORACLE_HOME/com/acr/security/jazn/bip_jazn-data.xml

2. Set the JAVA_HOME environment variable as follows:

   UNIX: setenv JAVA_HOME APPLICATIONS_BASE/fusionapps/jdk
   

3. Confirm the registration of the network location of FA_ORACLE_HOME.

   $REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -addLangs -jreLoc APPLICATIONS_BASE/fusionapps/jdk/ 
   -invPtrLoc APPLICATIONS_BASE/fusionapps/applications/oraInst.loc -silent -response location_of_response_file -updatesDir installer_patch_directory 
   

4. Run the following command to start Language Pack Installer in silent mode:

   If Language Pack Installer encounters errors in silent mode during installation, it terminates the session. The issue that caused the failure and then restart Language Pack Installer must be resolved using the same command used previously. Language Pack Installer then restarts from the first failed task. See General Troubleshooting During the Configuration Phase in Silent Mode.

   UNIX: REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -addLangs -jreLoc
   APPLICATIONS_BASE/fusionapps/jdk [-invPtrLoc FA_ORACLE_HOME/oraInst.loc] -silent
   -response location_of_silent.rsp_file 
   -noCheckForUpdates OR -updatesDir installer_patch_directory
   [-DpatchStageLocation=directory_location_of_patch_stage
   [-Dworkers=number_of_workers][-DlogLevel=level] 
   [-DserverStartTimeout=timeout_period_for_server_in_seconds]
   [-DpatchDownloadLocation=patch_directory][-debug]
   

   The following table shows valid options that can be used when running Language Pack Installer in silent mode.

   Table 16-2 Language Pack Installer Command Options in Silent Mode

   Option Name	Description	Mandatory
   -addLangs	Runs Language Pack Installer to install one language.	Yes.
   -jreLoc	Path where the Java Runtime Environment is installed. This option does not support relative paths, so specify the absolute path.	Yes.
   -invPtrLoc (UNIX platforms only)	The location of an overriding inventory pointer file. If the Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME) is registered in inventory with a /net path, then provide the location of oraInst.loc including /net in the path.	Recommended, use to override the default location of the inventory pointer file, located in /etc/oraInst.loc.
   -silent	Run Language Pack Installer in silent mode.	Yes.
   -response	The location of the response file, silent.rsp.	Yes.
   -noCheckForUpdates	Skips the application of the installer update patch, if there is no installer update patch available for this release.	No, this option cannot be used if the -updatesDir option is used. Either -noCheckForUpdates or -updatesDir must be used.
   -updatesDir	The location of the installer update patch. When a valid installer patch is found, the installer automatically restarts itself after applying the patch.	No, this option cannot be used if the -noCheckForUpdates option is used. Either -noCheckForUpdates or -updatesDir must be used.
   -DpatchStageLocation	Location of patch stage. This is the directory where Middleware patches from a downloaded location, as well as the repository, are consolidated before applying.	No, the default directory is APPLICATIONS_BASE/../patch_stage.. For example, if APPLICATIONS_BASE is /u01/APPLICATIONS_BASE, the patch stage directory is /u01/patch_stage.
   -DupdateJAZNPolicyStore=true	Updates the policy store with translated attributes so field descriptions, display names, and other attributes display their translated values.	No, use only when base English is not used in the policy store.
   -Dworkers	The number of workers to use for uploading database content. If a value is provided for the number of workers that is outside the calculated range, a value that is within the optimal range is requested. If this option is not used, a calculated optimal value is used.	No, overrides the default number of workers calculated by Language Pack Installer.
   -DserverStartTimeout	Configures the timeout value for server in seconds.	No, overrides the default value for server timeout.
   -DpatchDownloadLocation	The directory path where mandatory prerequisite patches were downloaded to be applied by Language Pack Installer. See Download Language Pack Software.	No, the default is 11.1.11.x.0_post_repo_patches.
   -DlogLevel	Records messages in the log file at the level specified. Enter a value to override the default log level of INFO.	No, default value is INFO.
   -debug	Retrieve debug information from Language Pack Installer.	No.

5. Proceed to Complete the Post-Installation Tasks..

1. Set the JAVA_HOME environment variable as follows:

   UNIX: setenv JAVA_HOME APPLICATIONS_BASE/fusionapps/jdk
   

2. Confirm registration of the network location of FA_ORACLE_HOME.

   If the Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME), which is APPLICATIONS_BASE/fusionapps/applications, is registered in the central inventory with a /net path, then provide the oraInst.loc location including /net when starting Language Pack Installer. An example follows:

   UNIX only:
   $REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -jreLoc APPLICATIONS_BASE/fusionapps/jdk/
   -invPtrLoc /net/APPLICATIONS_BASE/fusionapps/applications/oraInst.loc
   

   If not triggered with a /net path, Language Pack Installer copies the -invPtrLoc file to FA_ORACLE_HOME. This results in a copy of the file to itself, which then becomes an empty or zero byte file. As a result, the copy phase fails when oracle_common patches are applied.

3. Run the following command to start Language Pack Installer in GUI mode.

   UNIX: $REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -addLangs -jreLoc APPLICATIONS_BASE/fusionapps/jdk 
   [-invPtrLoc FA_ORACLE_HOME/oraInst.loc]
   -noCheckForUpdates OR -updatesDir installer_patch_directory
   [-DpatchStageLocation=directory_location_of_patch_stage
   [-Dworkers=number_of_workers][-DlogLevel=level]
   [-DserverStartTimeout=timeout_period_for_server_in_seconds]
   [-DpatchDownloadLocation=patch_directory][-debug]
   [-DupdateJAZNPolicyStore=true]
   

   The following table shows valid options that can be used when running Language Pack Installer.

   Table 16-3 Language Pack Installer Command Line Options

   Option Name	Description	Mandatory
   -addLangs	Runs Language Pack Installer to install one language.	Yes.
   -jreLoc	Path where the Java Runtime Environment is installed. This option does not support relative paths, so specify the absolute path.	Yes.
   -noCheckForUpdates	Skips the application of the installer update patch, if there is no installer update patch available for this release.	No, this option cannot be used if the -updatesDir option is used. Either -noCheckForUpdates or -updatesDir must be used.
   -updatesDir	The location of the installer update patch. When a valid installer patch is found, the installer automatically restarts itself after applying the patch.	No, this option cannot be used if the -noCheckForUpdates option is used. Either -noCheckForUpdates or -updatesDir must be used.
   -DpatchStageLocation	Location of patch stage. This is the directory where Middleware patches from a downloaded location, as well as the repository, are consolidated before applying.	No, the default directory is APPLICATIONS_BASE/../patch_stage. For example, if APPLICATIONS_BASE is /u01/APPLICATIONS_BASE, the patch stage directory is /u01/patch_stage.
   -invPtrLoc (UNIX platforms only)	The location of an overriding inventory pointer file. If the Oracle Fusion Applications Oracle home directory (FA_ORACLE_HOME), is registered in inventory with a /net path, then provide the location of oraInst.loc including /net in the path.	Recommended, use to override the default location of the inventory pointer file, located in /etc/oraInst.loc.
   -Dworkers	The number of workers to use for uploading database content. If a value is provided for the number of workers that is outside the calculated range, a value that is within the optimal range is requested. If this option is not used, a calculated optimal value is used.	No, overrides the default number of workers calculated by Language Pack Installer.
   -DserverStartTimeout	Configures the timeout value for server in seconds.	No, overrides the default value for server timeout.
   -DpatchDownloadLocation	The directory path where mandatory prerequisite patches were downloaded to be applied by Language Pack Installer. See Download Language Pack Software.	No, the default is 11.1.11.x.0_post_repo_patches.
   -DlogLevel	Records messages in the log file at the specified level. Enter a value to override the default log level of INFO.	No, the default value is INFO.
   -DupdateJAZNPolicyStore=true	Updates the policy store with translated attributes so field descriptions, display names, and other attributes display their translated values.	No, use only when base English is not used in the policy store.
   -debug	Retrieve debug information from Language Pack Installer.	No.

   The following table illustrates the tasks that Language Pack Installer runs. For information about log files and troubleshooting Language Pack Installer errors, see Troubleshoot Language Pack Installer Sessions.

   Table 16-4 Language Pack Installer Screen Sequence

   Screen	Description and Action Required
   Welcome	Appears when Language Pack Installer is started. This screen does not appear if Language Pack Installer is started after a failure. The standard Welcome screen is read-only. It contains a navigation pane on the left-hand side that summarizes the tasks the installer takes. Each item in the pane represents an installer screen, which contains prompts for the necessary information. Click Next to continue.
   Install Software Updates	Appears when Language Pack Installer is started. This screen does not appear if the -noCheckForUpdates option is supplied, or after the installer restarts itself automatically after applying an installer patch. The screen displays two options: Skip applying the installer update Search Local Directory for Updates Select Search Local Directory for Updates. Specify the correct Installer update patch location or click Browse to locate the file. Then click Search for Updates to display the patch number and the type of patch. Click Next to continue.
   Installation Location	Specify the location of the existing Oracle Fusion Applications home (FA_ORACLE_HOME) where the language is installed. Click Next to continue.
   Installation Summary	Summarizes the selections made during this installation session. It includes the Oracle home, required and available disk space, and the language to be installed. Review the information displayed to ensure that the installation details are correct. To make changes before installing, click Back to return to previous screens in the interview. Click Install to start installing this language.
   Installation Progress	Displays a progress indicator that shows the percentage of the installation phase that is complete and indicates the location of the installation log file. The installation phase consists of copying files from the language pack to the appropriate Oracle homes. When the installation progress indicator shows 100 percent, click Next to continue.
   Policy Store Analysis (Note that this screen displays only when the -DupdateJAZNPolicyStore option is set to true when Language Pack Installer is started)	Analysis is available for the following policy store stripes: hcm, crm, fscm, soa, ucm, bpm, b2b,and obi. Select the stripes to be analyzed and then click Run Analysis to identify any conflicts or deletions. Only the stripes that are included in the language pack are enabled for analysis and the analysis could run for several minutes. After the analysis runs, review the results of the analysis to determine which deployment method Language Pack Installer should use for policy store changes to each stripe. Oracle recommends to select Apply safe changes only. This is the safest method unless the consequences of the other three options have beemn read and totally understood. If it is decided to resolve the conflicts or deletions before the actual JAZN upload from Language Pack Installer, the Policy Store Analysis step should be run again to get the most accurate analysis report. The choices for deployment method are: Apply safe changes only (choose this method if there are no conflicts). Apply all changes and overwrite customizations (not available for soa, ucm, b2b, and bpm stripes). Append additive changes. Manually resolve conflicts and upload changes using Authorization Policy Manager. If Apply safe changes only is selected or Append additive changes, then the results of the analysis must be reviewed to manually upload any changes not applied by Language Pack Installer with the selected choice, after the installation is complete. If Apply all changes and overwrite customizations is chosen, then the customizations that are overwritten after the installation is complete may need to be reapplied. If one of these options is chosen, click Next after making the selection. If Manually resolve conflicts and upload changes using Authorization Policy Manager (APM) is selected, the installation must be paused while bringing up the APM application and uploading the changes. Note the location of the following files: Baseline file: FA_ORACLE_HOME/admin/JAZN/stripe/baseline Patch file for fscm, crm, and hcm stripes: FA_ORACLE_HOME/stripe/deploy/system-jazn-data.xml Patch file for the ucm: FA_ORACLE_HOME/com/acr/security/jazn/ucm_jazn-data.xml Patch file for the soa: FA_ORACLE_HOME/com/acr/security/jazn/soa_jazn-data.xml Patch file for the bpm: FA_ORACLE_HOME/com/acr/security/jazn/bpm_jazn-data.xml Patch file for the obi: FA_ORACLE_HOME/com/acr/security/jazn/bip_jazn-data.xml When completing this task in APM, shut down the APM application, return to Language Pack Installer, and click Next.
   Configuration Progress	Displays a progress indicator that shows the percentage of the configuration phase that is complete. It displays each configuration assistant in the message pane as it is performed. No additional user action is required in the Configuration Progress screen unless a failure occurs.
   Installation Complete	Summarizes the installation just completed. To save this configuration to a response file, click Save. To complete a successful installation, click Finish. The Finish button is activated only if all mandatory configuration assistants completed successfully. To rerun this session after resolving failed configuration assistants, click Cancel.

   For information about the user interface, see Installer User Interface.

4. Proceed to Complete the Post-Installation Tasks..

UNIX: $REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -addLangs 
-jreLoc APPLICATIONS_BASE/fusionapps/jdk 
-invPtrLoc FA_ORACLE_HOME/oraInst.loc 
-noCheckForUpdates OR -updatesDir installer_patch_directory

UNIX: $REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -addLangs 
-jreLoc APPLICATIONS_BASE/fusionapps/jdk 
-invPtrLoc FA_ORACLE_HOME/oraInst.loc -DupdateJAZNPolicyStore=true
-noCheckForUpdates OR -updatesDir installer_patch_directory

UNIX: $REPOSITORY_LOCATION/installers/fusionapps/Disk1/runInstaller -addLangs
-jreLoc APPLICATIONS_BASE/fusionapps/jdk
-invPtrLoc /net/APPLICATIONS_BASE/fusionapps/applications/oraInst.loc
-noCheckForUpdates OR -updatesDir installer_patch_directory

1. Set the APPLICATIONS_BASE environment variable to point to the directory that contains Oracle Fusion Applications. For example, if Oracle Fusion Applications is installed in /server01/APPLICATIONS_BASE/fusionapps, then set the APPLICATIONS_BASE environment variable to /server01/APPLICATIONS_BASE.

   Examples follow:

   UNIX:
   setenv APPLICATIONS_BASE /server01/APPTOP/
   

2. Run Health Checker.

   UNIX:
   $APPLICATIONS_BASE/fusionapps/applications/lcm/hc/bin/hcplug.sh -manifest 
   $APPLICATIONS_BASE/fusionapps/applications/lcm/hc/config/PostLanguagePackHealthChecks.xml 
   [-DlogLevel=log_level]
   

1. Bounce all servers using the fastarstop script bounce option. See Understand the fastartstop Utility and its Syntax in the Oracle Fusion Applications Administrator's Guide.

   If more than one language in an environment are being installed, servers need to be bounced only once at the end of installing all languages in that environment, to minimize time spent bouncing servers.

2. Verify that all deployed applications are up and running. Check this from Fusion Applications Control, or by reviewing the server side log files. See Access Fusion Applications Control in the Oracle Fusion Applications Administrator's Guide.

The installer can be restarted to rerun all failed configuration tasks as well as those tasks that were not started from the previous session. When a mandatory configuration task or step fails in silent mode, the installer exits. After resolving the issue that caused the failure, restart the installer using the same command used to start it. When the installer restarts, it restarts from the first failed task.

If any non-mandatory tasks fail in silent mode, the installer continues with the next configuration task and does not exit. Review the logs to find any non-mandatory tasks that failed and then rerun the installer until all tasks complete successfully.

If the installer is run in GUI mode, start it from the REPOSITORY_LOCATION/installers/fusionapps/Disk1 directory.

This section describes the following troubleshooting scenarios:

• Restart a Failed Installer Session

• Troubleshoot Failures While Parallel Tasks Are Running

• The Next Button Is Not Enabled During Configuration Assistants

• The OPSS Security Store Goes Down While the Installer is Running

• Failure During Opening of Wallet Based Credential Store

• Error While Loading Database Components in GUI Mode