Oracle has introduced encryption of the apps password in the registry value CCMCONNSTRING. I do not know exactly which patch introduces this change - FND.H / ATG.H / ATG.H RUP 4/ AD.I.4. Earlier the value used to be stored in an unencrypted fashion and once the apps password was changed, the DBA could manually go and update this value in plain text. This registry value is used by the concurrent managers at startup.
Of course, FNDCPASS would be used to change the 'APPS', 'APPLSYS' and 'APPS_MRC' passwords. However, in a multinode environment, some oracle documentation pointed out, that autoconfig needs to be run on each mid-tier, after changing the apps password using FNDCPASS on the database tier (this would require APPL_TOP to be available on db tier). The autoconfig would take care of apps password update in wdbsvr.app file and ccmconnstring registry value on the midtiers.
Autoconfig is time consuming, especially when you have more nodes and customized configuration files. So, I wanted to find an alternative to running autoconfig. After researching this problem for a little while, I came up with the following approach:
- Use CCMSETUP to update the ccmconnstring registry value.
- Manually update the wdbsvr.app file under $IAS_ORACLE_HOME/...
One can enter the password in plain text in CCMSETUP and save the changes which would in turn be saved in an encrypted format in the registry value by the CCMSETUP.
Troubleshooting Hints:
- Capture the value of ccmconnstring registry value before any change.
- In a multi-node environment, logon to a non-concurrent processing node and run the FNDCPASS.
- Capture the value of ccmconnstring registry value after the password change.
- No change in the encrypted values points to the fact that FNDCPASS does not update the ccmconnstring registry value.
- On the concurrent manager box, invoke ccmsetup and update the values and save. You will see the change in the encrypted value for ccmconnstring
- Bring up the concurrent managers and this works fine.
Thus, we achieved our goal of not running autoconfig and not recreating the concurrent manager service.
- Aravind Kamath
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
Thanks for the post and I found this is the only post talking about the problem which I am facing. Let me tell you in brief I have a situation to generate encrypted apps password for my new password for the apps. The reason is simple that FNDCPASS is not changing this password in CCMCONNSTRING registry entry. I tried all possible ways like running autoconfig on application tier (with env file sourced) and every possible things' Please dont say stop services and run and all. I have tried all possible ways including creating concurrent manager service using command line. But no luck. even CCMSETUP from FND_TOP\bin is showing some starange error "no less than 4 charaters" when I tried to change any thing on the window. Can any one paste here encrypted password for word s1mple. Yes s1mple is my new pass for apps. My installation is 11.5.10.2 (RUP 6) on windows XP SP3.
Unfortunately, I no longer work on apps on windows platform. However, as I mentioned ccmsetup should do the trick. If you update the password in plain text, the ccmsetup should update the apps password in the registry. Now, creating the service will not involve apps password if i remember correctly. It will only involve the Windows user account with which the service will run.If the CCMSETUP is not working, login to the console as administrator (or the service owner for CM) and then try. Btw, running autoconfig should have taken care of this. So, review the autoconfig log to see if this was done. I am just trying to point the direction as I dont have the error logs or the necessary details to see what might be causing the issue.
HTH
Aravind
Post a Comment