View Full Version : Unable to connect to localhost on 2223, and moar issues
March 4th, 2009, 08:08 AM
I am an avid Eset fan and are reorganizing my home/business network.
Since I also need to learn more about different aspects of remote administration I purchased a Business license of Eset Smart Security, and also installed Server and Console on my WHS Server.
Downloaded and printed the manual and started fiddling around with this.
1. Why doesn't the Services start but only gives me a message about "some services start and stop if they have no work to do"
2. I have NOT set any password, yet I am unable to connect to the server, maybe because it is not running? (Port should be open, proper rule in application and Windows Firewall has been disabled. I can Pink localhost, but not localhost:2223)
3. How do I verify that the clients are successfully talking to the server?
A big issue for me setting up this network is that I am configuring it as a file/backup/software/storage-server with everything except for normal Internet and e-mail, channeled through it, or to it. An example of this is the Eset AV Updates whose function will be pointing to this server, instead of local clients using B/W getting updates from Internet.
The more I read the documentation, the more I lack a simple 1-2-3-4-... manual (do this, then this and then this and also that and that and done)
An example, where is the DB stored? First pages of Manual talks about an ODBC connector. Are you seriously expecting me to set that one up manually? I know how, but I also know it just a dialogue of 4-5 lines in the MSI setup script. Cant find and ODBC configuration in Windows made by Eset as of yet.
"plis help me!"...:wacko:
March 4th, 2009, 09:13 AM
I'm having a somewhat difficult time understanding exactly what your issues are, so forgive me if I read some of this wrong.
1) RA has two associated services that are installed: ESET Remote Administrator Server and ESET RA HTTP Server. The first should be set to startup as automatic and be running at all times. The HTTP service is started by the other service when it downloaded updated definitions from Eset and should be set to manual.
2) You cannot "ping" specific ports, echo requests only function over TCP 7. If you want a tool to verify if a port is open, you need to use something like nmap. I have never personally tried to run a RAS without a password and I really recommend that you set one when you run the installer. Setting a password for the clients to connect to the RAS is at your discretion, but be aware that for it to function properly you need to check the box "Enable unauthenticated access for Clients" on your RAS once you have figured out how to connect to it through the remote administrator console (RAC).
3) Clients will be automatically added to the RAS database as the connect, and there is a column called "Last Connected" which you can use to keep track of which machines are still communicating with your RAS.
DB files are stored in %allusersprofile%\Application Data\ESET\ESET Remote Administrator\Server\database\ if you use the default internal database. Everything is set up automatically so long as you don't try to point to to a Oracle or MSSQL database.
March 4th, 2009, 09:37 AM
I forgive you :)
Okay, then something is wrong in the services. Both are set to manual, I tried setting them to Auto an reboot, but nothing.
Password will be implemented but since it is a new rig and stuff and i have a strong pwd for the whs, I have postponed that bit a little, need to verify that everything works first.
So DB are in fact setup by installation? Great. I assume it is independent of ODBC then.
Eset HTTP Server = Auto = Does not start
Eset RA HTTP Server = Auto = Does not start
Eset Remote Administrator Server = Auto = Does not start
None of them starts when I start the Console. And I can not login.
I guess a new installation of the lot is in order. :blink:
March 4th, 2009, 10:15 AM
Eset HTTP Server is the updater for the Nod32 kernel that is running on this server and is independent of the RAS. Both HTTP services should be set to manual and can only be started if the associated Eset Service or Eset Remote Administrator Server service invokes them for an update. They will fail if try to start them through services.msc, but that does not indicate a problem.
Since the RAS service is not starting automatically, check out the system and application event logs to see what is going on. There should be errors logged there that can give a better idea of what is going on.
March 4th, 2009, 10:20 AM
Sorry for doubleposting, but I am getting pissed.
As much as I know and realize that the Console should hardly be able to run with no Server installed, I did a little test, installing the Console first, which still claims it can not login. OF COURSE YOU SILLY TWIT, THE SERVER IS NOT INSTALLED! ffs...
Checking up on that as well, Smacky
March 4th, 2009, 10:28 AM
So after an uninstall and an installation I finally connect.
Now I have to figure out how to verify that my client (being the workstation from which I manage the WHS via RDC) can talk with it.
March 4th, 2009, 01:54 PM
Got it. Since this is a new farm for me I have not yet decided on the layout or naming. Turns out the Eset server hooked to the comp name. That can be ignored via a setting in advanced, but I failed to make it work. It was even explicitly commented in a log file.
However, reading up more thoroughly in the manual I see the recommended setup is ERAS on a Network Server and/or Domain Controller and ERAC on an Administration Workstation. Is that important? I have both installed on the same machine/server.
March 4th, 2009, 05:13 PM
It is a good idea to have both the RAS and RAC installed on the server, just in case you need it in a situation where you only have console access. You should be primarily managing things from your workstation through the RAC. I believe their warning is more about not running the RAS software on a desktop system, which would be a terrible idea.
March 5th, 2009, 02:08 AM
Having both on server, yes, but its that config that does not seem to play along.
I do not understand why, something in the internal communication perhaps...
vBulletin? Copyright ©2000-2014, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2014, Wilders Security Forums