Tuesday, March 23, 2010

upgrade oracle application 11i RDBMS 9i to 10gR2

COmming soooonnnnnn

Oracle E-Business Suite 11i Configuration in a DMZ

DMZ (demilitarized zone) configuration for iRecruitment
Oracle E-Business Suite 11i Configuration in a DMZ
Please note that we are taking AIX as an example OS (operating system) for the setup. In theory this can be setup for any OS that support Oracle Apps 11i.
DMZ Setup System Requirements:
1) External EBS Server:
Model: AIX
Host Name: external.shahab.com
IP Address: 192.168.1.1
OS: AIX
OS User: applmgr
2) Internal EBS Server
Model: AIX
Host Name: internal.shahab.com
IP Address: 192.168.1.2
OS: AIX
OS User: applmgr
3) Database Server
Model: AIX
Host Name: dbhost.shahab.com
IP Address: 192.168.1.3
OS: AIX
OS User: oracle

External Applications Web Tier
The external applications web tier is the server configured for external users for accessing Oracle E-Business Suite. It runs the following application service:
• Web server
Internal Applications Middle Tier
The internal applications middle tier is the server configured for internal users to access Oracle E-Business Suite. It runs the following major application services:
• Web and Forms Services
• Administration and Concurrent Manager Services
• Reports and Discoverer Services
RDMBS (Database) Tier
The internal RDBMS tier is the server configured for internal users to access Oracle E-Business Suite Database. It runs the following major services:
• Listener
• Database
Proposed DMZ Configuration Architecture


Image taken from metalink note:287176.1
Design Considerations, Assumptions, Limitations:
When configuring Oracle E-Business Suite in a DMZ configuration, firewalls are deployed at various levels to ensure that only the traffic that the architecture expects is allowed to cross the firewall boundaries. The firewalls ensure that if intrusion attempts against machines in the DMZ are successful, the intrusion is contained within the DMZ and the machines in the intranet are not affected. To make Oracle E-Business Suite modules as secure as possible, the following tasks may need to be performed.
• Use of separate web node for external usage
• Setting of server level profile values
• Associate trust levels to application middle tier nodes
• Mark a subset of responsibilities as available on an external web node
• Deploy a Reverse proxy in front of the external web node
• Configuring a URL firewall and mod security in the reverse proxy
• Run only the required Oracle E-Business Suite Application services on the external web tier
Pre-requisite Patches:




References:
287176.1 – DMZ Configuration with Oracle E-Business Suite 11i
364439.1 – Tips and Queries for Troubleshooting Advanced Topologies

1. Creation of the External WebServer
Clone the internal Oracle E-Business suite middle tier to the machine that you identified to be the external web tier in the DMZ. Sharing file systems between the external web tiers and the internal middle tiers is not supported in any deployment option. However, sharing file systems (following the document sharing file system which I given to you ) such as APPL_TOP between multiple external web tiers or between multiple internal middle tiers supported.
2. Update Hierarchy Type

The following profile options are used to construct various URLs in an E-Business Suite 11i environment:

• Applications Web Agent
• Applications Servlet Agent
• Applications JSP Agent
• Applications Framework Agent
• ICX:Forms Launcher
• ICX: Oracle Discoverer Launcher
• ICX: Oracle Discoverer Viewer Launcher
• Applications Help Web Agent
• Applications Portal
• BOM:Configurator URL of UI Manager
• ASO : Configurator URL
• QP: Pricing Engine URL
• TCF:HOST
The default hierarchy type value for the above profile options is Security.




The Configuration of EB Suite environment for DMZ requires these profile options hierarchy type to set to SERVRESP. To change the profile options hierarchy type values to SERVRESP, execute the following sql script.
1. sqlplus apps/apps-passwd @$FND_TOP/patch/115/sql/txkChangeProfH.sql SERVRESP
2. After successfully completing the above sql script, run Autoconfig in all nodes to complete the profile options configuration.

3. Update Node Trust Level
Oracle E-Business Suite 11i has the capability to restrict access to a predefined set of responsibilities based on the Web server from which the user logs in. This capability is provided by tagging web servers with a trust level. The server trust level indicates the level of trust associated with the web server. Currently, three trust levels are supported:

(i) Administrative
Servers marked as Administrative are typically those used exclusively by system administrators. These servers are considered secure and provide access to any and all E-Business Suite functions.
(ii) Normal
Servers marked as Normal are those used by employees within a company’s firewall. Users logging in from normal servers have access to only a limited set of responsibilities.
(iii) External
Servers marked as External are those used by customers or employees outside of a company’s firewall. These servers have access to an even smaller set of responsibilities.
Node Trust Level (NODE_TRUST_LEVEL) is a server profile option. The default value for this profile option for all E-Business Suite middle tiers is set to Normal.
Identify the external web tier in your Oracle E-business Suite 11i environment and set the NODE_TRUST_LEVEL profile option value at the server level to External. To change the value of the Node Trust Level profile option value for a particular node, perform the following steps:
1. Login to Oracle E-Business Suite as sysadmin user using the internal URL
2. Select System Administrator Responsibility
3. Select Profile / System
4. From the ‘Find system profile option Values’ window, select the server that you want to make external
5. Query for %NODE%TRUST%. You will see a profile option named ‘Node Trust Level‘. The value for this profile option at site level will be Normal. Leave this setting as is
6. Set the value of this profile option to External at the server level (not site level). The site-level value should remain Normal.




4. Update List of Responsibilities
It’s possible (and recommended) to restrict the general set of Applications Responsibilities based on the application server that you’re using. For example, there should be no reason to allow external users to modify your company’s Chart of Accounts, so that responsibility can’t be used if the end-user is logging in from outside the corporate intranet. After updating the server-level profile value for Node Trust Level for the external web tier(s) to External, users can no longer see any responsibilities when they login to the external web tier. In order for a responsibility to be available from the external E-Business Suite web tier, set the Responsibility Trust Level profile option value for that responsibility to External at the responsibility level.To change the value of the Responsibility Trust Level profile option at the responsibility level for a particular responsibility, perform the following steps:
1) Login to Oracle E-Business Suite as sysadmin user using the internal URL
2) Select System Administrator Responsibility
3) Select Profile / System
4) From the ‘Find system profile option Values’ window, select the responsibility that you want to make external
5) Query for %RESP%TRUST%. You will see a profile option named ‘Responsibility trust level‘. The value for this profile option at site level will be Normal. 6) Set the value of this profile option for the below responsibilities to External at responsibility level (not site level). The site-level value should remain Normal.


a) iRecruitment External Candidate

5. Update Home Page Mode to Framework
The new Oracle E-Business Suite 11i Home page based on the Oracle Applications Framework architecture is required for the deployment of the Oracle E-Business Suite in a DMZ configuration. To enable this set the self-service personal home page mode to “Framework Only” as shown in the diagram below.
To change the value of the Home page mode, perform the following steps:
1. Login to Oracle E-Business Suite as sysadmin user using the internal URL
2. Select System Administrator Responsibility
3. Select Profile / System
From the ‘Find system profile option Values’ window, query for %HOME%MODE%. You will see a profile option named ‘Self Service Personal Home Page Mode‘ , set the value of this profile option to Framework Only.



6. Configuration Details for using Reverse Proxies in DMZ
7. Update Oracle E-Business Suite Application Context file
On the external Oracle E-Business Suite web node, run the AutoConfig Context Editor as documented in the Oracle MetaLink Note 165195.1 "Using AutoConfig to Manage System Configurations with Oracle Applications 11i". In the Context Detail screen, set the following configuration values:
• set the webentry point, s_webentryhost, to the reverse proxy server.
• set the webentry domain, s_webentrydomain, to the domain name of the reverse proxy server.
• set the active webport, s_active_webport, to the port where the reverse proxy server listen for client requests. For example port 80 for HTTP or 443 for HTTPS.
• set the webentry protocol, s_webentryurlprotocol, to the protocol value the clients use to access the reverse proxy server.
• set the login page, s_login_page, to ://.:. Replace , , , and with their respective values.
8. Create a new Context File for the External Entry Point
To create a context file for the external entry point, execute the commands shown in the table below:
$ perl $COMMON_TOP/clone/bin/adclonectx.pl \
contextfile= \
outfile=
For example:
Internal Server Name: internal.shahab.com
External Server Name: external.shahab.com
Context file for Internal Entry Point including its location: /d1/applmgr/visappl/admin/VIS_internal.xml
Context file to be created for External Entry Point including its location: /d1/applmgr/visappl/admin/VIS_external.xml
Database ID: VIS
For the above given example, you will enter the command as
$ perl $COMMON_TOP/clone/bin/adclonectx.pl \
contextfile= /d1/visappl/admin/VIS_internal.xml \
outfile=/d1/visappl/admin/VIS_external.xml
The script will prompt for various inputs from the user as shown in the table below.
please note that the default prompt values are provided for reference purpose
only and may not reflect the actual values in your environment.
After you provide all the required inputs, the clonectx utility will proceed and create the new context file for the external entry point at the location specified in the command
9. Verify and Update the New Context File Created for the External Entry Point
Table given below gives a list of AutoConfig variables that need to be reviewed and edited if required



