We're in the middle of an EEPC rollout and have hit a snag on one system. After installing the software and having the encryption process start, the end user took the laptop out to the field and worked on it normally all morning. This afternoon, while trying to log on, the system freezes at the EEPC screen immediately after clicking Next after entering the password. The screen still displays the default McAfee Endpoint Encryption picture, and the mouse cursor is frozen in place. This happens regardless of which user is attempting to log into the system. I also attempted a Machine Recovery but that didn't help (although, I didn't really think it would anyway).
Any thoughts? I'm hoping the drive hasn't failed since the end user's entire morning worth of work is on there still.
Is this particular system different from any of the others, in any way? (in terms of hardware) It sounds like a hardware incompatibility. If it's the same as other systems that do work, then maybe check the BIOS version?
There is nothing different about this hardware than all the others we've done so far. (It is a Panasonic CF-T8 Toughbook.)
I left it overnight on the "frozen" screen. When I came in this morning, I found there has been a development. The screen is black with the following information in white in the top left corner:
McAfee Endpoint Encryption
Fatal Error: [0xEE020001]
I haven't had time yet this morning to investigate that code.
And, I've just received another call that a second end user reports something similar. Her system is freezing up after entering her user name and not displaying the screen to enter her password. I have a sick feeling in my gut telling me that the 30+ systems we've encrypted over the past 3 weeks may all be heading for crashes!
Since I am pretty new to EEPC, could you tell me if there is a best practice on running a health check on these encrypted drives?
There may be hope yet... a second system reporting similar behaviour might be a good sign that it's not a faulty disk, but you might be unlucky!
Other things to check besides the disk might be the settings in the BIOS, particularly for AHCI vs Legacy IDE (note that it will likely be a case of trial and error with any setting combinations).
As for checking the health of the hard drive, I guess the goal would be to access the SMART data from the drive (I'm assuming it supports SMART). I personally use a live Linux distro and the smartctl command to query the drive.
Hope this helps,
Upon further review...
It appears the 2nd machine is a different problem; the issue the end user reported cannot be replicated, so it looks like that may have been a power or end-user issue. As of this time, we have had no further incidents of systems freezing during the pre-boot authentication stage. The diagnostics that have been run on the original problem machine do indicate a failed hard drive. So, hopefully this was nothing more than a coincidence of a hard drive failing immediately after getting encrypted. (Of course, if the drive was on its last legs anyway, I suppose the encryption process itself may have pushed it over the edge.)
If we experience any similar issues, I'll update this thread.
We've determined that the "2nd" problem - the one where they enter their user name and never get prompted for a password - is user error. The system is going to the screen saver and then is asking for a password when it is next accessed. The end user, not reading the screen, is putting in their user name instead of password and, of course, not getting a password screen.
We've had no further incidents of failed drives, so hopefully it was simply a coincidence.