We are expanding a network and we are now testing it in a test setup. We have changed the domain in which the epolicy orchestrator (4.6) server resides.
Since then, we have been unable to login to the console. The error given were:
- The Local Event Parser service is not running
- A database error occurred while getting license information make sure your database server is currently running
I think the problem is the login information and domain, I followed the advice in this article and had to use solution 3.
https://kc.mcafee.com/corporate/index?page=content&id=kb69850
It all seems to work, as can be seen in the enclosed screenshot, except that the Apply button stays greyed out after the connection is successfully tested.
At first I suspected Internet Explorer Enhanced Security Configuration, as it warned that it had blocked certain content, but disabling it didn't help and I re-enabled it again.
The SQL server is hosted on the same machine as epolicy orchestrator.
I'm doubtful this is the only problem, but it would be a great step forward if I could at least update the login information.
Is anyone familiar with this problem and able to help?
Message was edited by: provalki - clarified that IE IESC has been re-enabled. on 1/20/14 9:28:13 AM CSTSolved! Go to Solution.
Hi Provalki,
I suggest to change the authentication from windows to sql user as per the attached sceenshot.
Then, from the db.properties
db.user.name=eposa ( As per my attached document, username is eposa)
db.user.passwd=[my password] ( After = leave blank space in the password.
Then STOP all the EPO services ( dont click restart, stop the services) then start only application server service and then reauthenticate the eposa user and password and see the apply button will be enabled and you can apply the changes.
Note: Please recheck the port number in db.properties and sql configuration manager=Protocols for instance and TCP/IP properties check the port is same..
Before making any chnages, please backup the db.properties file as recommended.
Regards,
RGC
Message was edited by: rgc on 1/21/14 2:24:05 AM CSTI have tried to circumvent this by putting the login information in manually with a plaintext password in db.properties:
db.user.domain=[my domain]
db.user.name=[my login]
db.user.passwd=[my password]
It didn't have any effect, I still get the errors:
- The license for ePolicy Orchestrator is invalid
- The Local Event Parser service is not running. (If I start it manually windows informs me that it stopped automatically after being started)
- A database error occurred while getting license information. Make sure your database server is currently running.
The server log says:
- COM Error: 0x80004005
- File: .\ePOData_connection.cpp(322)
- Function: DAL2_CConnection::Init
- Source: Microsoft OLE DB Provider for SQL Server
- Description [DBNETLIB][ConnectionOpen (Connect()).]SQL server does not exist or access denied.
- DAL2_CConnection::Init: Error 0x80004005 returned from credentials callback. Database NOT available
I have tried many KB articles with no effect.
Right now, I'd like to find out whether the real problem is "SQL server does not exist" or "access denied".
Reverting the domain change does not stop the problem either btw.
Hi Provalki,
I suggest to change the authentication from windows to sql user as per the attached sceenshot.
Then, from the db.properties
db.user.name=eposa ( As per my attached document, username is eposa)
db.user.passwd=[my password] ( After = leave blank space in the password.
Then STOP all the EPO services ( dont click restart, stop the services) then start only application server service and then reauthenticate the eposa user and password and see the apply button will be enabled and you can apply the changes.
Note: Please recheck the port number in db.properties and sql configuration manager=Protocols for instance and TCP/IP properties check the port is same..
Before making any chnages, please backup the db.properties file as recommended.
Regards,
RGC
Message was edited by: rgc on 1/21/14 2:24:05 AM CSTIt worked, it turned out to be the port was wrong.
I have no idea how that got changed since the move but that did it.
Thanks a lot
hi,
why do you have this strange port? Or maybe your SQL-Server is using dynamic ports? I would recommend to change it to use a fixed port only.
It was set to dynamic port and it does not appear to have been deliberate.
I have set it to a fixed port. Thanks for the heads up.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA