Am I the only one experiencing this issue?
You need to be more explicit. Which reports do you run and what information is incomplete? Give us examples.
Especially the report for Disk Status - the result is different every day (and by different I mean for example today 60 machines encrypted, tomorrow morning 25 and same thing on the next day)..
Is it reporting the disk status only for online machines??
Which version of Endpoint are you using? I had this problem with 6.0.1 and fixed it with a Hotfix obtained through support in October of 2010. Since then McAfee has released Endpoint Encryption 6 Patch 2 (6.0.2) which also resolved the issue.
Yes, we just deployed EEPC 6.0.1....
Probably then we shall consider upgrading to patch 2
We are having similar issues, where we have built a report that will show history of individual devices, the results will say that it is encrypted, then errors will creep in and ultimately report back as unknown status.
As you have done we have reports where the number vary day-by-day.
Support thought that ePO 4.5 patch 4 would solve that issue it has not. We are running 6.0.2 and some hot fixes.\
Our experience so far, we have about 300 devices encrypted is still pretty iffy.
Development is working on solving eePC/ePO issues for about 4 months now, it is a combination of number of devices and number of user on the devices that chokes our ePO server and consumes all resources. We didnt see it during the initial phases of roll out but at some point we hit a tipping point, around 100 devices with 70 - 100 users per device that crippled epo.
We are about to ramp up our deployment of EEPC 6.0.2 to additional machines. Currently we have ~45 machines that have EEPC 6.0.2 installed and each of those has an AD group mapped to it for logins. This group has about 85 machines there are also users that are assigned individually to these machines ~5 each. I am a bit concerned when you say "Development is working on solving eePC/ePO issues for about 4 months now, it is a combination of number of devices and number of user on the devices that chokes our ePO server and consumes all resources.".
What sort of hardware are you running for a server? How many client machines do you have in ePO?
Thanks for your repsonse.
Out ePO server and Agent handlers are all Virtual machines.
The physical resources of the box is not the concern, we are not consuming all the CPU, RAM or disk space. The host machines are running on DL380 G5s with only 1 or 2 VM running, the physical hosts don’t move off 1% CPU and disk IO is minimal. Your SQL server is where the ht comes
The issue that we ran into was that each device checking in was consuming TomCat resources and either not releasing, consuming all of it, I dont really know the internal details, other than ePO would stop responding until the server was rebooted or the services restarted.
It has been attributed to the way that the client machines talk back to ePO and the SQL server.
The patch 4 to ePO and 6.0.2 is supposed to take care of many of these issues, but we are still having issues.
Some of the things that we see are: devices not reporting their status correctly (what you are seeing), ePO becoming unresponsive and hammering on SQL.
Now we may be unique, I have heard that they are having similar but different issues with other people with much larger deployments having lesser issues. We heard that Proof of Concept fixes have fixed some peoples issues.
At least at this point I wouldn’t go all out in getting your stuff encrypted if you can delay it. We all read that beta 6.1 is being tested. Hopefully they can resolve those issues with 6.1
What I really hope is that they will fix is eePC communicating through the DMZ Agent handler. It makes no sense to have people in the field that need to connect with a VPN solution to get updates and policy changes and report information to ePO. As it stands right now our users that don’t have VPN that are in the field can get DAT updates and report AV issues, but eePC – SOL.