2 Prepare for the Release 12 Upgrade Before Downtime

If the environment does not meet the memory requirements, Health Checker reports an error during the pre-downtime phase. Verify that the memory configuration meets the requirement mentioned in the following table:

For Oracle Virtual Machine (VM) memory requirements, see Suggested Memory (in GB) and Number of vCPUs in Oracle Fusion Applications Installing and Managing in an Oracle VM Environment.

The disk space requirements mentioned in the following table are recommendations on the disk space required on specific hosts. If the environment does not meet these requirements, Health Checker reports an error during the pre-downtime phase. The disk space check does not check for total space, as it checks only for usable disk space, which is defined as free space with respect to quotas and permissions.

All recommendations and requirements assume non-shared access to the disk space. Therefore, if there are multiple hosts or processes running against the same physical disk, the size of this disk needs to be determined with respect to all sharing tenants. The requirements in the following table do not consider disk sharing scenarios:

For Solaris 10 Only

These patches can be obtained from My Oracle Support.

For Solaris 11 Only

The steps in this section outline the process for setting up permissions on directories that are shared across multiple hosts and are used by Oracle Fusion Applications Upgrade Orchestrator. These steps are required if different operating system (OS) users and groups are used to own Oracle Fusion Applications components (such as FA, FMW, and IDM) on the hosts in the Oracle Fusion Applications environment (such as Primordial, OHS, and IDM).

An OS user and group is considered to be the same across all hosts only if the corresponding IDs (User ID and Group ID) are also the same across the hosts. The minimum requirement for Upgrade Orchestrator is that the files in the SHARED_LOCATION must be owned by the same group. All OS users that own Oracle Fusion Applications components on various hosts must belong to the common group, in addition to other groups to which they already belong.

MANDATORY: The SHARED_LOCATION must be exported with the no_root_squash option, or its equivalent, to allow root user access to files in the SHARED_LOCATION that are owned by the applications user. For more information about the SHARED_LOCATION, see Create Directories in a Shared Location.

To set up permissions on directories that are shared across multiple hosts and are used by Oracle Fusion Applications Upgrade Orchestrator, perform the following steps:

1. Determine the OS group and Group ID that needs to be used for owning the shared directories. As an example, it is possible to use orch as the common group to be used across the hosts.

2. Perform the following steps as a privileged OS user, such as root, on all hosts that participate in orchestration:

   1. Create the common group as shown in the following example (if needed):

      (Linux) /usr/sbin/groupadd -g group_ID -f group_name
      
      (Solaris) /usr/sbin/groupadd -g group_ID group_name
      

   2. Add each distinct Oracle Fusion Applications component (FA, FMW, DB, IDM) OS owner on each host to the common group as shown in the following example:

      (Linux) /usr/sbin/usermod -a -G group_name component_OS_owner
      
      (Solaris) EXISTING_GROUPS=$(grep -w component_OS_owner /etc/group |awk -F: '{print $1}' |xargs echo | sed 's/ /,/g')
      /usr/sbin/usermod -G ${EXISTING_GROUPS},group_name component_OS_owner
      

      Log out of any sessions that were open prior to this change for OS users being modified, and then log in again so the changes take effect.

   3. Mount the file system to be used for the shared directories on all hosts.

   4. On one of the hosts, such as the primordial host, create a top-level directory that is passed to orchestration under which additional directories and files are created during orchestration. This directory is referred to as SHARED_LOCATION and is further described in Create Directories in a Shared Location.

   5. Before any additional content is created in the shared directories, change the group ownership of the top-level directory to the common group, such as orch as shown in the following example:

      (Linux and UNIX) chgrp common_group SHARED_LOCATION
      

   6. Set permissions on the directory so that the group has read, write, and access privileges as shown in the following example:

      (Linux and UNIX) chmod g+r,g+w,g+x SHARED_LOCATION
      

   7. Set the Directory group ID bit for the top-level shared directory. This allows for any subdirectories and files created under this shared directory to be owned by the same group, regardless of the host from where they are created. For example:

      (Linux and UNIX) chmod g+s SHARED_LOCATION
      

