But when I try and run it from within NNM I get a error 3 "login Failure" message. I think the problem is with the environment that NNM runs its automatic actions in. It seems to use the "default user" environment rather than the user I am logged in as. I have tried runnig ovactiond (by modifing the lrf) as the login account, but with the same results.
I am also having problems getting both mapisend and sendmail NT exchange email commands functioning. Everything works from the command line, but nothing works from automatic actions. I tried creating a batch file in the openview\bin directory.
This user "bin", I could not find it in the user manager for the local system. Where exactly is this user?
Any other suggestions on what I may need to get this functional?
I created an NT domain account named bin, configured an exchange account named bin, created a local profile on the NNM console workstation (NT Server), assigned the domain account bin full rights to the local server, created an outlook profile named bin and then tested everything again.
I have been working on the ovactiond.lrf file. Currently, this is where my confusion is.
Since I am using a NT domain account, how would I enter the user name? Would I enter \\domain name\user name or would I use domain name\user name.
I can recreated the same MAPI logon error from the command line by using an incorrect name in the - u parameter. This leads me to believe that the ovactiond executable can not "log in" as my domain user account and is still using the "bin" account.
I think Berlene's comments may relate to the UNIX version as UNIX has a /usr/bin directory which contains a number of 'shells'.
That a side, one thing I did try was to execute the "set" command and pipe its output to a file as an automatic action. The results showed that the command was run as "default user" and not as the user was logged in. I am no exchange expert, but I wondered if there are some environment variables that are needed before running mapisend. I tried copying the environment variables that are set for my account into a batch file and then running that instead of mapisend directly, unfortunatly, did not work and I still got the error 3.
The other thing I tried was to change the owner of ovactiond to my account using the -u option in the lrf. This also did not work.
I am back in the office, Friday, and will have another look at it and I will keep you posted with updates.
I have stopped ovactiond using ovstop -v ovactiond and then restarted it directly from the command line. The command prompt did not return, so I just left it running. I checked it was running as my user using a freeware program HandleEx. The automatic action ran the mapsend command succesfully.
The only problem is I can not get ovactiond to run with my user via the lrf file, it always defaults to NT Authority:SYSTEM no matter what syntax I try.
I gave up on the mapisend and sendmail commands!!!
I moved to using the telalert software instead. The free version is working fine for what I need. I have several email groups I have emails sent to based on the type of trap. One group just sends emails while the other one also pages specific cell phones. All is working fine.
If you use telalert and need to make changes to the [destinations] section for different email addresses, make sure you recompile the script using the telalert -init option. Otherwise, telalert will not recognize the telalert.ini changes.
Now I have mapisend.exe working I have made some change on ovactiond.lrf to look like: OVs_YES_START:pmd:-u NTuser1:OVs_WELL_BEHAVED:: The real situation is: The user NTuser1 have administrator rights and HP OpenView Process Manager is running with that user account, I don't think it is required but I have done so. In the exchange server I create a mail acount called HP OpenView NNM and I gave NTuser1 permision to use the account.