Hello, I've got EEPC 6.1.1 installed on a handful of laptops whilst testing and gauging the improvements over 5.2.5 which we've got installed on the rest of the business.
I've done the following as part of the uninstall process:
1) Broken Policy inheritance on the target laptop.
2) Applied a 'Decrypt' policy to the target laptop (This has got disk encryption set to 'none' and autoboot enabled).
3) Updated and Enforced policies on the client PC and allowed the laptop overnight to decrypt. Client Agent now states that all disks are decrypted.
4) Tagged target with 'Remove EEPC'
5) Tag configured as follows:
Target Platforms: Windows
Products and Components:
EE for PC Action = Remove
EE Agent for Windows Action = Remove
6) Updated and Enforced policies on the client PC, and received errors in the log as follows:
Error occured while uninstalling EEPC
Error occured while uninstalling EEADMIN_1000
I've referred back to my training notes and documentation, and I don't believe that I've missed a step - and I've also had this working fine in our virtual test environment, so that's leading me to believe there could be an issue specific to the hardware or install on this particular client PC - so any further logging or information would be appreciated.
Another additional question regarding autoboot. Presumably with autoboot enabled, this pretty much renders the Encryption product useless - as all of the ciphering process is done at preboot authentication correct?
We've got a history of SSO issues and password mismatches when changing AD credentials, and things have escalated which have threatened to remove MEE from our builds completely, and I'm wondering if MEE with encrypted disks but NO preboot authentication would offer ANY protection over just simply being unencrypted, as a sort of consolation alternative!
with the pre-boot disabled, the key is stored on the drive, it's really only for patch cycles etc. It's better than nothing, but not enough to meet most regulatory compliance rules in my opinion. You need to make up your own mind though.
Why not run with two different credentials? Lots of companies do that.
I guess your users are changing their passwords on non-EEPC machines, so the change is getting missed? Or perhaps you have something like Novell, or another third party credential provider involved?
Hi Safeboot, thanks for the response.
Our initial implementation of 5.2.5 contained seperate credentials, and our userbase cried out for SSO. We implemented SSO with 5.2.5 and had the odd issue with MEE password getting caught out of sync with AD password, usually if the Support Desk had to reset a password for somebody directly in AD users and computers - confusion ensued and before we knew it we had a support call because we needed to run the user recovery procedure over the phone with an offsite user.
I installed 6.1.1 within ePO a few months ago so we could use ePO to manage the system, and I'm very happy with it so far from an administration point of view - but business complaints regarding MEE and SSO have continued to rise (never complaints towards me which would allow me to either educate users or modify policy to correct faults) but the powers that be have decided that being compliant in this area is secondary to the impact on users (read into that what you will) and it looks like encryption could be removed as an IT requirement very quickly.
I ask about having pre-boot disabled as it may offer a 'better than nothing' alternative for IT management, but I appreciate the core functionality of MEE is blown out of the window when we progress down this route.
Still, as it stands I'm unable to uninstall MEE anyway due to the errors I'm gettings - so it looks like we're stuck with it !