3. Perform the following steps on all hosts that participate in orchestration. Make sure to be logged in as the OS user that owns the Oracle Fusion Applications content on the host when running these steps:

   1. Set the default mask for files so that the group has sufficient privileges on the files as follows:

      umask 0007
      

   2. Confirm that the group changes are effective. The groups command displays all groups that the current OS user belongs to. Confirm that the common group, orch, is one of them as follows:

      (Linux and UNIX) groups
      

   3. Confirm that the permissions are set up correctly on each host. To do this, create a temporary file in the shared directory and confirm that the file is owned by the common group and that its permissions are correct.

      • For directories, the group should have read, write, and execute privileges.
      • For files, the group should have at least read and write privileges.

      Run the following commands after creating the temporary file:

      The following command should show that the file is owned by the common group:

      (Linux and Unix)) ls -ls file_name
      

      The following command prints the group and group ID ownership for the file:

      (Linux) stat --printf="%G %g\n" file_name
      
      (Solaris) echo "group: `ls -ld file_name|awk '{print $4}'" "`"; echo "groupid:`ls -dn file_name | awk '{print $4}'" "`"
      

      Then, remove the temporary file.

   When unzipping the contents of a ZIP archive into the shared folder, the group ownership can be lost on some folders and files. This issue is specific to the unzip utility. To work around the issue, run the following commands when extracting contents to the shared folder:

   jar -xvf ZIP_archive
   unzip -q -o ZIP_archive
   

4. Ensure file permissions are correct by performing the following steps, as a prerequisite to starting orchestration:

   1. Change directory to FA_ORACLE_HOME/hcm/hrc/bin.

   2. Run chmod -R 755 *.

   3. During the upgrade, patch_stage directories are created in a location which is parallel to the APPLICATIONS_BASE directory. If the user ID who is running the upgrade does not have write permissions, the Consolidating Repository and Downloaded Patches configuration assistant reports a failure. To avoid this failure during the upgrade, ensure that the user who runs Upgrade Orchestrator has write permissions on the top level directory parallel to the APPLICATIONS_BASE directory, which is typically /net/mount1.

Create the directories required for the upgrade in a shared location that is accessible to all host types, including scaled out hosts, in the Oracle Fusion Applications environment. This location is referred to as SHARED_LOCATION in this guide.

If more than one environment are being upgraded, those environments can be configured to access this SHARED_LOCATION to avoid duplicating the software downloads. These directories must also be available to all users and if different users create any of the directories, the users must belong to the same shared group.

The directory names in this section are suggested names and are referenced throughout the upgrade steps. It is possible to choose to use other naming conventions. See Download Directories.

Create the following directories for Release 12 repositories:

• SHARED_LOCATION/11.12.x.0.0/Repository

• SHARED_LOCATION/11.12.x.0.0_post_repo_patches

• SHARED_LOCATION/11.12.x.0.0/idmUpgrade

• SHARED_LOCATION/11.12.x.0.0/LP (required only if languages other than US English have been installed)

• SHARED_LOCATION/11.12.x.0.0/PCU. Stage post repo patch for the pcu_bundle.zip in this location. Leave this location empty if there is no post repo for pcu_bundle.zip.

Create the following directories in a shared storage that is available to all users and all host types within the environment that is getting upgraded:

These directories can also optionally be configured to be shared across other environments.

• ORCHESTRATION_CHECKPOINT_LOCATION

  This is a shared location available to all hosts in the environment where orchestration checkpoint related files are saved. Ensure a shared mount point that has high disk I/O performance is selected, especially for writing. Orchestration framework automatically creates POD_NAME under the specified directory. This location is stored in the ORCHESTRATION_CHECKPOINT_LOCATION property in the pod.properties file.

  It is a best practice not to use ORCH_LOCATION/config as a value for this property.

• ORCHESTRATION_CHECKPOINT_ARCHIVE_LOCATION

  This is a shared location available to all hosts in the environment where orchestration checkpoint related files are archived. Ensure that a shared mount point that has high disk I/O performance is selected, especially for writing. Orchestration framework automatically archives the checkpoint file stored under the POD_NAME directory in the directory specified by the ORCHESTRATION_CHECKPOINT_LOCATION property. This location is stored in the ORCHESTRATION_CHECKPOINT_ARCHIVE_LOCATION property in the pod.properties file.

  It is a best practice not to use ORCH_LOCATION/config as a value for this property.

