I setup a client task to deploy an RSD sensor to each DHCP server, I then modified the RSD policy to allow for DHCP monitoring and setup a listening subnet rule to cover all my subnets. However, on the RSD screen it lists no sensors on my network, yet if I check on the DHCP servers I can see that the sensor has been deployed.
Why are they not reporting in?
First check and make sure the sensors installed correctly on the clients. The easiest method for this is to open up services and see if you have the following service present and started:
McAfee Rogue System Sensor
Assuming the sensor service is present and started the next step would be to check the RSDSensor_out.log and see what the error is communicating with the EPO server. The log should be located here (by default):
C:\Program Files\McAfee\RSD Sensor\RSDSensor_out.log
In that log you should find some sort of error as well as the IP address the sensor is trying to use to communicate with the EPO server. If the IP address is wrong you can correct this in the RSD Sensor policy on the General tab put the IP address for the EPO server in the Server name field.
I hope that helps!
I'm seeing the following:
12-29-09 04:36:40,827  WARN RSDSensor.ServerCom <> - SocketException: Failed to connect to remote host :8444
10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I've confirmed the IP in policy is correct, however am I correct in thinking that I should be seeing the host ip or name in front of the port number?
The port corresponds to the secure client - server communications port.
So this is a straight-forward failure to connect. If the IP is correct then try the following:
If the server is not listening on the correct port then we have many different possibilities I'd rather only go into if that is the problem. If the server is listening on the correct port but the telnet test is failing then something (ie a firewall) is blocking the communication. The most likely culprit would be the windows firewall on the EPO server.
I agree the IP address should be included in the log but it is not (even on working sensors).
Well then that makes sense. I'm guessing you put the correct IP address in the sensor policy the client had not enforced this policy yet.
I'm glad to hear the mystery is resolved