title: Moving Oracle Portal to a Different Infrastructure link: https://onemoretech.wordpress.com/2008/05/28/moving-oracle-portal-to-a-different-infrastructure/ author: lembobro description: post_id: 522 created: 2008/05/28 17:42:21 created_gmt: 2008/05/28 17:42:21 comment_status: open post_name: moving-oracle-portal-to-a-different-infrastructure status: publish post_type: post

Actually this problem involves changing the identity management infrastructure for an entire midtier installation. The solution could be found in the documentation, but like most Oracle issues the doc in this case are scattered and impenetrable. In a word, poorly organized and poorly written. Getting to the procedure provided below, even if you have access to MetaLink, is a nearly hopeless cause. In my case I was able to file an SR (Service Request) with Oracle Support and got put on the right track by one of their support reps.

Say you’ve got a midtier Oracle Applications 10g install, version 10.1.2.0.2, consisting of Discoverer, Forms and Portal, among other things. On installation it was pointed at a local metadata repository and infrastructure (Single Sign-On, SSO, and Oracle Internet Directory, OID) but now you need to change things so it uses the services of another infrastructure.

Easy, right? Just go to the web-based Enterprise Manager for Application Server and click through a wizard. Wrong. So wrong. Although all these pieces were built by Oracle itself from the ground up, such a straightforward approach should never be expected from Oracle, whose entire applications stack has been bound together with duct tape and covered over with lots of paint to hide the ugly parts. To successfully manage Oracle products you have to think like a Java developer whose programming logic very definitely does not trace its origin to the Golden Age of Athens.

Of course, Oracle isn’t the only company whose configuration management is not exactly user-friendly. JBoss has the same kind of problem (in the case of JBoss the very well designed interface shipped by the Apache project for Tomcat is actually replaced with something so horrible it’s a wonder that anyone actually pays for it).

Changing the infrastructure for an Oracle midtier (including Portal) is a complicated, multi-step, and most importantly, exceedingly manual process. To make this as easy as possible, I’m going to use an ordered list here. The procedure given here has been tested using a 10.1.2.0.2 midtier (Applications Server Release 2) and 10.1.4.0.1 (Identity Management Release 3) infrastructure. All the basic steps are in MetaLink Note 368419.1, and in the “Distributed Configuration Management User’s Guide” section entitled Removing an Instance From the Infrastructure After Executing the leaveFarm Command but these are so poorly organized and written that I’ll save you alot of heartache by giving you my own procedure from experience.

1. Make sure the midtier is up and running, as well as it’s existing infrastructure. Also make sure the new target infrastructure is up. Use sqlplus to confirm you can connect to both the existing and future metadata repositories.

2. Confirm that the various midtier schemae have been installed in the metadata repository for the new target (usually this happens if another midtier install has already been done against it).

3. Log in as the midtier system user. Be sure you’ve sourced (read in) the midtier environment (ORACLE_HOME, PATH including OH/bin, OH/opmn/bin, OH/dcm/bin).

4. Run dcmctl whichFarm to confirm you’re joined to the existing infrastructure.

5. Now run dcmctl leaveFarm to remove your midtier from that infrastructure farm. Run <dcmctl whichFarm` again and it shoud read back “Standalone Instance”.

6. Stop the midtier with an opmnctl stopall.

7. Go to the midtier $ORACLE_HOME/config/ias.properties file and remove the values only alongside the following definitions: IAS_Password, OIDHost, OIDport, OIDsslport, InfrastructureDBCommonName and while you’re there change “InfrastructureUse” to “false”.

8. Edit $ORACLE_HOME/j2ee/home/config/jazn.xml so that it looks like this:

`

<?xml version="1.0" encoding="UTF-8"
standalone='yes'?>
<!DOCTYPE jazn PUBLIC "JAZN Config"
"http://xmlns.oracle.com/ias/dtds/jazn-9_04.dtd">
<jazn provider="XML" location="./jazn-data.xml">
</jazn>

`

• Check $ORACLE_HOME/config/iasschema.xml to make sure that the entry for DCM looks like this:

`

<SchemaConfigData>
  <ComponentName>DCM</ComponentName>
  <BaseName>DCM</BaseName>
  <verride>false</Override>
  <SchemaName/>
  <DBConnect/DBConnect>
  <Password/>
  <SvcPassword/>
</SchemaConfigData>

`

9. Verify that sqlnet.ora under $ORACLE_HOME/network/admin in the midtier lists LDAP as one of the service resolution methods. The Note advises you to remove the LDAP method after leaving the farm, but I ran into trouble further on after doing this so I don’t recommend it.

• Changes in the LDAP entries on an OID associated with the midtier that was removed from the farm. There are basically two:

Delete

"orclApplciationCommonName=infra2,cn=IAS Instances, cn=IAS, cn=Products, cn=OracleContext

from OID.

Modify

orclApplicationCommonName=jaznadmin1,cn=JAZNContext, cn=products,cn=OracleContext"

to remove the uniquemember referrence to the old infrastructure to apps.

10. Restart the midtier (opmnctl startall) and the Enterprise Manager (emctl start iasconsole).

11. Log into the Enterprise Manager console, click on the Infrastructure tab and in the Identity Management section click on Configure. Provide the new OID server host and port, click next and give the credentials for that OID server’s orcladmin root account. Click Finish and when the page refreshes you should see the new target OID values listed.

12. Now issue a dcmctl joinFarm to join the midtier to the farm backended by the new target OID.

13. Restart the Enterprise Manager again and log back into it. Go to the Infrastructure tab and click on the big Change button under Metadata Respository. Answer the prompts for the orcladmin user dn and password, click Next and verify the Repository name in the drop-down and click Next, and then Finish again.

14. If you’re exceedingly fortunate your midtier should now be fully integrated with the new target infrastructure and with logins from applications like Portal redirected their rather than dead-ending in a 500 error.

Now unless you’ve already got an existing midtier hanging off the newly associated OID, you’ll also have to copy over your midtier-related application users and groups from the old OID. Make sure you thoroughly check the operation of all components and reconfigure where necessary to get things working.

The procedure described above deviates somewhat from both the referenced MetaLink Note and official documentation. It was arrived at after painful hours of trial and error using a pair of VMware images that had to be rolled back several times during experimentation. I’ll be using this process the next time I do this and will post any corrections here.

Copyright 2004-2019 Phil Lembo