Create a directory referred to as SHARED_UPGRADE_LOCATION in shared storage that is available to all users and all host types within the environment that is getting upgraded. This directory can also optionally be configured to be shared across other environments.

This is a temporary directory required by the upgrade to copy files and perform write operations. Ensure that a shared mount point that is shared across all hosts for a given environment that has high disk I/O performance is selected, especially for writing. This area can be cleaned up after all of the environments have been successfully upgraded to Release 12.

Additionally, create the following directory:

SHARED_UPGRADE_LOCATION/healthchecker/common

Grant write access to the group that was created in Create a Common User Group and Permissions for Shared Directories as well as the checkpoint location and shared upgrade directories that were created in this section.

The Release 12 repository contains all patches that are required to upgrade to Release 12 in an existing Oracle Fusion Applications environment. To download the repository from the Oracle Fusion Applications Product Media Package, perform the following steps:

To see the options available to obtain the Oracle Fusion Applications software, see Obtain the Software in the Oracle Fusion Applications Installation Guide.

After the repository is shipped for every release of Oracle Fusion Applications, additional required patches are staged in a "post repository" directory. The Upgrade Orchestrator can apply these mandatory post-release if the patches are downloaded from My Oracle Support before starting upgrade. The latest post-release patches are cumulative. You must always start by staging the latest post-release patches in a clean location that does not have any files or directories.

To download patches for Release 11.12.x.0.0, first unzip the /SHARED_LOCATION/11.12.x.0.0/Repository/installers/pre_install/PostRepoPatchDirs.zip file into the /SHARED_LOCATION/11.12.x.0.0_post_repo_patches directory to create the directory structure for the downloaded patches. Then, stage the patch bundles and post repo patches accordingly. The orchestration process automatically picks the patches from the SHARED_LOCATION/11.12.x.0.0_post_repo_patches directory when launching the Upgrade Orchestrator, and the upgrade process continues.

Language Installed Artifacts

To create the directory structure for the downloaded patches, unzip the /SHARED_LOCATION/11.12.x.0.0/Repository/installers/pre_install/PostRepoPatchDirs.zip into the 11.12.x.0.0_post_repo_patches directory. Then, proceed with staging all the available Post Release Patch content. The post-repo structure looks like the following:

For each language installed in your environment, download the Release 12 language pack from http://edelivery.oracle.com to the SHARED_LOCATION/11.12.x.0.0/LP directory. The location of the downloaded language packs is recorded in the REL12_LP_REPOSITORY_LOCATION property in the Primordial host properties file, as described in Table 11-2.

To find all installed languages in the environment, run the following query:

select LANGUAGE_TAG, ISO_LANGUAGE, ISO_TERRITORY from FND_LANGUAGES where INSTALLED_FLAG in ('I', 'B')

Health Checker performs sets of validations at various stages of the upgrade. Download the following patches for Release 11.12.x.0.0 from My Oracle Support to have all the required information available for Health Checker:

Create the SHARED_UPGRADE_LOCATION/healthchecker/common directory if it does not yet exist.

• Download patch 24623814 and extract its contents to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch defines Health Checker plug-ins that are to be disabled out-of-the-box. This patch will be updated with additional plug-in(s) to be excluded as short term solutions(s) when required.

  MANDATORY: This patch is mandatory and its latest version must be downloaded and staged before running Orchestration.

• Verify whether the following patches are available from My Oracle Support. If one of the patches for the target release is not available, ignore the patch as no action is required:

  • Patch 17051994: If available, download and extract its contents, such as FA_invalid_overrides.xml, from the patch to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch ensures that a set of objects that get into an invalid state during intermediate stages of the upgrade are safely ignored.

  • Patch 21196045: If available, download and extract its content, such as FA_file_permissions_template_overrides.xml, from the patch to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch defines the metadata that is used to check Fusion Applications file permissions. When filenames and folder names are added to the contents of this file, those files and folders are verified by the Health Checker File Permission check. This plug-in is disabled out-of-box. To re-enable this check, see Customization: Re-enable a Plug-in that is Disabled in all_overrides.xml.

  • Patch 21204921: If available, download and extract its content, such as FA_fmw_file_permissions_template_overrides.xml, from the patch to the SHARED_UPGRADE_LOCATION/healthchecker/common directory. This patch defines the metadata that is used to check Fusion Middleware file permissions. When filenames and folder names are added to the contents of this file, those files and folders are verified by the Health Checker File Permission check. This plug-in is disabled out-of-box. To re-enable this check, see Customization: Re-enable a Plug-in that is Disabled in all_overrides.xml.

