May I know the error message do you get while checking the pacakge?
Hem, not sure which package you're referring to?
We aren't trying to install a package; the issue is that clients that can no longer check into the ePO server for any updates, policy changes, DAT files, etc.
One thing, not sure if it's related or not, but maybe significant.
The apache log file directory filled up all available drive space, and the apache service crashed. We deleted a bunch of files out of \program files\mcafee\epolicy orchestrator\apache2\log; all files 12/31/2011 and earlier. Is it possible there was some critical files in that folder that might have broken something?
No there's no config files or anything critical in the log folder. Have you restarted the server since deleting the files?
The only things preventing a client reporting to the server is if the ports are blocked by a firewall or if the services aren't listening on the ports.
Basically are the services that Ulyses31 mentions running.
Yes, restarted the server since then, several times actually. All services appear to be running fine. Running queries on event logs or audit logs all work fine. We're able to edit HIPS exception policies and save them just fine. Only the system checking in to the ePO server "last communication time" doesn't work
I don't see how there could be any kind of network issue. Even the McAfee Agent on the ePO server itself isn't checking in. I removed the HIPS agent itself and rebooted, just in case HIPS was blocking something from working. The SQL backend, and all the agent handlers, are on the same switch; there is no firewall in between any of them.
Are you using SQL Express os SQL Server? Which is its size now?
1. test to see if the ports are open on the server
- On any client try and telnet to the 'Agent-to-server communication port'. I think the default it port 80. eg from the command prompt "telnet yourEpoIP 80" if the connection times out then it is a port/network issue. If the screen goes blank try typing "GET" and return, if you get html displayed then you know the server is running and accepting communication.
2. Check the agent logs of each of the machines. Hopefully they will contain some diagnostic info to be able to investigate further.
Here's another thing.
In the Windows event logs, the Apache service is generating application errors about every 30 seconds and referencing the "kernelbase.dll" file in each event log as the "faulting module path"
kernelbase.dll is in the folder c: \windows\syswow64
telnet clients aren't installed on these machines but netstat shows the ports listening, and there are established connections on both 80 and 443, so it's not a question of the ports not listening.