Just got DETech 7.1 WinPE V4 64 bit created and did an initial test on a legacy BIOS machine encrypted with EEPC 7.0. Although we are not yet ready to deploy 7.1, I built DETech 7.1 because it (finally) has reinstated the Restore EEPC MBR functionality, present in WinTech 5.x for years but missing in EETech until 7.1. (For those not familiar with Restore EEPC MBR, it makes recovering from a situation where malware has modified the MBR on an encrypted machine much simpler and faster. The xml file has had both the original and encrypted MBR in it since 7.0, but EETech only supported the original MBR restoration.)
I was surprised and disappointed to get the following message when I started EETech.
DETech 7.1 seemed to work; that is, I could authorize and authenticate and then view the disk contents, but I didn't attempt to perform a Remove operation, so I don't know if it would work or not.
The DETech 7.1 User Guide mentions nothing about this version ONLY supporting 7.1. Is there a technical reason for this message; that is, is the on-disk structure of 7.1 different from 7.0, or is this just a "we didn't bother testing it, so we'll just say it's unsupported" message.
We really need some information from McAfee here. I plan on raising an SR and will update this post when I get a response.
Just got the response from McAfee to my SR questioning this. The response is "DETech 7.1 is not backward compatible at all wtih any of the EEPC 7.0.x version and should not be used with any other versions other than its own. Therefore, we suggest you create a new DETech 7.1 tool for MDE 7.1 machines and/or another one for the EEPC 7.0.x machines".
I'm very unhappy about this. As far as I can see, once we deploy 7.1 and start supporting Opal drives, we will need the following eight different versions of EETech:
At least the WinPE-based EETech for 7.x works on both BIOS and UEFI (a small mercy) or it would be sixteen different versions!
In my opinion, this looks very much like product people who think only about themselves and their development effort and not about their customers. I'm almost tempted to respond to this SR response with "you should really look into this advanced concept called a subroutine, an amazing technique which allows different code to be invoked in different situations". Since EETech does not have to fit on a floppy disk, it should be possible to reduce the above 8 versions to just 2 -- one 32 bit that supports both 7.0 & 7.1 with or without Opal, and one 64 bit that does the same.Message was edited by: SeanKeeley on 2/5/14 2:14:18 PM GMT-05:00
I can half the number of versions straight away - you can use either the 32bit, or the 64bit - you don't need both, and you don't need to match the address width of the host OS unless you especially want to run a driver stored on it (which is extremely unlikely).
Your statement is correct for BIOS boot, but for UEFI boot it is not, according to KB77165 - "An x64-based UEFI computer can boot only by using Windows PE x64-based boot files. An x86-based computer can boot only by using Windows PE x86-based boot files. This differs from BIOS. In BIOS, an x64-based computer can boot by using x86-based boot files."
I have built the WinPE 4 64 bit EETech specifically to support an encrypted Windows 8 machine with Secure Boot enabled, and it works -- you can boot the WinPE 4 64 EETech CD using Secure Boot and perform file copies, decryption, etc., the same as with a BIOS boot machine.
While it might be possible to boot a 32 bit version of WinPE by disabling Secure Boot and switching to Legacy (BIOS) boot on a machine with 64 bit UEFI, this is something I'd rather not ask our support techs to do, since based on my reading about UEFI boot, the success of such an alternate boot is hardware dependent. I have to support many different machine types on a global basis, so I need a recovery tool that can be booted in exactly the same hardware setup as the OS.
While I can accept a separate recovery tool for EEPC 5.x, having separate versions for 7.0 and 7.1, with and without Opal is, as I've said, putting ease of development for McAfee over ease of use by customers. Asking support techs to maintain a box ful of CDs or USB drives in order to support a single product is not acceptable.
You are right - I forgot about that. UEFI is particular. I guess I've never used an x86 UEFI computer though - everything seems to be 64bit now.
Im Jose, from Peru. I cant make the EETech for DE 7.1. I´ve several problems during the WinPE process. Please...¿Do you can give me the .ISO file?
Please...can be rapidshare or mega.co.nz. I appreciate your help.
Unfortunately, because DETech includes the Microsoft WinPE components, it cannot be distributed due to licensing limitations -- that is why McAfee does not provide it pre-built. Blame Microsoft, not McAfee.
Please can you provide me Microsoft state on this, cause I cannot find one. I know that McAfee is saying that it is prohibited by Microsoft, when Microsoft really does not. And "Others" are publicity distributing WinPE ISOs with their recovery tools.
Where is the truth?
More info and voting here:
I would like to see some progress made by McAfee on the consolidation of the tools required to support MDE7.1.1.
I manage over 50K encrypted endpoints with 120 techs in the filed who in turn provide remote support to the end users. When we were on ver 5.x I was able to provide EETECH on a CD.
This helped our road warriors and kept everyone happy. I'm in the early stages of MDE7.1.1 deployment and have completed 10K upgrades so far. I am simultaneously building documentation and support process flows and I just realized the mess the support tools is going to cause me, my support folks, and the end users. Now we'll have to determine OPAL, UEFI, BIOS, etc before we send a CD, DVD, USB to our road warriors....SMH!
McAfee Please help us out here, this is just BAD as Sean says above. I plan to submit a PER now and escalate...