CCMCONNSTRING Registry Value Encryption - Password Change Scenario

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