Forcing Agents to update host names

[MNE_DUDE]

Dear experts,

In my ePO system tree I have systems with the same IP addresses. I know that it is acceptable due the DHCP, DNS...

I am wondering is there any way to force agents to update the systems in the system tree with the actual IP addresses?

Tnx!

[Pravas]

Hi @MNE_DUDE ,

We've moved your post to the relevant forum. Hope you get your query answered.

Link - https://community.mcafee.com/t5/ePolicy-Orchestrator-ePO/Re-Forcing-Agents-to-update-host-names/m-p/...

Thanks

[cdinet]

If the agents are communicating properly, they should be updating that info automatically.  If you send the client a wakeup, or run collect and send props manually from one of the clients, does it get updated or does communication fail?  I would first suspect that one of the systems is not communicating to epo.

[MNE_DUDE]

Hi @cdinet,

I think that I find a problem. Most probably source of all problem is dirty DNS...

Anyhow, ePO is trying to contact the station by IP address, which is not so good approach in my opinion.If you change the order and set NETBIOS on the first place, ePO will again hit station by IP in case name resolving fail...

So I run into the following case:

I sent ping and wake-up call to the station "A" with an IP "1.1.1.1". Ping is coming back, wake up passes successfully.

Then, I remote directly to this station "A" by IP, open Agent Status Monitor and send one more wake up. Everything works fine and very fast! After that I realized that host name doesn't correspond with host name (A) from the ePO. It is, let say station with name "B" and of course IP "1.1.1.1", but communication is working fine. 😃

I am not sure what stand behind this logic of ePO but in my opinion it can't be a good approach of a work station identifying by McAfee ePO. Also, this is good way to make some bigger mistake by granting of access to the wrong work station...

I really curious to hear your valuable opinion about this case...

v/r,

[cdinet]

If you connect directly to a system by IP, then I don't think it would need to resolve anything via dns because it already has the IP.  Since the IP belongs to some other system now, it will go to that new system.  

If you set the agent contact method to netbios, then fqdn, then IP and it still tries the IP, then dns isn't resolving the netbios or fqdn properly.  That is a problem then with dns, not epo.  Epo can only work with what dns tells it as the resolution.  If it can't resolve, then it would fall back to last known IP, which no longer applies.  

Are any of the affected systems in a sub domain?  If so, do you have the dns server registered in the dns nic settings and append dns suffix so epo can resolve better?

[MNE_DUDE]

Hi @cdinet ,

I fully agree with you about DNS. It is huge network and majority of DNS problems comes from lack of decommissioning procedures (for physical and AD objects)...

Aside of this problem, I am wondering is there a way to force agent to authenticate to the ePO by host name value. It is really weird that ePO-Agent communication is being kept for a long time even if there is no match in host name value on both side... I believe this is not a bug and that there is some reasonable explanation...

v/r,

[cdinet]

I do not believe the problem is in how agents connect to epo, as the server's IP is static, or at least it should be.  Agents will connect via IP, netbios and fqdn.  

The problem with wakeups or deploy agents, etc, is where the dns issues come in.  In server settings, agent contact method, you can control what the epo server uses as first method of contact - that is only the order of things, as it will still try all 3 methods, you are just defining what epo uses first.

Lets say you choose fqdn as first method.  DNS then comes into play to resolve the IP, whether you use fqdn or netbios first.  If dns resolves to the old IP, that is where it will go.  This is simple networking and nothing epo can do to get around that.

[cdinet]

Maybe they can increase the lease time for the IP address in dns so it doesn't change too frequently.

[MNE_DUDE]

Hi @cdinet,

What will happen in following case:

- ePO is contacting some station via FQDN, NETBIOS and IP at the end.

- Work station is turned off for long time and there is no DNS entry anymore for that host,

- but ePO still keeps assigned old IP address which is currently assigned to completely different host...

- FQDN and NETBIOS fails but IP contacting pass successfully!

- ePO keeps communication with wrong host name via "right" IP.

So, what could be the solution for this case? Let assume that DNS is cleaned and up to date, AD is synchronized with ePO...

[cdinet]

I would need to test that scenario, but if dns is working properly, I would think that it should fail with can't resolve address.  It must be resolving it from somewhere.  Do you have a wins server also?  I have seen that cause problems with cached entries.  

In that scenario, if you do an nslookup for that system, what does it return?