8 Replies Latest reply on Sep 14, 2009 4:22 AM by JoeBidgood

    Problems with EPO 4.5

      I've fairly recently setup EPO 4.5 to manage McAfee VSE in our environment.
      It's running on Windows 2003 R2 SP2, with it's own SQL 2005 Express DB.

      We have never had an EPO server before, but it's been working as expected, and I've been using it to upgrade servers from VSE 8.0 and 8.5 to 8.7, without any issues.

      I hadn't moved any servers into EPO for around 2 weeks, as I was just testing it on around 35 or so servers that I have direct control over, before expanding it to all our windows servers.

      On Monday morning, I opened the web console, intending to add some more servers in, and I noticed that the console was very slow and that the Threat Event graph on the dashboard was showing zero threats, so I added one new system, and then rebooted the EPO server.

      After it came back up I noticed that 3 or so servers were showing as "Non-Compliant" but when I clicked on the that to bring up the list, the servers have the current Engine/DAT, but the Product Version, (Agent) is blank. I've tried waking the agents and reinstalling the agents, but that doesn't seem to change. (I can also go to the client and have the agent collect and send props - seems to work, but no change). That's the first issue.

      Second issue is that my Menu\Reporting\Threat Log is blank, and up until this week it was showing dozens of events a day, (mostly on-access scans that timed out).

      The third and most annoying issue is that I've added two new systems into EPO since Monday, and both have basically failed. One is showing as "Managed" and shows it's VSE 8.7 details, (8.7 was already installed), but no agent details, and it's still taking it's updates from NAIHttp - not the EPO server. When I tell the agent to Collect and Send Props, it tells me that the EPO server is busy. The other server is showing as "Unmanaged", and shows no details. (VSE 8.0 is currently installed). and if I tell the agent to collect and send props, it says "Agent failed to collect properties".:mad:

      Also-when I first visited this forum, I saw the link to the 5400 engine, so I imported that into EPO to test that updates were still working, (clients have scheduled auto updates set), and now all the clients, except the two added since Monday, have upgraded themselves to the 5400 engine.

      Sorry that's so long - anyone have any ideas?
        • 1. Update
          Made some progress on this issue, it seems that EPO is producing hundreds of thousands of tiny files, and has either filled up the SQL 2005 Express DB, (which has a max size of 4GB), or has just died from the fact that it has 850,000 files in the C:\Program Files\McAfee\ePolicy Orchestrator\DB\events directory.

          Does anyone know why it would do that? and can I delete all the files in that directory?

          Further Update:

          The "EPO_4_Server" DB has hit it's maximum size of 4GB, but I only have 50 clients, and it's been only running for a month... how could this happen?
          And what can I do to get the DB back under control? Is there a task I should be running to purge the DB ?
          • 2. RE: Update
            Further to this - I've found the issue.

            I added a couple of Virtual Center servers to EPO 2 weeks back, and they've been reporting on every change to the VMware Workstation files, something around 1.3 million events in 2 weeks. This have caused the DB to hit it's max size and totally cripple EPO.

            Can anyone advise me on the best course of action?

            For starters - I've removed those 2 servers from EPO, and changed EPO Policy to not report on changes to VMware Workstation files.

            Can I safely clear out the EPOEvent table and the C:\Program Files\McAfee\ePolicy Orchestrator\DB\Events folder? Or will that cause other issues?

            Will EPO manage to fix itself now that it's not being flooded with events? Or do I need to take further action?
            • 3. RE: Update

              I've had the similar issue with Virtual Center server. But In my case the system drive on VC server run out of space. The folder C:\Documents and Settings\All Users\Application Data\McAfee\Common Framework\AgentEvents was filled with hundred of thousands of small xml files. I had to disable raporting of modification to the VMware Workstation files.
              So check also that folder on yours VC servers.

              ps. I have also sheduled to purge event log an my EPO server everyday to delete outdated events.

              • 4. RE: Update

                yes you can do both of these, just stop the EPO services and clear it all down, I would also purge all the logs down when you manage to get back in.
                • 5. RE: Update

                  Thanks for the tip - Checked mine but there was only around 3k .xml files in those folders, so not so bad. They must of transferred them all to the EPO server.
                  • 6. RE: Update

                    So I can clear out the EPOEvent Table in SQL, without breaking EPO / corrupting the Database?

                    Thanks for the replies -btw !
                    • 7. RE: Update
                      well if you have other reports referencing data that tries to point back to the events then you wouldnt be able to drill down to them, but if the system is broken then yes you can go in and clear the table down or at least clear off a large amount of it without it actually breaking anything ( always backup though :))

                      I've had to do this in both 3.6.1 and 4.0 and 4.5 doesnt treat the event table any differently
                      • 8. RE: Update

                        Just a small point - there's a slight difference between 3.6.1 and 4.0 / 4.5. In 3.6.1 there were a number of related tables, so you had to be slightly careful what you were doing or you could get the situation you mention (where the summary page of the report looked OK but there was nothing to drill into.)
                        In 4.0 / 4.5 it's simplified in that there is only one table to worry about.