To download and unzip the latest versions of Orchestration.zip and the Health Checker framework, perform the following steps:

There are two different types of IDM upgrades for this release. In the following chapters you will choose your upgrade type and perform the steps and use the patches applicable to that type only. For more information see, IDM for FA Upgrade Roadmap.

After you download all the patches listed above, stage the latest idmUpgrade.zip file only if the environment meets all of the following requirements:

• Runs on a Linux or Solaris platform

• Supports the Type 1 or Type 2 IDM upgrade

To set up Upgrade Orchestrator on a shared location, perform the following steps:

Perform the steps in this section only if Oracle Fusion Applications is being run in an Oracle Virtual Machine (VM) environment that was created from official releases of Oracle VM templates for Oracle Fusion Applications Release 12 (11.12.x.0.0) and higher. This content is not applicable for any Oracle VM environments that are created using other methods.

• To determine if the Oracle VM environment was created from official releases of Oracle VM templates for Oracle Fusion Applications Release 2 and higher, verify if the /assemblybuilder directory is present in the Oracle VM environment. This confirms that the environment is an OVAB.

• To confirm the release version, review the .labelinfo.txt and .misclabels.txt files in the u01/APPLTOP/ovabext directory to check the rehydration labels that correlate to the release version. Also check if there is a /u01/ovmext directory to determine if it is an Oracle VM IDM instance.

To install the Oracle Fusion Applications 11.12.x.0.0 Lifecycle Management Tools for Oracle VM Installer repository on the Oracle VM hosts, perform the following steps:

This repository includes RUP Lite for OVM.

For more information about the plug-ins, see RUP Lite for OVM Utility.

If Oracle Beehive is used in a Windows environment to send email alerts from Upgrade Orchestrator, then there must be a secured SMTP connection, which requires user authentication data. Such data must not be stored in any property file, and it cannot be pre-seeded in a credential store. However, it is possible to use the mkstore command utility to save this required user authentication information in a wallet file. By default, this wallet file is located at ORCH_LOCATION/config/orchfwk/wallet.

To add user authentication data to the wallet file, perform the following steps:

To update properties files, perform the following step:

• Update the properties files which are located in the ORCH_LOCATION/config/POD_NAME directory. If a property is not relevant for the environment, leave it empty, but do not remove the property. For a detailed list of properties, see Upgrade Orchestrator Properties Files.

Perform the following steps to create an override file that will be referenced by the REL12_RUPINSTALLER_UPGRADE_PARAM property during the upgrade. This step is not applicable for Oracle VM environments.

1. Create an override file, which can be located in SHARED_LOCATION. In this example, the file name is override.properties. It is possible to use a different name for the override file in the environment.

