ePO agent port clashes .....options?

[Superhoop]

Hi All,

Currently using ePO 4.5 Patch 4 with 50,000 nodes.

As part of a take over we have an additional 300 critical servers to migrate to ePO. The applications on these servers currently use the ports the ePo agent wants to use !!

Agent-to-server communication secure port

Agent wake-up communication port

Agent broadcast communication port

Agent-to-server communication port

I do not fancy changing these ports for all 50,000 nodes plus the application ports cannot be changed.

I also don' understand why I am getting a 'last communication' time in ePo under these machines given the ports are in use.

Apart from creating a new ePO server dedicated to these 300 servers do I have ANY other options?

Now the machines are still talking to ePO as the last communication date in ePO is up to date but what functions am I going to miss with these ports in use? Is it a show stopper ?

Thanks

Dan

Message was edited by: Superhoop on 04/05/12 04:10:13 CDT

[JoeBidgood · Accepted solution]

You should know this stuff, Dan

The agent-to-server comms ports should be fine, as the agent is not trying to listen on these ports.

The agent broadcast port (aka the Superagent wakeup port) is likewise not important unless you intend to make these machines superagents.

The only one that'll give you trouble is the agent wakeup call port, which the agent will try to listen on - depending on the order in which services start you may run into problems (for example if the agent binds the port first and prevents the other - presumably more important - app from using it.)

HTH -

Joe

[Superhoop]

Hi Joe

Of course, 9080 is the port on the ePO server that the agent is communicating to I guess. I will go and fetch my dunces hat and stand in the corner for the rest of the day.

That for the heads up on the superagents and service start up order.

So, apart from not being able to send a wake up call and see the agent log remotely  you believe we should be able to function like this ?

• I have just created an Eicar test virus on the server .... this was sent back to ePO and I received an email alert.
• The machine can update it's DATs
• The last comm date is showing within the last hour before any task
• Scheduled a 'Wake up force comms' task and this initiated OK on the client.
• Changed a policy config and , using the scheduled comms task, told the agent to pick it up. It did and successfully enforced.

I really hope so  !!

Thanks (as always)

Dan

Message was edited by: Superhoop on 04/05/12 05:44:39 CDT

[JoeBidgood]

Yep, from what you've described, the only thing that will be impacted is the ability to send wakeup calls to these machines. (Also global updating won't work.) If the other app runs as a service you could maybe do something like make the frameowrk dependent on it, so that the other app always gets first crack at reserving the port.

f it turns out to be a big problem, then the agent wakeup call port is actually one of the easiest to change: you can do it from the ePO console without having to hack anything. The client machines will all pick up the new port when they make their normal communication with the server.  The only downside of course is that you can't send wakeup calls to machines until they have done this.

HTH -

Joe

[Superhoop]

Thanks again Joe ... I hope McAfee continue their quest to clone you

Regards

Dan

[JoeBidgood]

We achieved that years ago - there's now forty-six of me, but only one of them gets paid

Joe

[jdavie3]

Similar problem as Superhoop. A company merger.

I have a number of servers that are using the McAfee Agent 4.6 wake-up communication port and cannot be changed.

If I change the port on the ePO server, there are a miriad of firewalls that will need changing.

If the Agent wake-up communication port could be disabled on these new servers, that would suffice. Unfortunately, in all the testing I have done, the Agent always opens the port, even if the policy disables Wake-up funcrionality.

Are there any new options since last May or related to McAfee Agent 4.6? Maybe a registry hack? Maybe a hacked and whitelisted SiteList that could not be changed by the agent.

NOTE - During migrations to the new ePO server, I noticed that the McAfee Agent properties can show the old port, and use it for wake-up calls, until the new ePO server policy is enforced.

[ottawa_tech_31]

We had a similar problem...and a small continuing problem..

We push to have the agent on ALL boxes...Windows, Mac, LInux, etc...

On Linux, lotsa stuff on 8081 (Tomcat, websphere, etc..)...so port 8081 became an issue..

I queried firewall logs for a month, looking for a specific port that wasn't used, and got it `reserved`` for the Mcafee agent..

We tested in the lab, changing the port, and all the agents just took it without issue (we're an all 4.6 shop, save for agent 4.0 on a few legacy Win2K boxes)

So we changed the wake-up port and the agent runs great now on all boxes, as we've got  a new port (my oldest daughters` birthday is now tattood on 10,000+ machines, HA) that doesn't conflict with anything...EXCEPT when we install it on an already running Linux server, because, on Linux, the agent has 2 annoying bugs (still in 4.6)....

1. Even if the agent is compiled on an ePO server with a modified wake-up port, the Linux Mcafee agent wil always start on 8081 until it gets a policy and then the agent restarts with new settings, which on it`s own isn`t bad, except for another issue.

2. Mcafee agent for Linux WON`T START if it can`t get òwnership`of port 8081 to listen on, so we get a chicken or egg scenario, where we can`t install the agent becuase of a port conflict when another service is present, and we can`t fix the conflict with an updated policy because the agent won`t start...

i REALLY REALLY REALLY hope this gets fixed in an upcoming release of the Mcafee agent for Linux,. ...

But yeah, changing the listener port is  very doable...all my superagent repos adjusted, and so did my sitelist too..all without issue..