Just completing a rollout of EEPC 6.2.1 to c.300 endpoints.
Used EEGO to pre-scan which highlighted a handful of machines with PGP, Truecrypt etc. Very useful tool so we could handle the potential problems before they occured.
We use almost exclusively Dell Latitudes, like many other shops i imagine.
Final 40 computers (>10%) would not activate. Started troubleshooting, mfeepe.log shows the following:
ERROR EpoPlugin userHandler: failed to process batched user data response: [0xEE010003] INCOMPATIBLE PRODUCT(S) DETECTED! The following incompatible product(s) were found: Wave Trusted Drive Manager
Turns out to be some Dell Data Protection software that is bundled with the Latitudes. It highlights an internal process issue where builds are not completed properly and some of the bundled 'crapware' is left on. We can sort that no problem.
My issue is - why did EEGO not highlight this for us? Clearly EEPC can detect it - why can't EEGO? If it had, i could have dealt with this before rollout and saved some internal aggro and face.
Can we add our own detection parameters to EEGO?
For such a widely used platform as Dell Latitude i am very surprised this detection is not available in EEGO?
I have read that in EEPC 7.x EEGO is built in. Please can I request that this detection is provided with EEGO in 7.x? Perhaps it would be useful to enable us to add custom detections should this situation arise in future? I see no update on serviceportal for EEGO since Q4 2011 - surely more incompatible products have been produced and\or detected since then? (and don't call me shirley....)
Can EEGO have definition updates, and be built into Software Manager in epo?
Otherwise (believe it or not!) very pleased with EEPC and success rate.
EEGO can't be modified Shirley, but EEPC itself has modifiable product detection capiabilities built in for some time now - EEGO's more useful for detecting agent handler and data channel problems.
Personally I was never a fan of having to run some software to tell you if you could run some software, so I've been campaigning to have it all built in (as we have with EEPC7). This meant that the stand-alone EEGO took a back seat for some time, and the two got out of step.
Sorry about that, but going forward EEPC7 is all self contained.
Thanks for the link. Interesting. RTFM at it's best.
We have situation where Truecrypt is installed for a specific purpose (decrypting USB sticks sent for a specific case\job). Not using truecrypt FDE\partitioning etc. Same goes for PGP - they use it purely for sending the odd encrypted email via Outlook, not for encrypting drives\partitions. EEPC\GO will show that as a conflict, as the regkey it looks for exists. But the use case probably won't conflict (subject to us testing) - so i guess this could help us activate installations on devices that have this software installed, but we know in our particular environment should not in theory conflict with a FDE product like EEPC. Would that be fair to say? In an "I won't hold you to it" sort of way?
I will look forward to EEPC 7 when my cahunas grow large enough to migrate. Had my fingers burnt hard on EEPC 6.0.0 (POC major fail) a couple of years back, so will probably avoid the "point zero" release and wait for 7.0.1 or higher.
Thanks for replying.
I hear you re EEPC6.0...
I would though reccomend you at least take a look at EEPC7 - The standard MBR/PC side is only a small step away from the 6.2 version - the real "new version" features are on the uEFI side for Win8 - an entirely new product so to speak. We didnt want people to have to consider three different versions though (EEPC, EEMAC, EEUEFI), so we put them all together and called it EEPC7.
Personally the AMT integration, I find really exciting - the ability to run EETech remotely without having to have someone in front of the machine, or to be able to reset a password the same way even with the machine stuck at the pre-boot is very interesting from a support perspective.
Just to add, all latitudes here as well. when we first started rolling out 6.1/2 it didnt detect this wave secure software, it only started with the latest bunch that this started to pop up and cause us issues as well! I'm guessing dell changed something with their bloatware to start triggering the rule. I did look into changing the detection rules of EEPC but it was unsupported so i decided against it (same boat as well with truecrypt/pgp for emails/some external encrypted drives).
Let me know when you start rolling out EEPC7.0, I have been waiting for the standard 2-3 weeks to see if there are any issues reported to the forums (so far it seems very quiet) before I start to look into this, be interested to hear from someone with a similar setup and what things you run into.
I like the look of AMT integration as well but dont I need to start paying for deep control first?
We have upgraded from EEPC 6.2.1 to 7.0 in our Pilot group and I am starting to deploy EE GO 7.0 to all Windows laptops to determine EEPC compatibility. Despite SafeBoot's comment that EEPC 7 is all self-contained is inaccurate. The EE GO utility is still separate, although I can't speak to whether or not it is in-line with EEPC 7.0 with respect to maintaining the same incompatible product list.