10. Instantiate New Configuration Files for the External Entry Point
1. Execute the Shared Oracle Home configuration script ( txkSOHM.pl ) as shown below to instantiate the required http server configuration files to a location of your choice.
$ cd $FND_TOP/patch/115/bin

$ perl txkSOHM.pl

The script will prompt the user for the following inputs:
Absolute path of Application's Context XML file : created for the external entry point including its name>
Type of Instance [primary/secondary] : secondary
Absolute path of 8.0.6 Shared Oracle Home :
Absolute path of iAS Shared Oracle Home :
Absolute path of config top: the configuration files for the external entry point. Always
remember to choose a new location as the configuration top
can not be shared between multiple instances>
Oracle Application apps schema password:
For example:
Context file for External Entry Point including its location: /d1/applmgr/visappl/admin/VIS_external.xml
Absolute path of 8.0.6 Shared Oracle Home : /d1/applmgr/visora/8.0.6
Absolute path of iAS Shared Oracle Home : /d1/applmgr/visora/iAS
Absolute path of config top : /d1/applmgr/viscomn/conf/VIS_external
Database ID: VIS
For the example given above, you will enter the value as shown below:
Absolute path of Application's Context XML file : /d1/applmgr/visappl/admin/VIS_external.xml
Type of Instance [primary/secondary] : secondary
Absolute path of 8.0.6 Shared Oracle Home : /d1/applmgr/visora/8.0.6
Absolute path of iAS Shared Oracle Home : /d1/applmgr/visora/iAS
Absolute path of config top : /d1/applmgr/viscomn/conf/VIS_external
The script will run autoconfig at the end which will generate a new scripts directory under
$COMMON_TOP/admin/scripts . You can use the scripts created under this new directory to start/stop
services for the external entry point.
Please note that you only need to run the main HTTP and the HTTP listener for the pl/sql requests
for the external entry point. All the other services can be disabled. Please refer to
appendix
I. Disabling E-Business Suite 11i Application Services on the External Web Tier for instructions to disable a service.
You can also refer to Oracle MetaLink Note 438744.1 Case History: Implementing a Reverse Proxy Alone in a DMZ Configuration for more detailed verbose instructions on implementing this toplogy.

8. Enable Oracle E-Business Suite Application Server Security.
The Server Security feature supports authentication of application server machines and code modules in order to access the database. When Server Security is activated, Application Servers are required to supply server IDs (like passwords) and/or code IDs to access a database server. Server IDs identify the machine from which the connection is originating. Code IDs identify the module and patch level from which the connection is originating. Code IDs are included in applications code by development. The database server can be set to allow access only from specific machines and/or by code at a desired patch level.
The application server security feature is not activated by default for pre 11.5.10 E-Business Suite installations.
1. Set the value of Application Server Security Authentication (s_appserverid_authentication) to SECURE
2. Run AutoConfig on each Applications middle tier to complete the configuration
3. After AutoConfig completes successfully, restart the Oracle HTTP server.
4. http.conf set URL == …comn_TOP/conf/context_file/Aapche/.../http.conf
5. url.fw.conf ====== iRec remove # remarks
6. Run AutoConfig and Restart Oracle HTTP Server.
 Run AutoConfig on External Server.
• cd $COMMON_TOP/admin/scripts/$CONTEXT_NAME
• adautocfg.sh
First run RDBMS & Listener
Second start internal apps service
Third start only http services on external
And check the URL
http://external.shahab.com:8000/OA_HTML/IrcVisitor.jsp


Syed Shabuddin

Oracle application DBA

How to change APPS password in 11.5.10.2 & R12

How to change APPS password in 11.5.10.2 & R12

Oracle Application 11i and R12, we have an FND functionality for changing the passwords for either application user, or product schema password or most important – the “APPS” password. The FND binary which will help us is doing these things is FNDCPASS.

