Back with another quick blog that was inspired from a post on the OTN forum, the poster raised an issue when changing the account to manage the OPMN windows service.
The issue relates to starting the Essbase OPMN service but I believe it is valid for any of the 11.1.2.x EPM OPMN services.
After the initial configuration of Essbase an OPMN windows service will be created and set to be controlled by the Local System account.
Say you change the Log On account for the service to different account to the one that configured Essbase, the issue will not occur if it is the user that configured Essbase which I will explain why shortly.
Attempting to start the service should now fail with the standard timeout message.
The first place to look if any OPMN type issues occur for Essbase is logs located at
<MIDDLEWARE_HOME>\user_projects\<instancename>\diagnostics\logs\OPMN\opmn
As the OPMN process did not start then the log to check first is opmn.log and it should reveal the following information:
[opmn] [ERROR:1] [] [ons-secure] Failed to open wallet (file:E:\Oracle\Middleware\user_projects\essbase\config\OPMN\opmn\wallet) [default password] (28759)
When OPMN starts it attempts to access the Oracle wallet file cwallet.sso in the above location and fails, so why does it fail well if you check the security properties of the file you will see.
The only accounts that have access to the file are the SYSTEM user and the user that originally configured Essbase which in my case is FUSION so the user that I configured to start the OPMN service will not have access to the file which ends up causing the failure.
The OPMN service should now start without any problems.
The issue relates to starting the Essbase OPMN service but I believe it is valid for any of the 11.1.2.x EPM OPMN services.
After the initial configuration of Essbase an OPMN windows service will be created and set to be controlled by the Local System account.
Say you change the Log On account for the service to different account to the one that configured Essbase, the issue will not occur if it is the user that configured Essbase which I will explain why shortly.
Attempting to start the service should now fail with the standard timeout message.
The first place to look if any OPMN type issues occur for Essbase is logs located at
<MIDDLEWARE_HOME>\user_projects\<instancename>
As the OPMN process did not start then the log to check first is opmn.log and it should reveal the following information:
[opmn] [ERROR:1] [] [ons-secure] Failed to open wallet (file:E:\Oracle\Middleware\user_projects\essbase\config\OPMN\opmn\wallet) [default password] (28759)
When OPMN starts it attempts to access the Oracle wallet file cwallet.sso in the above location and fails, so why does it fail well if you check the security properties of the file you will see.
The only accounts that have access to the file are the SYSTEM user and the user that originally configured Essbase which in my case is FUSION so the user that I configured to start the OPMN service will not have access to the file which ends up causing the failure.
The simple solution is to add the account with read permissions to the wallet file.
[opmn] [NOTIFICATION:1] [90] [ons-internal] ONS server initiated [opmn] [TRACE:1] [522] [pm-internal] PM state directory exists: E:\Oracle\Middleware\user_projects\epmsystem1\config\OPMN\opmn\states [opmn] [NOTIFICATION:1] [675] [pm-internal] OPMN server ready. Request handling enabled [opmn] [NOTIFICATION:1] [667] [pm-requests] Request 2 Started. Command: /start [opmn] [NOTIFICATION:1] [662] [pm-process] Starting Process: Essbase1~EssbaseAgent~AGENT~1 (528287129:0) [opmn] [NOTIFICATION:1] [665] [pm-process] Process Alive: Essbase1~EssbaseAgent~AGENT~1 (528287129:2768) [opmn] [NOTIFICATION:1] [668] [pm-requests] Request 2 Completed. Command: /start
The OPMN service should now start without any problems.
It's very likely that this error, like the similar one you get on the weblogic wallet, is due to a mismatch between Fusion libraries and Hyperion-EPM ones. Fusion installers on Windows *require* UAC to be enabled in order to correctly assess security on wallet files and modify it accordingly; the EPM installer enforces the exact opposite policy, in order to accommodate legacy components. As a result, wallets get screwed. This will not change until they eradicate those legacy components (hfm? fdm? who knows), I can only hope they stop adding new wallets until then.
ReplyDelete