Documente Academic
Documente Profesional
Documente Cultură
Issue - ERP is not opening and giving 500 Internal Server Error, adadmin, FNDCPASS not working
because of password corruption, autoconfig not completing successfully, Connecting to
database with apps and applsys, but not able to work on adutiliites
Sequence followed
1. As ERP is not opening and showing internal error, checked error and access log files of Apache and
opmn error log files, application.log files.
3. Made some changes in configuration files to collect debug information, a we have not found any
thing in log files from application, access, error and opmn and ran autoconfig, autoconfig did not
completed successfully. Checked autoconfig log files
4. Made aolj.test
5. Tried to disable maintainence mode, but adadmin is not working and throwing error
AD Administration error:
DCPW null for "APPLSYS" [0]
AD Administration error:
Failed getting PDI list for product 'fnd'
AD Administration error:
aipspv(): Error setting up PDI list for upgrade
6. Tried to change password of apps and applsys through FNDCPASS, but it also showed error
FNDCPASS was not able to decrypt password for user 'ANONYMOUS' during applsys password
change.
FNDCPASS was not able to decrypt password for user 'AUTOINSTALL' during applsys password
change.
FNDCPASS was not able to decrypt password for user 'CONCURRENT MANAGER' during applsys
password change.
FNDCPASS was not able to decrypt password for user 'GUEST' during applsys password change.
......
......
FNDCPASS was not able to decrypt password for user 'ODM' during applsys password change.
FNDCPASS was not able to decrypt password for user 'APPS' during applsys password change.
FNDCPASS was not able to decrypt password for user 'APPLSYS' during applsys password change.
---------------------------------------------------------------------------
Concurrent request completed successfully
Referred -
Changing APPS Password Using FNDCPASS Gives 'not able to decrypt password' Message [ID
733427.1]
Tried To Change Apps Password And A "Not Able To Decrypt" Message Came Up [ID 459601.1]
FNDCPASS Was Not Able To Decrypt Password For Applsyspub When Changing Apps Password [ID
454299.1]
Solution -
Steps 1 through 4 are run on the database server running as the Operating System user, "oracle",
using "sqlplus" connected as the "SYS" or "APPS" database user
Step 5 is run as the Operating System user "applmgr" on an application tier and uses
the "FNDCPASS" command line utility.
Step - 1
$ export ORACLE_SID=<sid>
$ export ORACLE_HOME=<db-oraclehome>
$ export PATH=$ORACLE_HOME/bin
$ unset TWO_TASK
REM One more time for luck (avoid session caching of profiles)
connect APPS/CLONE
REM Set SYSADMIN password
select APPS.fnd_web_sec.change_password('SYSADMIN','CLONE') "RES"
from dual;
commit;
exit
Step 3 -
Prepare steps for setting additional scripts
In this step scripts are prepared to assign passwords to the other database users which were disabled
in Step 1. Dynamically generated scripts are used to accomplish this because the set of database users
may differ between instances of EBS. Create the script below and run it as the Operating System user
"oracle":
REM Prepare SQL and SHELL scripts to set more passwords later
spool step3.lst
REM Generate a sql script to set password for db users not managed with EBS
REM Generate a shell script to set password for all base product schemas
REM Generate a shell script to set password for non-EBS db users managed
with EBS
select 'FNDCPASS apps/clone 0 Y system/clone ORACLE "' ||
replace(ORACLE_USERNAME,'$','\$') || '" clone'
from APPLSYS.FND_ORACLE_USERID
where READ_ONLY_FLAG = 'X'
and ORACLE_USERNAME in (select USERNAME from SYS.DBA_USERS);
spool off
exit
Step 4 -
Assign new passwords to all database users not managed with EBS
This Step runs the SQL script, "dbusers4.sql", generated in Step 3.
Sample content of "dbusers4.sql" listed below for illustration purposes only, you must run the
one you generated on your system
Connect as sysdba
sqlplus / as sysdba
sql>spool step4.lst
sql>dbusers4.sql
sql>exit
The output spool file should show many output lines stating "User altered.". No error messages
(ORA-nnnnn) should appear.
At this point, the database should be started and running. Stop and restart the database at this time. To
ensure that the application tier code can access the database for Step 5, you must also ensure that the
database TNS-listener service is running.
You will need to locate and copy the "dbusers5.sh" script from the directory where it was created
in Step 3. Again, as with any dynamcially generated scripts that you run on your system, you should
review the contents of the file before running it.
To run "FNDCPASS" you also need a number of environment variables set, at a minimum
ensure that:
"FNDCPASS" is in the "$PATH" ("$ which FNDCPASS" will tell you if it is.)
The "TWO_TASK" environment variable is set to a value that can be resolved via
the "$TNS_ADMIN/tnsnames.ora file", in order to access the clone target database.
# Verify that the Oracle client environment is set to correct database (as
"applmgr" OS user)
SYSDATE NAME
--------- ---------
25-JUL-07 PRD12
The following is sample content of a "dbusers5.sh" file is listed below for illustration purposes
only, run the one you generated on your system
To verify that you have assigned passwords to all the database users, run the following query and
ensure that it does not return any rows:
What remains to be done is to set new passwords for additional applications users or the creation of
new test users, depending on your needs. Changing passwords for applications users can be done using
the "Define User" form (logged on as "SYSADMIN/CLONE") or by running "FNDCPASS" with the
below syntax from an "applmgr" applications shell environment.
applmgr$ FNDCPASS apps/clone 0 Y system/clone USER <username> <password>
Step 6 -
Step 7 -
Run Autoconfig