Friday 8 January 2016

12.2 Upgrade Driver Fails with ORA-01017: invalid username/password; logon denied


Symptoms

During the initial upgrade to EBS 12.2.0 following Oracle E-Business Suite Release Notes, Release 12.2 (Doc ID 1320300.1) , or while applying the 12.2.x CUP, an upgrade driver worker job fails with the following errors:

ERROR
-----------------------
ORA-01017: invalid username/password; logon denied
occurred while executing the SQL statement:
CONNECT AR/*****

- or -

Creating APPS_NE schema APPS_NE ...
Create user APPS_NE identified by *****
ORA-28003: password verification for the specified password failed;
ORA-20002: Password length less than 15




STEPS
-----------------------
The issue can be reproduced at will with the following steps:
1. Applying one of the 12.2 upgrade drivers
2. database connection failing because of security

Solution

1) if a password was changed without using FNDCPASS or AFPASSWD on the previous EBS release, this is not fixable as adpatch starts by saving all passwords in memory and cache them. Also, when a connection error occurs in the middle of the upgrade, since the system is at that time in-between 2 releases, the AD utilities such as FNDCPASS and AFPASSWD will not work.  The only solution is to restore from the previous EBS release (11i, 12.1.3, etc) and redo the upgrade from the start.
2) if a database password management policy that is more restrictive had been implemented, the DBA can attempt to restore the APPS or other accounts to use the DEFAULT policy which should not be restricted.  Then adctrl can be used to attempt to restart the job.  Please note that if the DBA decidd to cancel the upgrade driver by exiting completely as a failure, the patching cannot be restarted.  The following will be found in the adpatch logs if the 12.2 upgrade driver is restarted from scratch with adpatch:
Restarting from scratch a patch will NOT execute the correct upgrade steps so it will make fail later the rest of the upgrade
Do you wish to continue with your previous AutoPatch session [Yes] ?     <<< do NOT answer "No"  -- you MUST continue with the previous upgrade session in order to potentially get a successful upgrade
------------------------------------------------------------------------
If you have partially applied a patch, you must continue with your           <<< this is a critical warning -- a patch/upgrade cannot be re-applied from scratch.. the workers should be restarted using adctrl so the same session is used
previous AutoPatch session until it completes successfuly.
If you try to re-apply a patch that you have only applied partially,
AutoPatch may apply the patch incorrectly.
------------------------------------------------------------------------
You can try to "fail" the worker job and "restart" it in adctrl after having make sure there are no more policy limitations;
If restarting the worker job still is failing, there will be no other choice but to:
1) recover from before upgrading/patching
2) remove the custom security that was attached to the database default password management profiles
3) restart the upgrade from scratch

All EBS customers who have implemented custom security solutions during the running of their Production system are strongly recommended to remove these customizations before starting an upgrade.  If an error occurs during an upgrade which is related to a security customization, the system must usually be restored from a backup and the upgrade restarted from scratch as the effect of failures are unknown and generally impossible to fix because of the nature of an upgrade and of it's complexity in data dependencies.

Thanks
Srini

No comments:

Post a Comment


No one has ever become poor by giving