We're using ePO 4.0 and VSE 8.7. In trying to reinstall one of our clients that wasn't updating, we can't get the client to communicate with the ePO server. Upon investigating, the client's registry settings for the Agent are not reading the IP address information correctly. What it's doing is assigning the Agent and IP of 127.0.0.1, which is what it's supposed to use to communicate with the ePO server. The end result is that the client can't find the SiteStat.xml file.
Does anyone have any ideas on why the client isn't getting the correct IP address info?
I can't tell if you're saying in EPO the agent shows up with an IP of 127.0.0.1 or if the agent is trying to find the server at IP 127.0.0.1.
Open the agent log file and check what IP it thinks the server is at. The log can be found at C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\Db\Agent_[hostname].log.
Look for some entries like this:
2009-04-14 00:37:16 I #2088 naInet Connecting to Real Server: [server IP] on port: 8088 2009-04-14 00:37:16 I #2092 Agent Forwarding all events 2009-04-14 00:37:16 I #2088 naInet Connected to ePO Server: [server IP]
The ePO client is registering with the IP address of 127.0.0.1 instead of it's actual IP address, i.e. 192.168.0.201.
When it looks for the ePO server, it's looking for http://127.0.0.1:8088/software/sitestat.xml. So from what I can tell, the client is getting the 127.0.0.1 address AND it's trying to find the ePO server at 127.0.0.1. I think the client giving itself the localhost address is what's causing the client to not be able to find the Sitestat.xml file.
From the client I can ping the ePO server and telnet to all the appropriate ports.
When I did a re-install today, the client had the correct IP entries in the registry until I tried to do a manual update. Then it changed them back to this:
New development: We called this in to McAfee tech support yesterday and once they found out how our system was set up (ePO server in DMZ w/all clients on internal subnets communicating through firewall) they told us we were running an unsupported configuration and we were on our own. Nice.
The SiteList.xml and ServerSiteList.xml both refer to our ePO server as having an IP address of 127.0.0.1. This is the same as on our systems that work. I'm not sure how the agent is translating this, but the one thing that doesn't seem to happen during the install on the affected box is that the agent is missing a registry key of ServerName|127.0.0.1|8088 in addition to the incorrect IP info that I mentioned before.
The server did have two NICs which were registering, but I disabled the one that wasn't being used. It made sense that the Agent was trying to grab IP info from the wrong NIC, but re-installs after the disable had the same result.
Jim: No, it's just a secure environment with firewall rules to only allow communication that is absolutely necessary. There are no VPN's or VPN clients involved. We have other servers in the same subnet that are working properly with our standard installation process, which is what has us stumped.
Well I did think that if you'd been using VPNs then you'd have mentioned it before now 😉
However - I still just can't get my head around your clients actually using 127.0.0.1 - on my PC the dos command NBTSTAT -A 127.0.0.1 returns and error and the IP address reported is the "real" IP address of my PC
EDIT: - of course a subsequent NBTSTAT - A of that IP address return the correct info....
- so as I said earler 127.0.0.1 is not a "normal" IP address and is the Loopback IP for your local PC or Server so I just cannot see why this IP is being used :confused: