Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Admiral Admiral
Admiral
606 views

OBM: Errors related to self-monitoring when OA tries connecting to DB with ´SERVERNAME$´

Jump to solution

Hi all,

Not a new problem; when OBM service is running with a dedicated service account and DB is set up with windows authentication, OA fails in running some scripts/policies because of no access to DB.

Ex:
"Health notification for 12.12.010 opcmona: Failed Health Parameters :Perl_Script_Execution."

opr-clis.log:
"Login failed for user '<DOMAIN>\<SERVERNAME>$" 

From the OA 12.12 doc:
"Operations Agent, after installation, starts running with the Local System account on Windows nodes and with the root account on the UNIX/Linux nodes. You can, however, configure the Operations Agent to run with a non-default user that has fewer privileges than the root or Local System user.

You can run only the Operations Monitoring Component with a non-root/non-Local System user and the remaining components with the default root/Local System user."

Anyone knows how to do the last part, run only "Operations Monitoring Component" with a non-Local System user on Windows? 

Any other suggestions are also welcome. 

1 Solution

Accepted Solutions
Fleet Admiral Fleet Admiral
Fleet Admiral

you can save yourself the trouble with the support.  gone through this. its just waste of time

As you have windows auth there are only 2 solutions.

1) run agent with a user that has access priviledges to MSSQL

2) allow SERVERNAME$ to access the MSSQL DB

We have gone for 1) . Remeber to grant local admin rights to the user account. else you run into other troubale.

View solution in original post

11 Replies
Fleet Admiral Fleet Admiral
Fleet Admiral

https://docs.microfocus.com/itom/Operations_Agent:12.14/ChangingDefaultUserWindows

Documentation on this is not really great but using the ovswitchuser script is similar to description in unix.

Other solution is to allow on MSSQL side the "SERVERNAME" to access the DB. As no user/password is given the scripts fallback to "SERVERNAME" for authentification.

Be aware that its a good idea for the user account you use for running the agent to gvie local admministrative priviledges. Else you run into other issues with automatic actions, and of course policies accessing Windows eventlog ...

 

Admiral Admiral
Admiral

Andreask, thanks for feedback.

Maybe this can be a solution, if "Operations Monitoring Component" covers self-monitoring. 

"To run only the Operations Monitoring Component with a non-Local System account:

%OvInstallDir%bin\win64\ovconfchg -ns eaagt -set MODE MIXED"

0 Likes
Micro Focus Expert
Micro Focus Expert

My understanding is that MODE_MIXED is a OA12 option usualy means the performance component runs using different permissions than the EA part, meaning it has enough permissions to access the the kernel or /proc. 

I think it would be helpful to define the problem as what is failing.  Your problem comes from opcmona which is running a command which errors in opr-clis.log.  So, that's a command line tool or opr-jmxUtil which is embedded in the perl script.

Do you know which policy is failing? 

Ciao, CT.

0 Likes
Admiral Admiral
Admiral

The main thing is to fix the problem with the Perl script failing.
I often see error in processing "OMI CiCacheUsage" and "OMi Event Statistics" around the same time as the event on failed Perl script. 

This may be two separate problems so need to sort the problem with the Perl script first. But from what you describe I understand that switching user as described probably isn´t relevant.
Any other suggestions?

0 Likes
Micro Focus Expert
Micro Focus Expert

it's not the perl script.  I'm sure that's fine.  The problem is the perl script runs a command and it's this command which errors and updates opr-cli.log.  Which policy is it?  If we know what it's doing there is a change of fixing it.  CT.

0 Likes
Admiral Admiral
Admiral

OK, erase and rewind 🙂

The problem is that OA runs with Local System and tries to access the OBM DB (for instance for the mentioned Perl script). Since we use remote MS SQL with Windows auth. and a dedicated service account for the OBM services, access to the DB is denied for OA/OPR. Therefore a lot of entries in ´opr-clis.log´ related to this.

Known problem, and I cannot see that MF has any solution to this. Have a support case, but not much progress.

0 Likes
Fleet Admiral Fleet Admiral
Fleet Admiral

you can save yourself the trouble with the support.  gone through this. its just waste of time

As you have windows auth there are only 2 solutions.

1) run agent with a user that has access priviledges to MSSQL

2) allow SERVERNAME$ to access the MSSQL DB

We have gone for 1) . Remeber to grant local admin rights to the user account. else you run into other troubale.

View solution in original post

Micro Focus Expert
Micro Focus Expert

what's the policy name?  I'm interested now.

0 Likes
Admiral Admiral
Admiral

Good suggestion to run the agent with a user with both access to the DB and sufficient rights locally, will try that.

Think that is the only practical solution, don´t think Local System Acc can access remote resources that requires password no matter how DB access is defined.

0 Likes
Fleet Admiral Fleet Admiral
Fleet Admiral

dont remember but may be i can find the Case number. its documented there

0 Likes
Admiral Admiral
Admiral

Ended up with alternative 2, works fine.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.