This article is intended to provide some supplemental information and lessons learned for the IDM portion of the FA upgrade when going from RUP1 to RUP2 and from RUP2 to RUP3. For these two upgrades in partuicular, Oracle has published a separate document for the IDM upgrade steps. Overall, the process of upgrading the security components is straightforward if the instructions are followed carefully, but it's also true that the IDM part of the upgrade is a little more hands-on and potentially confusing that the FA part.
Note that the documentation below was created during a period when the naming convention for the upgrades changed -- initially, the upgrades have been referred to RUP1, RUP2, etc., but the documentation no longer reflects that:
Version Old Name New Name
188.8.131.52.0 FA 11gR1 RUP1 FA 11gR1 Release1
184.108.40.206.0 FA 11gR1 RUP2 FA 11gR1 Release 2
220.127.116.11.0 FA 11gR1 RUP3 FA 11gR1 Release 3
One will see references to both naming conventions, so this should be kept in mind when searching in My Oracle Support or the internet for information.
Important Note: These are incremental and not cumulative patches. One must apply RUP1 before one can apply RUP2, and RUP2 before RUP3.
Starting with RUP2/Release 2, the documentation for the upgrade upgrade consists of three separate documents:
For RUP1/Update 1:
Release Notes: MOS Document 1382781.1
Patching Guide: http://docs.oracle.com/cd/E25054_01/fusionapps.1111/e16602/toc.htm
For RUP2/Update 2:
Release Notes: MOS Document 1439014.1
Patching Guide: http://docs.oracle.com/cd/E25178_01/fusionapps.1111/e16602/toc.htm
IDM Upgrade Procedure: MOS Document 1435333.1
For RUP3/Update 3:
Release Notes: MOS Document 1455116.1
Patching Guide: http://docs.oracle.com/cd/E28271_01/fusionapps.1111/e16602/toc.htm
IDM Upgrade Procedure: MOS Document 1441704.1
Always start with the release notes before looking at the patching guide. The IDM upgrade procedure is a complement to the patching guide -- while following the patching guide for the upgrade, it will refer to the IDM upgrade doc, which will then refer back to the patching guide to continue.
Important Note: These documents have all been updated over time -- check online before starting the upgrade to make sure that you have the most recent version!
Most of this consists of patching, but there are a couple of major changes on the IDM side, namely, the upgrade of the IDM Suite to 18.104.22.168.0 from 22.214.171.124.0 which in turn requires the upgrade of WLS in the IDM domain to 10.3.6.
The RUP2 binaries on eDelivery originally included the wrong copy of the IDM Suite installer (version 126.96.36.199.0 instead of the required 188.8.131.52.0). This has been corrected for the Oracle Linux distribution, but not as yet for some other platforms (e.g., AIX). This means that one will need to separately download the correct version from eDelivery. Once everything is downloaded and ready to go, it's worth going through the binaries to identify where the IDM-specific patches are to avoid having to search for them later. For the examples in this article, everything was unpacked to "/u01/backup/rup2" on the server:
Note that the last patch (13477091) is an OAM 10g patch for WebGate and is not applied with OPatch but run as a standalone executable.
In a similar vein, the document references some common paths, and the example paths in the doc do not reflect the paths that are specified in the Enterprise Deployment Guide. The following examples conform to the suggested paths in the EDG:
Again, this is an exercise worth doing before beginning to make the upgrade steps go a little more quickly.
The upgrade document divides the tasks into 13 steps, and some specific comments below will highlight the steps where issues have been encountered or where some clarification was warranted. For example, there are four patches (13797139, 13642895, 13686287 and 13579026) that one is instructed to apply in Step 6 and then again in Steps 7 and 8. The reason for this is that the document assumes a very generic deployment where the IDM Suite, the IAM Suite and the Web Tier were installed to separate middleware homes. If, for example, all components share the same home, then one need only apply the four patches once.
Do not neglect this step! Upgrading FA is a large and complex effort and there are many instances when restoring from backup becomes necessary.
This step can and should be done before this point, as the required downloads are listed in the Release Notes.
Note that one can wait until Step 7 to apply those four patches discussed above if there is a single middleware home.
Remember that if the initial installation followed the EDG, the IDM and IAM nodes are one and the same and one has already upgraded WLS (and don't need to do it again).
There are two things that may occur when applying this patch. The first is an error from OPatch saying that this patch conflicts with patch 12961473. This is a known issue and the fix is to simply roll back patch 13399365 and then reapply it. The second was the deployment the new weblogic.profile file. There were some unfamiliar parameters that needed to be given values, and here is a copy of what it should look like for FA:
# For passwords if you dont want to put password </optional> in this file just comment it out from here, you will be promted for it in rumtime. #Neccessary env variables [Mandatory] ant_home=/u01/app/oracle/product/fmw/modules/org.apache.ant_1.7.1 java_home=/u01/app/oracle/product/fmw/jrockit-jdk1.6.0_24 mw_home=/u01/app/oracle/product/fmw oim_oracle_home=/u01/app/oracle/product/fmw/iam #DB configuration variables [Mandatory] operationsDB.user=FA_OIM # Database password is optional. if you want to give it on terminal itself leave it commented. Otherwise uncomment it. OIM.DBPassword=Welcome1 operationsDB.driver=oracle.jdbc.OracleDriver operationsDB.host=idmdbhost.mycompany.com operationsDB.serviceName=oimedg.mycompany.com operationsDB.port=1521 appserver.type=wls isMTEnabled=false # If you have milty-tenancy enabled in your environment mdsDB.user=<MDS DB Schema owner> #Password is optional, if you want to give it on terminal itself leave it commented. Otherwise uncomment it. #mdsDB.password=<MDS DB Schema password> mdsDB.host=<MDS DB Host> mdsDB.port=<MDS DB port> mdsDB.serviceName=<MDS DB ServiceName> #For domain level configurations [Mandatory] # put here your admin server related credentials weblogic_user=weblogic #Password is optional, if you want to give it on terminal itself leave it commented. Otherwise uncomment it. weblogic_password=Welcome1 weblogic_host=servername weblogic_port=7001 weblogic.server.dir=/u01/app/oracle/product/fmw/wlserver_10.3 #oim specific domain level parameters [Mandatory] oimserver_host=servername oimserver_port=14000 oim_managed_server=wls_oim1 oim_domain_dir=/u01/app/oracle/admin/IDMDomain/aserver/IDMDomain isSODEnabled=false #SOA specific details [Mandatory] soa_home=/u01/app/oracle/product/fmw/soa soa_managed_server=wls_soa1 soaserver_host=servername soaserver_port=8001 #put here the name of the targets of taskdetails. in non cluster it will be soa server name and in cluster it will be something like cluster_soa taskdetails_target_name=cluster_soa isOHSEnabled=false #Following params is needed only if you have enabled OHS in your env ohs_home=/u01/app/oracle/product/fmw/web #If your env is FA, you can set this var false or ignore this if your env is non FA. isFAEnabled=true
The patch_weblogic.sh script is in the same directory as weblogic.profile. You may see an error in the last step that it runs, and this seems to be due to the fact that the script tries to deploy a SOA composite before the server is fully up. This is another known bug, and the easiest fix is to check for undeployed composites and manually deploy them.
Most of this consists of patching, but one will also upgrade the WebGates to 11g from 10g. In addition the FA database is upgraded to 184.108.40.206, and while this is mandatory for the FA DB it is optional for the IDM DB for RUP3, but will be mandatory for later releases. For that reason alone, if you are going to upgrade the IDM DB as well, it is recommend that this be done after the overall upgrade is complete and validated.
Once again, one should map the homes as above to have those paths readily available, and locate the patches in the RUP3 binaries before rather than during the upgrade:
Patch 12575078, which contains Oracle Access Manager WebGates (220.127.116.11.0)
Patch 13453929 for Oracle Access Manager WebGates
Patch 13735036 for Oracle Identity Manager
Patch 13768278 for IDM Tools. Note: Be sure you download the 18.104.22.168.0 version of this
patch, which is named p13768278_111150_Generic.zip.
Patch 13787495 for Oracle Access Manager Config Tool
Patch 13879999 for Oracle Internet Directory
Patch 13893692 for Oracle SOA Manager
/u01/rup3/installers/oracle_common/patch/13893692 < for ORACLE_COMMON_HOME
/u01/rup3/installers/soa/patch/13893692 < for SOA_HOME
Patch 13901417 for Oracle Access Manager
Important Note: Patch 13893692 has two parts that are applied separately to different homes, and the two parts are in different directories.
Finally, when installing the 11g WebGate(s), one will need a couple of specific gcc libraries present. You can build these from scratch by downloading the source from GNU, but they are also available via the Oracle public yum server:
yum update libgcc mkdir /u01/app/oracle/product/fmw/gcc_lib cd /u01/app/oracle/product/fmw/gcc_lib ln -s /lib64/libgcc_s-4.1.2-20080825.so.1 ./libgcc_s.so.1 ln -s /usr/lib64/libstdc++.6.0.8 ./libstdc++.so.6
This will need be needed for Step 9.
The same applies here as above -- there are 14 steps in this document with a special section that applies specifically to Solaris.
When patch 13893692 is applied, one will get a message stating that it is already present.
This is where the gcc libraries are needed -- from the installer, specify the path that contains the symbolic links above (e.g., /u01/app/oracle/product/fmw/gcc_lib) for the location of the gcc libraries. The file names have to match those above exactly.
In the new httpd.conf file, you may need to add the following lines to ensure that all logins work as they previously did:
You may need to add one line to httpd.conf to ensure that login works correctly:
#*******Default Login page alias*** Alias /oamsso "/u01/app/oracle/product/fmw/oam/webgate/access/oamsso"
If one is careful and methodical, there shouldn't be any issues encountered for the IDM part of the upgrade. The two upgrade documentss, while a bit confusing in some respects, are complete and should work