2. The override file contains the following properties:

   • The VIRTUAL_HOST_MODE property must be set to one of three values: IP, Name, or Port. To determine which property value to use, perform the following steps:

     1. Open WEBTIER_INSTANCE_HOME/config/OHS/ohs1/moduleconf/FusionVirtualHost_fs.conf. An example of WEBTIER_INSTANCE_HOME is APPTOP/instance/CommonDomain_webtier.

     2. If the FusionVirtualHost_fs.conf file contains the string, NameVirtualHost, use VIRTUAL_HOST_MODE=NAME in the override file.

     3. If more than one host exist in FusionVirtualHost_fs.conf for the VirtualHost directive, use VIRTUAL_HOST_MODE=IP in the override file.

     4. Otherwise, use VIRTUAL_HOST_MODE=Port.

   • Set the user base dn and group base dn to configure Application Security Console (ASE). The default values are set as follows:

     1. user.create.bases= cn=Users,dc=us,dc=oracle,dc=com 

     2. group.create.bases= cn=FusionGroups,cn=Groups,dc=us,dc=oracle,dc=com 

     If the default value are used, there is no need to set them in overriding properties file. Otherwise, set these two properties accordingly to be consistent with the actual LDAP Identity Store setup.

   • The REFERENCE_ROLES_FILES property contains a list of the offerings that were selected to be provisioned in the environment. It is possible to obtain this list from the APPLICATIONS_CONFIG/fapatch/FUSION_env.properties file, using only the offerings that also have an entry set to TRUE in this properties file.

     The following examples are provided for each pillar:

     overrides-hcm.txt:
     VIRTUAL_HOST_MODE=Name
     REFERENCE_ROLES_FILES=PER_CORE,PER_WKF_DEPL,PER_WKF_DEV
     

     overrides-fscm.txt:
     VIRTUAL_HOST_MODE=Name
     REFERENCE_ROLES_FILES=XLE_FINANCIALS_JUR,PO_PROCUREMENT,PJF_PROJ_MNG,PIM_PROD_MNG,DOO_ORCHESTRATION,INV_LOGISTICS,FOS_SCM_FIN_ORCHESTRATION
     

     overrides-crm.txt
     VIRTUAL_HOST_MODE=Name
     REFERENCE_ROLES_FILES=MKT_MARKETING,ZBS_SALES,CMP_OIC_BU
     

   • Perform the following step if Load Balancer (LBR) is enabled:

     To create the wiring for the OHS configuration that is used by the Product Management application in the SCM domain, create the following properties. These properties must contain the values for the host and port of the custom LBR external endpoints:

     • PROCUREMENTDOMAIN.SUPPLIERPORTALAPP.LBR_HOSTNAME

     • PROCUREMENTDOMAIN.SUPPLIERPORTALAPP.LBR_PORT

     The OHS.properties file contains two related properties that must be populated for both the LBR enabled and LBR disabled scenarios: SUPPLIER_PORTAL_VIRTUAL_HOSTNAME and SUPPLIER_PORTAL_VIRTUAL_PORT. For a scaled out scenario, multiple properties exist, prefixed with the OHS_INSTANCE_ID:

     • ohs1_SUPPLIER_PORTAL_VIRTUAL_HOSTNAME

     • ohs1_SUPPLIER_PORTAL_VIRTUAL_PORT

     • ohs2_SUPPLIER_PORTAL_VIRTUAL_HOSTNAME

     • ohs2_SUPPLIER_PORTAL_VIRTUAL_PORT

3. Update the REL12_RUPINSTALLER_UPGRADE_PARAM property in the pod.properties file to add the following value:

   -DrupOverride=SHARED_LOCATION/override.properties
   

To determine if Upgrade Orchestrator needs to run incremental provisioning, review the following list of requirements:

Incremental Provisioning Requirements for Oracle VM Environments

Review the following steps if an Oracle Virtual Machine (VM) Environment is used:

• Review the offerings in the applicable OVM template for your environment in Overview in the Oracle Fusion Applications Installing and Managing in an Oracle VM Environment.

• If the environment contains all of the offerings available in the template, there is no need to run Incremental Provisioning.

• If the environment does not contain all of the offerings available in the template, run Incremental Provisioning to add offerings so that the environment matches the OVM template.

Incremental Provisioning Requirements for non-Oracle VM Environments

Review the following steps if a non-Oracle Virtual Machine (VM) Environment is used:

• Review all offerings in Oracle Fusion Applications Product Families and Product Offerings in the Oracle Fusion Applications Installation Guide and compare them with your current installed offerings.

  • If offerings need to be added from the list of offerings for your business needs, then run Incremental Provisioning to add these offerings. If the environment has at least one SCM offering or the Procurement offering, select all mandatory SCM offerings in Incremental Provisioning.

  • If the environment has all of the offerings needed, then consider the following questions and refer to the table below to determine what to do next:

    • If the environment has no SCM offerings, then there is no need to run Incremental Provisioning.

    • If the environment has at least one SCM offering or the procurement offering, then the environment must have all mandatory SCM offerings from all releases. If the environment does not meet this requirement, then run Incremental Provisioning.

For more information, see the Extend an Oracle Fusion Applications Environment Using Incremental Provisioning During Upgrade section in the Oracle Fusion Applications Installation Guide.

To prepare for incremental provisioning, perform the following steps:

$ cd SHARED_LOCATION/11.12.x.0.0/Repository/installers 
$ ./validate_repo.sh repository_manifest.xml

./installers/biappsshiphome/patch/25499241/files/bifoundation/server/bin/libmemhook64.so does not exists in the repository 
./installers/oracle_common/patch/25217940/etc/config/.nfsA6D7 does not exists in the repository 
Total resource entries in the manifest file: 71711, missing resource entries: 2 
This repository is corrupt because of some missing files

