Another Agent unable to connect to EPO

[tauhs]

Agreed, simpler solution.....other way works but if your unfamiliar with using McAfee in Command Line...may not be the way to go for you.

[scottgilliland2]

Thanks ansarias

I used the command to forcereinstall the agent and it seems to have worked on the 3 machines I tested it on, problem is there is about 200 machines on our domain an only 90ish are actually managed.  Going to be a long road to find them all and connect.

I tried solution 1 but the problem is I cannot find:

• C:/Documents and Settings/All Users/Application Data/Network Associates/Common Framework
• C:/Program Files/Network Associates/Common Framework/Data

On any of the affected machines!

Do you guys think seeing as this server is using 11.5Gb of RAM should I maybe move the epo to our domain controller?  Or is that not advised?

[chrisakinika]

If the folders are not there, I'd suggest that either the agent is not there or not installed properly. Are the affected syetems showing up in the system tree as unmanaged? 

If so, maybe try an agent deployment from ePO and force it to install over any existing installations?

Select a few systems from the system tree, then click on Actions->Agent->Deploy agent.  Ensure that the agent version you select is correct (I'm using 4.8 because of the agent-server comms issues with agent 5.0), and tick the checkbox for "Force installation over existing version". 

Regards the RAM issue, is there anything else running on your ePO server?  Ours is managing approx the same number of endpoints with 8GB and very rarely goes over 4GB used.

I'd certainly advise against moving ePO functions to the DC!

[scottgilliland2]

Yes they are showing as unmanaged systems, however I am unable to ping them within ePO and have tried numerous times to deploy agents to them.

Yes the ePO also is running a system managing the functions on production floor as well as the printer server functions, its an access card print server as well so it would most likely take a lot of physical RAM to process.

Is it better running on a server of its own then?  I have a number of options to go down if I migrate it but also can afford another server in the budget if need be to be a standalone ePO server.

[chrisakinika]

In that case I'd definitely recommend migrating to a separate server.  ePO is recommended to be running on a server with at least 8GB of it's own, so with the server also performing all those other functions it's going to encounter performance issues straight away. 

With all those other processes running on the server, we could pull at threads all day trying to get the bottom of whats causing the issues (which while would be an interesting exercise in itself, would also be time consuming!)

If I were you, I'd just cut the knot and take the clean-slate approach.  New server build, clean install of ePO and then have nothing else running on the box. Check the other endpoints to see if there is an agent installed anywhere (even as basic as just checking for the folders on HDD or a listing in Progs & Features) and if so perform uninstall in your manner of choice.

But you never know - with a clean install and no other functions that may be interfering with ePO, agent installation pushes may then start working correctly. 

[scottgilliland2]

I have just had a look at that server again, and after a reboot from last night after some patching it is only using 5/12Gb of RAM

So it could be left on there now then an eye kept on the RAM usage (some major patches missing hence reboot needed) OR I could take a clean sheet with it as it would be better for my own experience in using ePO.

On another note, are there any issues with have the ePO on Hp Thin Clients?  I have got 2/11 managed since I tried deploying in last hour.  Not a major issue if they aren't managed as they only use one piece of software but better safe than sorry.

[chrisakinika]

scottgilliland2003 wrote:
OR I could take a clean sheet with it as it would be better for my own experience in using ePO.

Exactly how I got started with ePO!  We had a clunky 5.0 server that wasn't managing to do anything properly, the boss gave me a new(ha!) Win2008 server, bought an ePO license and told me to get on with it.  Certainly an experience I'd recommend, as it really lets you get to grips with managing your ePO system from day1 one and know it inside out (and props to McAfee for the good Install and On-Premesis guides!)  

Not sure on the thin Client side of things; we have them too but they remain unmanaged for exactly the same reason (and are underpowered, so having any agent on there would deplete what little spare resources they have anyway)

[ansarias]

You can deploy Agent package from ePO console and it will require domain ID and password. Make sure you use only Administrator ID and password. If you use ePO login credentials than it will not work.

[tauhs]

Another approach if its available, if your company uses SCCM you can create a FramePkg.exe from within ePO and have SCCM disseminate. SCCM can set up an update package to push to all endpoints when they connect to the network guaranteeing an agent install. Once the agent is installed, ePO can manage it from there.

[tauhs]

Its not under program files or program files (x86) look for the Common Framework file located at (you will need to turn on you see hidden folders)

?:\ProgramData\McAfee\Common Framework  (the ? is for whatever drive you use)

Within there you can access the DB folder mentioned above.