This is present in $FND_TOP/bin directory.
This post explains the usage of FNDCPASS, best practices that needs to be followed while using FNDCPASS and some tricks when FNDCPASS screws up the instance )
Using FNDCPASS
Below is the usage for FNDCPASS
$ source environment for example $SOURCE APPSORA.env
$ FNDCPASS (FNDPASS Utility)Usage: FNDCPASS logon 0 Y system/password mode username new_passwordwhere logon is username/password[@connect]system/password is password of the system account of that databasemode is SYSTEM/USER/ORACLEusername is the username where you want to change its passwordnew_password is the new password in unencrypted formatexample FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS SHAHAB

FNDCPASS apps/apps 0 Y system/manager ORACLE GL SHAHAB12

FNDCPASS apps/apps 0 Y system/manager USER VISION SHAHAB1
You can just type FNDCPASS and press enter, it will give you these details.
The first usage
FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS SHAHAB is for changing the password for apps and applsys. These are the database schema users (most important for application to work). Password for both these users should be in synch. You can change the password of these users using this command. Note that this is the only way to change the password for apps and applsys. Please do not try any other method for changing apps and applsys password. Oracle recomends using FNDCPASS only to change apps and applsys password. Also note that using this command will change the password for both apps and applsys.
Following activities will take place
(1) applsys validation. (make sure APPLSYS name is correct)

(2) re-encrypt all password in FND_USER

(3) re-encrypt all password in FND_ORACLE_USERID

(4) update applsys’s password in FND_ORACLE_USERID table.

(5) Update apps password in FND_ORACLE_USERID table.
Also changes are made in DBA_USERS table.
The second usage
FNDCPASS apps/apps 0 Y system/manager ORACLE GL SHAHAB12 is for changing password for any other product schema like MSC, GL etc.Following activities will take place
(1) update GL’s password in FND_ORACLE_USERID table. The new password is re-encrypted with the current applsys password.
If GL does not exists, step

(2) below does not happen. Message for invalid oracle user is written in the log file.
(3) alter user to change GL’s password.

The Third usage
FNDCPASS apps/apps 0 Y system/manager USER VISION SHAHAB1is for changing the application level passwords like sysadmin etc used for logging into application.
Following activities will take place
(1) update VISION’s password in FND_USER table. The new password is re-encrypted with the current applsys password.
If VISION does not exist, message for invalid application user is written in the log file.No products affected by the patch
When you run FNDCPASS command it will check the integrity of all schema password in the application. If any of the password is corrupt then this will through and error and will not change the password.
The tables that it uses is FND_USER and FND_ORACLE_USERID. All the application passwords and schema passwords are stored in these two tables. Ofcourse DBA_USERS will have the schema users and password stored as well.
When we run FNDCPASS it will update all the above 3 tables.

Best practices for using FNDCPASS
Before using FNDCPASS and changing the passwords from default to some thing else, always follow the following best practices.
1) Always, Always, Always keep the back of tables FND_USER and FND_ORACLE_USERID. You can take back of these tables using CREATE TABLE — AS SELECT * FROM —.You must have backup of these tables before running FNDCPASS. In case if FNDCPASS fails then it might corrupt the passwords of your application and worst can happen that the application wont come up. So always be cautions about this command.
2) If possible also keep an export dump of these two tables.
3) verify each arguement you are providing to FNDCPASS. Like verify that apps and system passwords you are providing is correct.
4) Never update apps, applsys or any schema password directly from database using the alter command. Always use FNDCPASS. System password can be set directly using ALTER command in database.

NOTE 4: VERY IMPORTANT:-
When changing the password for APPS it is important to manually change the APPS
password in the following files as well as necessary:


1. $ORACLE_HOME/listener/cfg/wdbsvr.app file as well. Otherwise users will not be able to login to the Personal Home Page or Self-service web apps.

2.This may also be necessary in the $IAS_ORACLE_HOME\Apache\modplsql\cfg\wdbsvr.app file

3. Workflow Notification Mailer - $FND_TOP/resource/wfmail.cfg

4. The concurrrent manager start script.4. $OA_HTML/bin/appsweb.cfg

5. $AD_TOP/admin/template/CGIcmd.dat may contain the password if it is being used.Please refer to note:159033.1 How to Setup Oracle Reports in Portal to Use CGICMD.DAT File

6. If you instance is Multi-node and Autoconfig enabled, it may be necessary to invoke Autoconfig to implement the above changes.

Once these updates are done, try your luck by running FNDCPASS and it should work fine.
Hope this help !!!
References
Metalink note ID 159244.1
Metalink note ID 445153.1
Metalink note ID 429244.1

Syed Shabuddin

Oracle Apps-DBA