The upgrade process does not expect the Node Manager password to be different from the keystore password. This difference in passwords causes a failure during the upgrade, which includes the following error message:

ERROR KEYSTORE WAS TAMPERED WITH, OR PASS...

To prevent this issue, confirm that the Node Manager password is the same as the keystore password before starting the upgrade. Use the Administration Console to change the values for the Node Manager password and properties.

If a cloned instance is being upgraded, change the Node Manager password back to the original password that is used by the Node Manager in the source environment for the clone. After the upgrade, it is possible to change the password back to what it was in the cloned environment after the clone was complete.

Refer to the latest Technical Known Issues to verify that the database and Sql*Net tuning parameters are set properly to avoid timeout errors during the upgrade.

If JDeveloper customizations to a SOA composite were performed, and then the composite to the SOA runtime was deployed, perform manual steps to merge the customizations during the upgrade. To ensure that the customizations can be merged successfully, review the recommendations in About Merging Runtime Customizations from a Previously Deployed Revision into a New Revision in the Oracle Fusion Applications Extensibility Guide for Developers before starting Upgrade Orchestrator.

Merge the customizations after the SOA Preverification configuration assistant fails during the upgrade. See Merge SOA Composite JDeveloper Customizations During SOA Preverification.

Ensure that you have your own versions of any customized BI Publisher reports. If an upgrade includes an update to a catalog object that was delivered with an Oracle Fusion application, the patch overwrites any customizations applied to the original report. For more information on customizing business intelligence, see the Creating and Editing Analytics and Reports guides relevant to your products.

If Extended Flexfields is being used and the DOO SOA composites have been customized for mapping between EBO and DOO SDO, it is possible to remove these customizations before upgrading to Release 12 and use the new automap feature. See Preserve SOA Composite JDeveloper Customizations Before Apply a Patch in the Oracle Fusion Applications Patching Guide.

For more information about the automap feature in Release 12 that allows you to avoid using SOA composite customizations by setting up Oracle Fusion Distributed Order Orchestration Extensible Flexfields, see the Oracle Fusion Applications Order Orchestration Implementation Guide.

The FUSION user must have an unlimited quota on all FUSION_TS* tablespaces. To verify that the FUSION user has an unlimited quota on all FUSION_TS* tablespaces, run the following query:

select tablespace_name, max_bytes from dba_ts_quotas where username = 'FUSION';

The FUSION user must have a value of -1 for max_bytes on all FUSION_TS* tablespaces. If any tablespace does not have the correct value or does not have an entry, grant the unlimited quota by running the following command:

alter user FUSION quota unlimited on tablespace_name; 

Run the validatedomains script to confirm that all Administration Server domain locations are detectable. If the steps to scale out hosts were followed, the Administration Server of the scaled out host may have been added to a new machine. This section provides the steps to temporarily add the Administration Server back to the originally provisioned machine so that all domain directories can be found by Upgrade Orchestrator. During post-upgrade steps, the Administration Server is added back to the machine that was created during scaleout.

Whether the hosts have been scaled out or not, perform the following steps to run the validation for domain locations and to temporarily update the machine for Administration Servers, if needed:

1. Unzip domainvalidate.zip from the SHARED_LOCATION/11.12.x.0.0/Repository/installers/farup/Disk1/upgrade/validate directory into any directory on the primordial host.

   1. Update the path with the correct location of JDK by placing the JDK apptop in front of the path so that java runs from it as follows:

      (UNIX)
      PATH=$1/jdk6/bin:$1/fusionapps/jdk6/bin:$PATH
      export PATH 
      

   2. If FA_MW_HOME is APPLICATIONS_BASE/fusionapps, run the following command:

      (UNIX)
      ./validatedomains.sh APPLICATIONS_BASE
      
      

      For example:

      validatedomains.sh /u01/APPLTOP
      

   3. If APPLICATIONS_CONFIG is APPLICATIONS_BASE/instance, run the following command:

      (UNIX) ./validatedomains.sh FA_MW_HOME APPLICATIONS_CONFIG
      
      

      For example:

      validatedomains.sh /u01/APPLTOP/fusionapps /u01/APPLTOP/instance
      

