This content has been marked as final. Show 5 replies
when the Common Framework Svc starts up it derives its IP from an API call ( it is actually logged in the ePO Agent's Agent_computername.log if the logs go back that far)
now the most likely case for the framework starting up is the computer has been rebooted, and what i have seen happen is the Framework svc start before the TCPIP stack is ready, and the IP returned from the API call is the loopback address.
it may be worth checking the windows evt logs to see if the computers concerned all rebooted at around the same time ( patch installs, or something ) its possible it could be a property of the NICs present in these machines - are they simple NICs or are they teamed, clustered, loadbalanced or other trickery perhaps ?
i agree it would be useful to have the agent sanity check the IP address returned from the API call, because the loopback addy is never useable ( i think they have already added this functionality into the ePO Server codebase)
I started seeing this on a few agents as well. Just your basic single NIC 3com variety.
if anyone is interrested to get to the bottom of this, it might be worth seeing if you can put some chronology into the events that occur when the computer concerned boots up,
ie, the windows evt log often logs an event from the NIC when it comes on line, and the ePO agent log will log the time that the agent tried to determine the IP of the host machine,
does it do the IP address check before the NIC is initialized ?
this would help to provide steps to reproduce, and a solid case to get Mfee to make the code more robust,
oh, and an enterprise support contract helps too....
Sorry for the delay in replying. It went a little manic here for the last couple of weeks.
I have checked the event log and it seems the network card is coming on line before the framework service starts. If I uninstall the agent reboot the server and reinstall it, the first collect and send props it actually uses the correct ip address, but on other collect and send props it defaults back to the 127 address? Which really doesnt make any sense.
I am completely stumped by this and not sure of what the next step would be :-(
tjackson, have you manage to find a slution yet?
thats good that you have come up with an explanation of what happens when this condition occurs.
couple of thoughts
open a support case with McAfee and complain bitterly until it is escalated to tier 3 - you are doing a public service.
what the framework needs is a check of the IP address - IF IP = 127.0.0.1 wait 30 secs and query again
in the short term, since this is only affecting a few servers ( namely the superagents ) you could make FrameWorkService a dependency of the network card service ( if it exists as a service)
or.. set the framework svc to manual, and start it using a startup script, with a delay of, say 2 mins to allow the servers NIC to come online
hope this helps,