Yes, something wrote to the EEPC MBR replacing it with a Windows one - perhaps your customer tried to remove EEPC using a system restore, or did a fixBoot?
Regardless, something replaced the EEPC MBR with a Windows one - that's the only explanation. To resolve it, use SafeTech and do an emergency boot. That will fix the MBR problem, no need to decrypt.
I was going to post a question about the lack of the "Restore EEPC MBR" functionality in EETech 7.0 [even though the EEPC MBR, called EpeMbr in the XML file, IS now exported from ePO in EEPC 7.0, unlike 6.x], when I came across this thread.
I believe that the Restore EEPC MBR functionality is still required in EETech because an Emergency Boot will only work if Windows is not damaged, since if Windows won't start, the EEPC client cannot repair itself. I have run into several situations with EEPC 5.x where a rootkit has damaged the system and a Restore EEPC MBR was necessary before WinTech could access the file system. I understand that a Force Crypt followed by a Restore MBR will work, but, at least in 5.x, the Force Crypt performance was so terrible, ~10 times as slow as the normal decryption, that I only used it as a last resort.
Not sure I understand
in 5.x, the Force Crypt performance was so terrible, ~10 times as slow as the normal decryption
Force crypt, and normal crypt run at exactly the same speed - it's WinTech which is 10x faster than SafeTech - but both crypt methods are available in both tools?
I agree that the standalone performance is terrible. In fact, the internal documentation I've distributed says explicitly that standalone is ONLY to be used for Emergency Boot. My experience with WinTech (still using 5.2.5 version, even though our server is 5.2.10) is that Force Crypt and normal Crypt (i.e. Remove EEPC) do NOT perform the same. Perhaps this problem was corrected in a later version of WinTech and I wasn't aware of it. Note that I have not included SATA drivers in BartPE, so WinTech is always run with SATA=Compatibility set in the BIOS -- during normal Windows operation, changing the SATA setting in the BIOS does not cause any apparent performance impact, but perhaps BartPE is different.
in any case, I plan to test the BartPE based EETech 7.0 to compare normal vs forced decryption speed and will post my findings here.
Have just finished a test of Force Decrypt and, at least on EETech 7.0 based on BartPE, SafeBoot's statement above is correct -- Force Decrypt is no longer any slower than normal decrypt; aka Remove EE