2. If validatedomains.sh reports any domains that failed the validation, and there are no scaled out hosts, skip to Step 3.

   If validatedomains.sh reports any domains that failed the validation, and if there scaled out hosts, perform the following steps on the Administration Server of each of the reported domains:

   1. Log in to the WebLogic console for the domain.

   2. Navigate to Environment, then Machines.

   3. Find the machine that corresponds to the host name for which the Administration Server was initially provisioned.

   4. Click on the machine and go to the Servers tab. Note that the Administration Server should not appear on the list of servers. If it does appear on the list, either this domain passed validation or this is not the originally provisioned machine for the Administration Server.

   5. Click Lock & Edit to make changes.

   6. Click Add.

   7. Select the AdminServer and click Finish.

   8. Click Activate Changes to apply the changes.

   9. Skip Step 3 of this procedure.

3. If validatedomains.sh reports any domains that failed the validation, and if there are no scaled out hosts, perform the following steps:

   1. Download the patch 18062458 to a local directory.

   2. Run the extracted command against each domain directory under APPLICATIONS_CONFIG as follows:

      For Unix:
      FA_MW_HOME/oracle_common/common/bin/wlst.sh fixadminconfig.wlst APPLICATIONS_CONFIG/domains/<HOST>/<DOMAIN NAME>
      

   3. Run the validatedomains script again, to ensure that all Administration Server domain locations are detectable.

Perform the following steps on the admin-apps/PRIMORDIAL host and all Midtier hosts to verify that the node manager configuration is correct.

1. Review the config/config.xml file in each domain directory and check the MACHINE_NAME entries. Ensure that for each machine entry, the node-manager child element has its own name element that matches the name element of the machine. Refer to the following example:

   <machine>
     <name>MACHINE_NAME</name>
     <node-manager>
       <name>MACHINE_NAME</name>
       ...
     </node-manager>
   </machine>
   

2. If any of the node-manager elements are missing child name elements, then the configuration must be fixed by using the offline WebLogic Scripting Tool (WLST) command as described in the following steps:

   1. Run the WLST command to fix the configuration in each domain directory as follows:

      FMW_ORACLE_HOME/oracle_common/common/bin/wlst.sh
      

   2. Open the domain in offline mode as follows:

      readDomain('PATH_TO­_DOMAIN')
      

   3. Run the following commands for each impacted machine:

      cd('/Machine/MACHINE_NAME/NodeManager/MACHINE_NAME')
      set('Name', 'MACHINE_NAME') 
      

   4. Save the domain and exit WLST as shown in the following example:

      updateDomain()
      closeDomain()
      exit()
      

3. Review the config.xml file for each of the impacted domain directories and ensure that the name elements are now present.

To verify that the node manager configuration is correct, perform the following steps on the admin-apps/PRIMORDIAL host and all Midtier hosts:

1. Review the config/config.xml file in each domain directory and check the server entries. Ensure that for each server entry, the SSL child element has its own name element that matches the name element of the machine. Refer to the following example:

   <server>
   <name>SERVER_NAME</name>
   <ssl>
   <name>SERVER_NAME</name>
   ...
   </ssl>
   </server>
   

2. If any of the ssl elements are missing child name elements, then the configuration must be fixed by using the offline WLST command as described in the following steps:

   1. Run the WLST command to fix the configuration in each domain directory:

      FMW_ORACLE_HOME/oracle_common/common/bin/wlst.sh
      

   2. Open the domain in offline mode:

      readDomain('PATH_TO­_DOMAIN')
      

   3. Run the following commands for each impacted machine:

      cd('/Server/SERVER_NAME/SSL/SERVER_NAME')
      set('Name', 'SERVER_NAME')
      

   4. Save the domain and exit WLST:

      updateDomain()
      closeDomain()
      exit()
      

3. Review the config.xml file for each of the impacted domain directories and ensure that the name elements are now present.

Upgrade Orchestrator expects the default realm name to be myrealm for the Common Domain. Changing the name to anything other than myrealm causes Upgrade Orchestrator to fail. To verify that this value has not been changed to any other name, perform the following steps :

Upgrade Orchestrator uses "Bash" as the default shell on Unix platforms. Ensure that the /bin/bash shell version 3.2 or higher is installed on all hosts.