Knowledge Center

FAQs for Drive Encryption 7.x
Technical Articles ID:   KB79784
Last Modified:  3/11/2019


McAfee Drive Encryption (DE) 7.2.x, 7.1.x

For details of DE supported environments, see KB79422.


Recent updates to this article:
Date Update
March 11, 2019 Updated FAQ "What is a Windows Tablet?" to be generic to all Windows operating systems, and not just Windows 8.
February 6, 2019 Updated the "Additional Windows 10 general facts" content in the Compatibility section:
  • Windows 10 LTSB/LTSC is supported with DE 7.2.2 and later.
  • References to Long-Term Servicing Branch (LTSB) to include the new Microsoft name Long Term Servicing Channel (LTSC). Name change occurred with Microsoft Windows 10 version 1809.
October 4, 2018 Updated TPM FAQ.
Added new FAQ to cover support for Windows 10 UEFI conversion tool (MBR2GPT.EXE), to the Compatibility section.
Changed all "patch" references to "update."
NOTE: McAfee updates were previously referred to as patches.
June 29, 2018 Added a link to KB79422 in the Windows 10 section in Compatibility.
May 17, 2018 Minor formatting changes. No content updates.

To receive email notification when this article is updated, click Subscribe on the right side of the page. You must be logged on to subscribe.

This list presents common questions and answers and is intended for users who are new to the product, but can be useful to all users.

  • DE was previously known as Endpoint Encryption for PC (EEPC) and Endpoint Encryption for Mac (EEMac).
  • To review the FAQs for Endpoint Assistant (EA), see KB80070. EA is a companion application for iOS and Android that was developed to work with DE. Help Desk costs for DE are typically related to user password reset management. EA can completely offload the preboot password reset related Help Desk costs to users. You can enable users to securely reset preboot passwords even if they have no access to a telephone to call the Help Desk.
  • FAQs for Opal Drives have been split into a separate article. For details, see KB89333.

Click to expand the section you want to view:

What is an OptIn and OptOut user?
You might see references to OptIn and OptOut users in the logs. For example, failing policy enforcement: assigned OptIn user.
  • OptIn users have their User-Based Policy (UBP) Enforcement set to True in ePO, which means that a specific UBP applies.
  • OptOut users have their UBP Enforcement set to False, which means that the UBP assigned to the computer applies.

Why do I need DE?
The key purpose of DE is to only protect sensitive data on the disk when at rest. This type of protection might also be required to be covered by identity protection laws.

What protection do I have when preboot authentication is disabled when enabling the temporary Autoboot feature?
Although the key purpose of DE is to protect the disk at rest, when the disk is unlocked, DE provides no data access protection. So, if you want a secure system, do not use the Autoboot feature because the autoboot feature effectively removes the preboot authentication, which completely removes the security of the product. The AutoBoot feature is provided only as a temporary means. For more details about AutoBoot, see Autoboot. For details about the more secure Trusted Platform Module (TPM) autoboot.

Compatibility DE 7.2.0 and later:

Do you support the Windows 10 Anniversary Update new command-line parameter /ReflectDrivers for in-place upgrade?
Yes. Microsoft has included a new feature in Windows 10 Anniversary Update that allows for OS in-place upgrade through ISO and SCCM using a /Reflectdrivers option.
This command switch specifies the path to a folder that contains encryption drivers for a computer that has third-party encryption enabled. PnP drivers are installed and the upgrade can continue.

NOTE: The /Reflectdrivers option is also supported with DE 7.1.3 Hotfix 1148978 or later, but the process is further simplified with DE 7.2.0 as a result of changes introduced in the product installer.

For detailed information about Windows 10 in-place upgrade with DE installed, see KB87909.
To view the Supported platforms, environments, and operating systems for DE, see KB79422.

Compatibility for DE 7.1.0 and later:

Do you support the in-place UEFI conversion tool (MBR2GPT.EXE) with Windows 10 Creators Update and later?
Yes. A Drive Encryption MBR to GPT tool (MdeMbr2GptTool.exe) has been developed, that works on Microsoft Windows 10 (version 1703) Creators Update and later (64-bit only). The tool works with the Microsoft tool (MBR2GPT.EXE) to convert a software-encrypted Drive Encryption drive from Master Boot Record (MBR) to the GUID Partition Table (GPT) partition style, without the need to decrypt the disk
To get the Drive Encryption tool and instructions, see KB89024.

What version of DE supports Windows 10 (version 1507)?
DE 7.1 Update 3 (7.1.3) is the first version to support Windows 10, but is released ahead of the Windows 10 general release. So, there might be caveats that apply to the deployment and use of DE 7.1.3 on Windows 10 systems.

See the following articles for specific details about upgrading Windows 10 when DE is installed:
Windows Release Article
Operating System (OS) refresh from Windows 7 or 8 KB79908
Windows 10 November Update (version 1511) KB84962
Windows 10 Anniversary Update (version 1607) KB87909
Windows 10 Creators Update (version 1703) KB89482

Additional Windows 10 general facts:
  • To view details about Windows 10 compatibility with McAfee products, see KB85784.
  • The Windows 10 option "Go back to the previous build” is supported with DE installed and active.
  • Windows 10 LTSB/LTSC is supported with DE 7.2.2 and later.

Is a Windows operating system with DE installed on Mac hardware supported?
No. DE has not been tested on any Mac hardware and is thus unsupported.

Can I run the Microsoft Upgrade task to upgrade a Windows 8.0 system to Windows 8.1?
No. Microsoft is using functionality that lays down a new WIM image and is essentially an operating system Refresh Process and not a traditional upgrade or Service Pack upgrade. But, DE has a documented OS Refresh Process that allows you to upgrade from Windows 8.0 to Windows 8.1 and keep the existing data encrypted throughout the entire process. For assistance with this process, see the following:
  • Windows OS Refresh Recommended Process Guide for Master Boot Record Systems Only, see PD24854.
  • Windows OS Refresh Recommended Process Guide for UEFI Systems Only, see PD24855.

Can I use the Windows 8 or later Automatic Repair (enabled by default)?
No. We recommend that you disable this feature. Automatic Repair of an encrypted disk might inadvertently destroy the encrypted operating system files and cause permanent boot problems. Previous versions of Windows asked whether you wanted to repair your system before starting the repair. But, Windows 8 starts Automatic Repair immediately when a problem is detected, leaving little scope to prevent destruction of encrypted data. For information about disabling Windows 8 Automatic Repair, see article KB76649.

Why must I use the DE 7.1 OS Refresh Process when I do not use it on Windows BitLocker systems?
Microsoft implements a mechanism that exposes the BitLocker encryption key during the upgrade, allowing the WIM overlay process to run. McAfee does not adopt this approach because it leaves the system vulnerable to attack during the Windows upgrade process.

Microsoft has talked about a new feature called Device Encryption. What is it?
Microsoft Device Encryption can be considered a scaled-down, non-managed version of BitLocker. Additional Device Encryption general facts:
  • Microsoft Device Encryption is automatically enabled if the hardware matches or exceeds its minimum hardware requirements.
  • If you deploy DE to a system that has Microsoft Device Encryption automatically enabled, your system meets the minimum hardware requirements, has been automatically enabled, and has encrypted the disk, the following happens:
    • Pre-activation checks determine that BitLocker is active. Remember that Microsoft Device Encryption is simply a non-managed version of BitLocker.
    • DE activation fails because the disk is already encrypted with Microsoft Device Encryption.
    • This status is reported back to ePO.
  • IMPORTANT: The following applies if you have a new system that meets the Microsoft Device Encryption minimum hardware requirements, but have Windows 7 and DE 7.1 installed, and then decide to upgrade to Windows 8.1:
    • If you have not logged on with an MSDN account, the system does not try to enable Microsoft Device Encryption.
    • If you have logged on with an MSDN account, it does break the operating system.

Back to Top

Does DE support Windows compressed drives?
No, Windows compressed drives are not supported because no compatibility testing has been undertaken.

Are there plans to support JAWS for Windows screen reading software for the preboot client, to help users with poor eyesight?
No. JAWS is a Windows-only software product and does not work at the preboot authentication point because Windows is not yet loaded.

Does DE work with the new Dell Cylance Advanced Threat Protection Technology, which can report if a Boot attack is detected?
No. DE has not been tested with Dell Cylance Advanced Threat Protection.

Does DE support Intel Anti-theft technology, which can lock the computer based on hardware?
No. Intel has discontinued Intel Anti-Theft Service.

Does DE 7.1 support Intel Smart Response Technology (SRT)?
Yes. Data is always safe, even the cached data. The Intel SRT is a smart cache component that only caches frequently accessed data. This cache is at the sector level and is encrypted by the DE filter driver.

Does DE support Intel Rapid Start (IRS)?
No. IRS requires an extra partition space on the Solid State Drive (SSD) or Hard Disk Drive (HDD), called the Hibernation Partition. This partition must be equal to or larger than the amount of system memory. This partition does not have a drive letter. IRS provides a low-power S3 state where, instead of storing state to DRAM in S3, the memory contents are flushed to the dedicated partition on the SSD. Because the BIOS is responsible for flushing to and from the SSD, DE cannot intercept and encrypt the content. So, any sensitive data in DRAM is written to the disk in plaintext. This issue affects only the S3 state, not S4.
NOTE: IRS technology enables your system to resume faster from sleep; this fact saves time and power consumption.

Is the DE 7.1.x client compatible with Microsoft BitLocker?
No. It is not compatible with BitLocker or any other Full Disk Encryption or Sector Level Encryption software running on the same system. DE detects Windows BitLocker during the DE activation process and stop the activation of DE if BitLocker is active.

Is Active Directory required for a DE 7.1 installation?
No. You can install the installation (MSI) packages without access to Active Directory because of the new User Directory feature included in DE 7.1. See the Functionality section for details. Additional Active Directory general facts:
  • Active Directory is required to manage DE 7.1 clients via ePO.
  • Although Active Directory is required for a DE 7.1 activation, a DE 7.1.0 new feature allows offline activation to activate DE without a connection to ePO. When the system can successfully communicate with ePO, the client moves into an Online mode. Only systems that ePO does not manage, can remain encrypted without the need to be connected to Active Directory.
  • Assigned users are not deleted from the ePO database if the object name such as a Group or User is changed in Active Directory. The object name change will be detected on the next run of the 'LdapSync: Sync Across Users from LDAP' task and updated in ePO. During the following ASCI, any user object name change is synced to the client.

What happens to my endpoints if the ePO server goes down?
If the product is already installed and active, clients continue to operate with the cached copy of the policy. No additional policy updates or user assignments occur until the client can communicate with the ePO server. If the product is not yet installed, it cannot activate until communication with the ePO server is re-established.

Can I use a Windows bootable CD on an encrypted system?
A bootable CD works on an encrypted system unless you want to access the hard drive. One advantage of full disk encryption is that it prevents a bootable drive from being used to access the hard drive without authenticating. If Windows is not working properly and you have to repair it using the Windows setup disk, you must first decrypt the drive before you use any Windows repair tools. To access the encrypted drive and DETech WinPE Recovery, you have to create media. For more information about how to create the media, see PD24204.

Back to Top

What operating systems are supported with DE?
For up-to-date details of current supported operating systems, see KB79422.
NOTE: The following also applies to the article named above.
  • The minimum ePO versions supported by DE 7.x.
  • The minimum McAfee Agent (MA) supported by DE 7.x.
Which EEPC versions can upgrade to DE 7.1.x?
The following upgrades are possible:
  • EEPC 7.x - (End of Life)
    Systems installed with EEPC 7.0.x can upgrade to DE 7.1. But, you must first upgrade the EEPC extension to either EEPC 7.0 Update 2 (7.0.2) or Update 3 (7.0.3).
    Follow the detailed steps described in the Drive Encryption 7.1 Product Guide (PD24867). See KB79912 for documentation corrections.
  • EEPC 6.x - (End of Life)
    If you are using EEPC 6.1.2 or later, you must first upgrade all extensions to either EEPC 7.0 Update 2 or Update 3. Client systems running EEPC 6.1.2 or later can be directly upgraded to DE 7.1. ePO installations with either EEPC 7.0 Update 2 or 3 extensions checked in can be upgraded directly to DE 7.1. Before upgrading EEPC 6.1.x or 6.2.x clients to DE 7.1, McAfee strongly recommends that you review KB81522 for further details.
    Follow the detailed steps described in the Drive Encryption 7.1 Product Guide (PD24867). See KB79912 for documentation corrections. This article describes the steps needed to upgrade to DE 7.1, a process that also requires installation of the EEAdmin 7.0.4 extension.
  • EEPC 5.x - (End of Life)
    Systems installed with EEPC 5.2.6, 5.2.12, and 5.2.13 can migrate directly to DE 7.1.
    Follow the detailed steps described in the Drive Encryption 7.1 Migration Guide PD24870. See KB79912 for documentation corrections.

What steps must I follow if I want to upgrade to the latest version of DE 7.2.x but already have an earlier DE 7.1.x version installed?
If you have an earlier version installed, such as DE 7.1.0, but want to upgrade to a later DE 7.1.x version, perform the following steps:
  1. Ensure that there are no LDAP Sync tasks running. If any are running, wait for them to complete.
  2. Disable all LDAP Sync tasks before initiating the upgrade.
  3. Install the DE 7.1.3 extensions.
  4. Check in the DE 7.1.3 Agent and PC software packages.
  5. Re-enable all LDAP Sync tasks.
  6. Deploy the DE 7.1.3 software packages to the client system.
  7. Restart the client system after the deployment task has completed.

Back to Top

Why the EEAdmin extension is required:
Because of the changes to the LDAPSync and User Directory, there must be a migration of existing encryption-related user data across to the new structures. EEPC 7.0.4 includes a task called "User Data Upgrade" that moves any existing data across to the new structures. Additional EEAdmin general facts:
  • The EEPC 7.0.4 EEAdmin extension supports ePO 5.1.x.
  • The length of time to retain the EEPC 7.0.4 extension is to keep it as short a time as possible. Only use the EEPC 7.0.4 extension until you have performed the User Data Upgrade. When that is complete, immediately upgrade to DE 7.1.
  • When an admin tries to go to DE 7.1 without first checking in the EEPC 7.0.4 EEAdmin extension: First, the installation of the DE 7.1 extension fails because it does not run on your ePO version. Second, you could not update ePO to the minimum version because your existing ePO extensions for encryption do not support it. Third, you are not able to upgrade because it detects that you have not run the User Data Upgrade task successfully. The EEPC 7.0.4 EEAdmin extension is a compulsory step in upgrading to DE 7.1.

What is the User Data Upgrade?
The User Data Upgrade is a server-side process that migrates all existing encryption user information to the new LDAPSync and User Directory internal structures.

IMPORTANT: Do not perform any user-related encryption actions while the User Data Upgrade Task is running. While the User Data Upgrade Task is running, all user-related actions are disabled in ePO. Additional User Data general facts:
  • The User Data Upgrade can only be run on ePO v5.1.x. Although it is possible to install the EEPC 7.0.4 extension on earlier versions of ePO, you are not allowed to run this task until you have upgraded your ePO server to ePO 5.1.x.
  • This task is an ePO-only task. The task does run software that simply moves data around internal structures in the SQL Server. The data is moved to the new structures and then verified for accuracy and completeness before completion.
  • The time the User Data Upgrade takes to run depends on how much user information you have in your database. As a rough indication:
    • 2,000 Users take about five minutes.
    • 10,000 Users take about eight minutes.

    NOTE: The performance varies depending on the specification of the SQL Server and its current workload. These figures are taken from a test system with an i5 processor and 4 GB of RAM. Other items that can affect the time are the inclusion of other pieces of user token data such as Single Sign On (SSO) data and self-recovery data.
Additional User Data Administrator role facts:
  • Because of the new Data Structure, any existing user data must be updated. To accomplish this update, you must run the User Data Upgrade process to upgrade all existing user data to the new internal structures.
  • The existing user data must be updated to the new data structures used by the User Directory and LDAP Sync extensions. This update is a one-time process that must complete before you upgrade to DE 7.1.
  • When something goes wrong with the User Upgrade, review the ePO Server Task Log. You also see the Audit Log entry with failed status for the same task. It is not possible to revert the EEPC 7.0.4 EEAdmin extension, but existing EEPC client systems can be managed with the EEPC 7.0.4 EEAdmin extension installed.
  • It is possible to rerun the User Data Upgrade if it fails. It can roll back the data and re-enable all user-related functions automatically. It can be run as many times as needed until it has completed successfully.
  • Features that are disabled in ePO while the User Data Upgrade task is running:
    • No new users are processed by Add Local Domain Users.
    • No user-related work is performed (that is, new passwords or other related user token information).
    • User-related WebAPIs are also disabled.

    But, the following are still available:
    • Export machine keys
    • Challenge / Response (machine only)
    • Any non-user recovery functionality (Active Management Technology (AMT) or non-AMT)
  • If you try one of the above on the client or ePO during this time, all client actions fail gracefully, or are disabled/blocked in the ePO User Interface.
Additional User Data user experience facts:
  • The clients experience the following changes during the User Data Upgrade task:
    • The existing received policy on the client remains enforced.
    • New policies come down to the client while the User Data Upgrade task is running; but they are not enforced.
    • Newly captured passwords, or other token data, cannot be sent to ePO and propagated to other systems while the upgrade task is running.

      NOTE: If there is a recovery, a computer recovery is still available as is a self-recovery, but a challenge/response for resetting a password is not available.
  • The user-related actions are only re-enabled when the User Data Upgrade task completes successfully and the ePO extensions have been upgraded to DE 7.1. If it has failed and rolled back the data operations, the user-related actions are also enabled.

I am setting up a new ePO server and want to move DE clients across to it. Is this action supported?
Yes. This scenario is supported in DE 7.1.3 and later.
  • With earlier versions of DE, transferring a system from one ePO server to another replaces the user assignments and user token data on the system, with data from the destination server. There is a potential to lose user assignments and change user credentials in the preboot environment.
  • DE 7.1.3 introduces a client transfer capability that provides the ePO Administrator with a mechanism to allow systems to be transferred from one ePO server to another while preserving user assignments and user data. If the feature is enabled, a DE 7.1.3 system detects a server change. It requests that the new DE 7.1.3 managing server automatically assign users to the system in the context of the new managing server. When the assignment is successful, the system sends its user token data up to the new managing server. Any systems that have failed the system transfer process are highlighted on the destination server via an intuitive out-of-the-box report.
  • A separate DE 7.1.3 Client System Transfer Guide is included in the release that describes this system transfer process in detail. For details, see PD25905.

What do I have to consider if I install to a Windows 8.x system using native UEFI?
If you plan to install DE 7.x on a Windows 8.x system using native Unified Extensible Firmware Interface (UEFI), McAfee recommends that you only use native UEFI mode, if the system is explicitly Windows 8 certified. McAfee also recommends that you upgrade your UEFI systems to the latest UEFI firmware level and test on a specific native UEFI-capable system before wide-scale deployment. NOTE: For other UEFI questions and answers, see the Functionality section below.

Do I have to decrypt and re-encrypt the clients during the upgrade to DE 7.1?
No. The upgrade process is designed to transfer the key from the old agent to the new agent.

Can I automate the DE users and systems migration from one ePO server to another?
For how to migrate DE users from one domain to another, see KB83802.

During the installation process, what methods are available to avoid all users using the same default password?
There are two methods:
  • Via the DE policy, you can forgo using the default password and force users to be prompted to enter a password they choose.
  • Use a policy assignment rule with a different User-Based Policy (UBP) where you define a different default password for those users assigned the UBP.

Can I install DE on a system and take a RAW image (sector by sector) to use on new computers?
No. This scenario is not supported. It would introduce a security problem because every system would have the same security key.

Back to Top

Can I change the size of the tablet on-screen keyboard displayed during preboot if I think the default size is too small?
No. To submit a Product Enhancement Request to include this functionality, see the Related Information section.

Do I need to add VirusScan Antivirus exclusions for DE?
No. Antivirus exclusions are no longer required.

Functionality features and functions:
Cold boot attacks
Contextual Security
Encryption keys (offline activation)
Elevated Security Crypt Mode vs. Standard Crypt Mode,
Fast Initial Encryption (Used Sector Only)
Hardening systems
Hybrid Boot,
Intel Active Management Technology
Intel Software Guard Extensions (SGX),
Offline activation
Offline user
Organizational Units,
Preboot users
Power-failure Protection
Preboot Files System
Preboot Smart Check
Reactive Autoboot
Remote Remediation
Reset Password
Secure Boot
TPM (Autoboot)
User Directory
UEFI Windows 8
Wake and Patch (Remote Unlock)


Functionality FAQs applicable to DE 7.2.0 and later How does DE 7.2.x use Intel Software Guard Extensions (SGX)?
Intel SGX is an Intel Architecture extension, introduced with 6th Generation Intel Core processor platforms, that is designed to increase the security of software through an inverse sandbox mechanism. In this approach, legitimate software can be sealed inside an enclave and protected from such threats, irrespective of the privilege level of the threat. The alternative is to try to identify and isolate all potential threats or attack surfaces on the platform.
Using Intel SGX with DE further improves protection against memory-based attacks (such as the cold-boot attack) without affecting performance on systems that support SGX and with suitable policy applied.

How do I enable SGX with DE 7.2.x?
To ensure that DE uses SGX where available, support for SGX must be enabled before DE 7.2.0 is deployed to a target system.
For further information about the technology requirements for this new feature, see KB87256. Back to Contents

Functionality FAQs applicable to DE 7.1 and later Can I repartition a disk that is encrypted with DE?
No. It is not possible to change the partitioning of a disk that is already encrypted. You need to fully decrypt the disk and uninstall DE before performing the repartitioning of the disk.

What is the key length used by the encryption algorithm AES256?
The key length used is 128-bit.

Is Raid supported?
There are two types of RAID technologies to consider: Computers with hardware or software RAID:
  • DE is untested with hardware RAID, but we expect that DETech will work properly in environments where pure hardware RAID has been implemented. This expectation covers systems that have internal RAID cards or external RAID systems with a built-in controller.
    NOTE: DE/DETech cannot support diagnostic or disaster recovery for a broken raid configuration when hardware RAID is in use.
  • DE/DETech does not support software-based RAID. Windows dynamic disks are a form of software RAID.
Computers when the BIOS SATA Mode is configured to use RAID or RAID ON:
In general, DE/DETech works in RAID mode as long as the BIOS SATA mode of that computer can see the disk.

  • In Legacy/MBR BIOS mode DE relies on Int13 calls to access the hard-disk (HDD) of the computer.
  • In Unified Extensible Firmware Interface (UEFI) mode, DE relies on the system input/output protocol, so DE is agnostic to the BIOS SATA mode. The only caveat to this statement is, if the disk is an OPAL or Self Encrypting Drives (SEDs) HDD, DE must be set to Advanced Host Controller Interface (AHCI) mode. The reason is because DE has its own controller driver and does not rely on the BIOS for hard-disk access.
    NOTES: The caveat only applies to hardware encryption of an OPAL or SED drive, and not if the OPAL HDD is configured for software encryption.

Is possible to encrypt a removable media storage device connected through a USB port?
No. DE detects and encrypts the drive only if it is detected through a SATA port.

What is the DE User Directory?
The User Directory extends your ePO-managed DE to systems with unmanaged, non-domain users. In addition to users managed in Active Directory, DE can now also use these ePO-managed users for preboot authentication.
User data is now synchronized from Active Directory and cached locally in ePO. This fact eliminates the need for constant round trips from ePO to Active Directory and results in significant performance improvements for user-based policy checks. Additional User Directory general facts:
  • User Directory removes the dependency on Active Directory
  • An Administrator must install the User Directory extension. You can do this install before or after you have upgraded to DE 7.1.x, as long as the ePO prerequisites are met, which is ePO 5.1.x
  • There are no conceptual differences between the standalone users in EEPC 5.x and the users in the User Directory
  • Migrate EEPC 5.x standalone users to the User Directory.
  • You can create Organizational Units (OUs) in the User Directory.
  • Users can be added to and removed from an OU.
  • Users can be moved from one OU to another OU
  • OUs can be nested.
  • A user cannot belong to more than one OU
  • When selecting an OU, you can see all users that make up that OU (including nested OUs).
    NOTES: You can see all users from sub OUs, but not all nested OUs. From the distinguished name, you can see which sub OU each user comes from.

Regarding scripting, does the ePO WebAPI change for User: Machine assignments?

Back to Contents

What is Trusted Platform Module (TPM) autoboot?
TPM autoboot is a new offering in DE 7.1 that strengthens the traditional autoboot functionality by using a TPM, if the hardware is present, to protect the key.

The TPM provides a sealing mechanism whereby encrypted data can only be decrypted if the system is in a predefined state. During system startup, the TPM measures the firmware and all boot components. Measuring consists of extending a hash stored in a TPM register with the code about to be executed. The firmware performs these measurements, which cannot be bypassed. Effectively, the TPM only allows the decryption of the key if the system is in the same state as when it was sealed. Any change, no matter how small, causes it to fail. Additional TPM general facts:
  • TPM autoboot is different from traditional autoboot in that traditional autoboot provides no security for the system. The key used to encrypt the disk is written in plaintext to the disk. TPM autoboot secures the key by encrypting it with the TPM; it is no longer in plaintext.
  • TPM helps secure the key because the TPM can decrypt the key only if the system state has not changed. If the TPM believes that the system state has changed, or a new TPM chip is present (for example for a new motherboard), it does not decrypt the key. If it cannot decrypt the key, the autoboot functionality fails and the preboot authentication is displayed.
  • With TPM autoboot enabled, the system continues to automatically boot, but only if the TPM believes that everything is in order. In this situation, the user does not see the preboot environment and it simply boots into Windows.
  • TPM autoboot can be used with reactive autoboot.
  • TPM Autoboot and reactive autoboot can be used with the new Connected Standby support and hardening of systems against cold boot attacks functionality.
  • If the motherboard is changed, or the TPM boot measurements change, the User sees the preboot authentication screen. If a user has gotten into this situation, they need to perform a Challenge / Response Recovery to gain access to Windows.
    If valid preboot user credentials are known, the user can simply authenticate and boot into Windows. But, because the user has been in this autoboot mode, the chances of them knowing a valid user credential is low.
  • TPM does more than encrypt the key. It also measures the boot path. Every time the system boots, we hash some data about the boot path into the TPM. The result is that the TPM only decrypts the key if the boot path has not been changed.
    This fact means that after TPM autoboot unlocks the disk, it is not possible to boot to another boot path. If a different boot option is selected on startup, the autoboot functionality fails and the preboot is displayed.
Additional TPM Administrator role facts:
  • The policy settings for TPM autoboot are under the title "User TPM for automatic booting" and it has the following three options:
    • Never - Disk key is written in plaintext to the disk. This option is the original autoboot functionality.
    • If Available - If the system has a usable TPM, the TPM is used to encrypt the key. If no TPM is available, or is unusable, the TPM present on the system has the key written in plaintext to the disk according to the original autoboot functionality.
    • Required - Autoboot only works if the system has a usable TPM. The DE preboot environment is displayed on systems that do not have a TPM.
  • IMPORTANT: If Microsoft updates the Windows bootLoader during a Windows update, the boot measurements have changed. As a result, TPM cannot decrypt the key and you must go through a recovery process, which requires a Help Desk call, to have the system boot successfully again.
    NOTE: The DE preboot is also in the boot path. So, when an administrator rolls out a new version of DE, including a hotfix, update, or new version, and it updates the DE preboot EFI Application, the boot measurements also change.
  • Similar to the Windows update scenario, users will have to make a Help Desk call to access their system after DE pushes an update.
  • The minimum requirements for TPM autoboot are:
    • DE 7.1.x/7.2.x only support TPM Autoboot on TPM 2.0 systems (all Connected Standby Systems support TPM 2.0). NOTE: Older systems with TPM 1.2 do not support this feature.
    • DE 7.1 Update 1 (7.1.1) and later add support for TPM 1.2 chipsets (UEFI systems only).
    • The TPM owner key must be managed locally and not in the Active Directory.
    • The system must include the TPM UEFI protocol in the OEM’s UEFI implementation (a requirement for Connected Standby systems).
Additional TPM user experience facts:
  • When TPM cannot decrypt the key, it displays the preboot environment and asks the user to authenticate. If TPM is in any doubt, it does not automatically boot the system and instead displays the preboot environment and waits for authentication.
Back to Contents

Can I now handle a larger number of users in preboot?
The preboot environment has now been improved to support more than 5,000 users without perceptible performance degradation during preboot authentication. The previous limit was a maximum of 250 users in preboot. You can now safely provision all users to share desktops, which enables any user to use any system.

What is the recommendation for the number of users assigned for preboot authentication?
The general recommendation remains unchanged. Assign only the minimum number of users for preboot authentication. Additional preboot authentication general facts:
  • Although DE 7.1 and later increase the number of users that preboot can support to thousands rather than hundreds, it is recommended to minimize the number of users assigned per node.
    First, best security practice aims to limit the number of users that can access a system to the smallest group of users.
    Second, assigning large numbers of users to each node might affect the overall scalability of the entire system and reduce the maximum number of nodes that DE can support.
  • The following penalties apply if you allow 5,000 users to log on at preboot on a computer:
    • Activation takes longer because it needs to download all information about the 5,000 users.
    • Synchronizing user information takes longer, increasing the workload on the ePO server.
    • Other actions that include user information take longer to process. An example of these actions is Saving the Machine Information about a client, because it also includes user information.
    • Scalability of an ePO server can be affected. Your ePO server performs more work per agent-server communication intervals (ASCI) to ensure that all information is up to date.
      Suppose that you have 100 systems that each have 5,000 users assigned. Take the most common occurrence, a changed password. For a user, that would be captured on one system, uploaded to ePO, and then pushed down to the other 99 systems when they sync with ePO.
      If you force users to change their passwords every 90 days, 5,000 users must update their password. The result is 500,000 updates (5,000 users x 100 systems) that the ePO server must process at various times as the systems synchronize with ePO.
  • A large number of users causes increased network traffic. All this traffic is handled across the network. Although individual user data is small, generally < 20 kilobytes, it is multiplied out by the number of transactions. If one of your systems has a slow link, it could take a considerable amount of time to receive all changes. If the server is handling user updates for many clients, the network traffic could also be significant. In the worst case, it might not receive all updates in a sync period.

What is AOAC?
AOAC means Always On, Always Connected. Microsoft calls it 'Connected Standby' and Intel refers to it as 'Smart Connect'. They all basically refer to the same high-level functionality. It is the ability to keep a system in a low-power sleep mode, periodically wake it to retrieve data, such as emails or Facebook updates, and then have it go back to sleep again. This activity occurs without the user knowing or intervening. Think of it being similar to the way your mobile phone works. Additional AOAC general facts:
  • DE 7.1.x supports an AOAC Model. Support is provided through Connected Standby. While it is in this standby mode, the Windows logon is used to protect the data from unauthorized access.
  • AOAC changes Full Disk Encryption. Full disk encryption has historically been about protection of data at rest (when the system is turned off). Various companies are introducing AOAC functionality and driving user expectations that their system will always contain fresh content.
  • With the AOAC model, the system and services need to be able to access the disk. That means the encryption key for the disk always remains in memory. But systems that support AOAC are more vulnerable to cold boot style attacks because the key is always in memory. Remember that the system does not turn off; it is only in standby.
  • All AOAC and Connected Standby functionality still works when this functionality is enabled.
  • When the system is sleeping, the data is never at rest with the AOAC model. The systems are not turned off; they are only in standby. The AOAC model requires the disks to remain 'unlocked' because:
    • Systems might wake periodically or via a push notification.
    • Applications and Services might require access to the disk during this awake period.
  • You can use AOAC functionality with preboot, the autoboot functionality, or both. This functionality works regardless of your method of authentication. But, McAfee does recommend that you use one of the following:
    • Preboot
    • If autoboot is chosen, enable TPM autoboot with reactive autoboot or the integration with Intel’s Active Management Technology.

How does DE harden systems against cold boot attacks?
A high-level overview of this new DE functionality is that on modern Windows platforms that can support the new 'Connected Standby' mode, the user can have an iPad-like experience. These systems are always in a powered-on state requiring the encryption key to be always in RAM, making them susceptible to memory scrubbing attacks that can scrub the encryption key from RAM.
DE can operate behind the scenes delivering a native Windows experience to the end user. When the device enters the 'Connected Standby' state, DEerases the encryption key from RAM and moves it to a secure area on Intel hardware hardening systems to prevent against cold boot and memory scrubbing attacks. When the device moves into an active state, the encryption key is transparently moved back to RAM after successful user authentication to Windows.

Back to Contents

What is a cold boot attack?
A cold boot attack is a way of extracting sensitive data from system memory when the system is turned on or in a standby state, even if the system is protected by a Windows password. The attack involves either of two actions:
  • Hard rebooting the system and running a small program on the next boot cycle that scans system memory for sensitive information
  • Removing the RAM from a powered-on system and translating to another system for scanning
Additional Cold Boot general facts:
  • DE hardens systems against a cold boot attack when a system enters one of the standby modes. DE 7.1.x removes the key from memory. It is stored in a secure location that is still accessible while in Connected Standby. The system continues to function as an end user expects; but, the system is less vulnerable to a cold boot-style attack because the key is no longer in memory.
  • DE completely removes the key from memory. This functionality hardens the system against memory-style attacks. Although every effort has been taken to ensure that the key is removed from memory, McAfee cannot guarantee that it is completely removed because of the way Windows manages memory. Further hardening work will be done on this functionality in future releases.
  • The only condition in which the key is put back into memory is after a user has successfully authenticated to Windows. Simply having Windows running does not put the key back into memory.
  • When the key is not in memory, it is held in a secure storage area that is not in memory. The key can be removed from memory when any of the following events occur:
    • The system is turned off.
    • The user logs off.
    • The user locks the workstation.
    • The system is waiting for a user to authenticate at the Windows logon prompt.
    • After the system wakes up from standby or sleep.
    Looked at another way, if users have authenticated and they are at their desktop, the key is in memory. If users have not authenticated, or are not at their desktop, the key is not in memory.

    NOTES: An Administrator can select, via a policy, under what conditions the key is removed.
  • Although only one driver is required to handle the key in memory, it does operate in one of two modes. Those two modes are:
    • Standard Crypt
    • Elevated Security Crypt

What is Standard Crypt Mode?
It is a state of the encryption driver where:
  • Encryption key is stored in RAM.
  • Not secure against RAM-based or Cold Boot-style attacks.
  • Highly optimized for performance.
  • Uses the same algorithm implementation as in previous legacy EEPC 7.x releases.

What is Elevated Security Crypt Mode?
It is a state of the encryption driver where:
  • Uses a new implementation of the AES256-CBC encryption algorithm.
  • Encryption key is stored in a secure location, not in RAM.
  • ISO
  • Comes with a significant performance penalty.
  • Policy enforcements are disabled while in this state.
Additional Elevated Security Crypt general facts:
  • The driver swaps between the two modes and is defined by a policy.
    Example: DE 7.1 can swap into the Elevated Security Crypt Mode when the system is:
    • Locked
    • Logged off
    • Has entered into Standby mode
      NOTE: Standard Crypt mode resumes when the user has successfully authenticated to Windows.
  • This functionality can be used with TPM autoboot.
  • The boot time is slower in the Elevated Security Crypt Mode. From the initial boot, the key is not stored in memory until the user has successfully authenticated to Windows. If you are using a tablet, you rarely shut down completely, so you will not always experience this issue.
  • When the system performs a high disk intensive task and the workstation is locked, the workstation runs slower when the user returns later. The reason is because when the system is running in the Elevated Security Crypt Mode where the key is not in memory, you have a performance penalty when performing the task.
  • In the Elevated Security Crypt Mode, you have a security vs. performance trade-off. The important thing to remember is that when a user is actively using their system, then the normal full performance is experienced. It is only the periods where authentication has yet to occur that the user experiences the performance impact.
  • Example of the performance impact when the driver uses the Elevated Security Crypt mode:
    Looking at raw algorithm performance: 64-bit AES-NI Capable processor:
    • Standard Crypt = 1 CPU clock cycle/byte
    • Elevated Security Crypt = 15 CPU clock cycles/byte
    32-bit non-AES-NI capable processor:
    • StandardCrypt = 35 CPU clock cycles/byte
    • Elevated Security Crypt = 133 CPU clock cycles/byte
    NOTE: The impact can be higher than the above raw algorithm because of the tests being executed with interrupts disabled. Looked at another way, purely as an example: If a system experienced a throughput of 208 Mb/Second in Standard Crypt, it can drop to 20 Mb/Second in Elevated Security Crypt.
Are there any hardware requirements for using this Elevated Security Crypt Mode functionality?
Yes. This information is provided in KB79291.
NOTE: The system needs to support Connected Standby and it must be either a Clover Trail tablet or a Haswell system.

Is there a difference between 'Connected Standby' and 'Smart Connect'?
Yes. Smart Connect is an older technology/design in the sense that it has a driver that periodically wakes the system and dials into a server to pull notifications. Connected Standby is a new technology where the system goes into a new power state on the CPU.
Connected Standby requires new hardware to support it; Smart Connect does not. So you can have Smart Connect on a Windows 7 system with older CPU and hardware. Technically speaking, Smart Connect uses the power state S3, which is Sleep. Connected Standby uses the power state RTD3, which is a different state on the CPU.

What is Connected Standby?
Connected Standby is not really a true sleep mode. It runs in this new power state and leaves some services running that can receive notifications from the server. So, it has hardware requirements and is available only on Windows 8.x systems.
Example: The hardware requirements for Connected Standby on Windows 8 take advantage of Connected Standby if all following hardware requirements are met:
  • A firmware flag indicates support for the standard.
  • The boot volume does not use a rotational disk.
  • Support for NDIS 6.30 by all network devices.
  • Passive cooling when in Connected Standby.
NOTES: There are additional security-specific requirements. For example, memory must be soldered to the motherboard to prevent cold boot attack vectors that involve removing memory from the computer, and support for Secure Boot.

Back to Contents

Is it possible to clone an existing hard-disk (HDD) to a larger disk, make the new disk bootable, and extend the size under Window’s environment?
No. To migrate to a larger HDD, you must first decrypt the HDD, complete the cloning, and then re-encrypt.

Is it possible to perform a remote wipe of an encrypted system?
No. Preboot does not have networking functionality.

Why does Windows 8 require a significant change for encryption products?
Microsoft introduced many new features with Windows 8 and later. The ones that affect encryption the most are:
  • A Unified Extensible Firmware Interface (UEFI) Boot Process
  • GPT Disk partitioning
  • Secure Boot
  • Hybrid Boot
  • Windows 8 Modern User Interface (UI)
  • Windows 8 Tablets
Additional Elevated Security Crypt general facts:
  • Windows 8.x has two possible boot methods. Depending on your system's configuration and capabilities,
    Windows 8 either installs the capability to boot with the new UEFI Boot process or the legacy BIOS boot process.
  • You cannot change a configuration setting and swap Windows 8 from one boot process to another. You need to completely reinstall Windows 8 because of the change in the partitioning mechanism.
  • From Windows 8 and later, DE has two preboot environments. A preboot to handle the UEFI Boot Process and a preboot to handle the BIOS boot process.
    The DE Intelligent Client examines which boot process the system is configured to use, and determines which preboot needs to be installed. This fact allows an administrator to deploy DE to systems and know that the appropriate preboot will be installed automatically.
  • DE 7.x does not use the modern Windows 8 user interface (UI). After Windows has loaded, the only DE UI in Windows 8 is the tray status monitor, which is only available on the desktop. It is not available in the Modern UI.

What is Autoboot?
Autoboot is an account that effectively bypasses the protection provided by DE where the user does not see the preboot authentication screen.

What is Reactive Autoboot?
Reactive autoboot is an enhancement to the traditional autoboot functionality that exists on Windows and OS X. As in autoboot mode, the drive is encrypted, but the user does not see the preboot authentication screen and boots directly into the OS.

Unlike traditional autoboot, reactive autoboot has one additional piece of functionality. When enabled, the product monitors Windows authentication requests. If an end user exceeds a specified maximum number of authentication failures, reactive autoboot automatically enables preboot authentication, disables autoboot, and immediately restarts the computer. After these actions occur, the user must successfully pass preboot authentication before gaining access to the OS and the data on the drive. This functionality allows the authentication policy to automatically transition from autoboot (unlocked, insecure) to preboot (locked, secure) based on certain conditions designated by the Administrator.
  Additional Reactive Autoboot general facts:
  • To enable reactive autoboot (not enabled by default), an Administrator must do two things: select the product policy setting Disable and restart system after <n> (1–10) failed logons or unlocks (Windows only, Vista onwards), and specify the number of failed logons or unlocks allowed. The policy must then be assigned to the systems that require the reactive autoboot functionality.
  • A good example for the use of reactive autoboot is if you might want to encrypt shared systems that any user in the organization might need to access. As a result, you cannot assign a specific user or group of users for preboot authentication. Reactive autoboot might be an acceptable solution for such cases where you would otherwise be forced to deploy using autoboot.
  • The drives are encrypted on a system with reactive autoboot if so defined in the encryption policy. But, because authentication is not enabled when autoboot is enabled, the data is not protected.
What are the key features of Reactive Autoboot?
  • This feature is client-side only; this functionality is a client-only. Audit events are uploaded to ePO on the next sync, but the ePO server has no interaction with this functionality.
  • This feature is Windows-only. Reactive autoboot is not offered on Mac OS X. Because of Apple changes, Management of Native Encryption (MNE) has replaced the EEMac product. For details, see KB79375.
  • You can specify the maximum number of failed attempts. An ePO administrator can specify this number in the policy. It has a minimum value of 1 and a maximum value of 10.
  • Applies to all Windows authentication attempts. It applies to both Windows logons and unlock attempts.
  • It works with both Software Encryption and Opal.
  • Users can use the Challenge/Response Recovery to allow the system to access Windows when a user exceeds the maximum defined failed attempts.
  • A Windows user can be either part of a Workgroup or Domain user.
  • Events are audited. An ePO administrator can see which systems have enabled. The event 30070:“Automatic Booting Deactivated – Exceeded maximum failed logons" is sent to the ePO Server, but only after the next successful authentication to Windows, and when connectivity to ePO is possible.
    NOTE: The moment that the system thinks it is under attack, it disables autoboot and restarts the system. There is no time to send an event to ePO, so ePO is not aware of the lockdown as it is implemented.
  • No administrator action is required to re-enable reactive autoboot on a system where it was disabled because of failed Windows Authentication attempts. After the client has restarted the system and accessed Windows, reactive autoboot is re-enabled automatically. The system does not need to communicate with ePO to re-enable autoboot.

What is the User experience when the system uses Reactive Autoboot?
  • When end users turn on their computers, they boot directly into Windows. Autoboot means that there is no preboot authentication. Users go directly to the Windows logon. Assuming they always successfully authenticate to Windows, their experience does not change.
  • The end user will experience the following after exceeding the maximum number of failed Windows authentication attempts:
    • Preboot authentication is automatically enabled, and autoboot is disabled.
    • An ungraceful shutdown of Windows occurs, and the system restarts.
    • When the computer restarts, the preboot authentication screen displays and the user must successfully authenticate to gain access to Windows.
  • After a user exceeds the maximum defined failed attempts, a user will not be able to:
    • Authenticate using Windows credentials
    • Use Self-Recovery to pass preboot and access Windows
      NOTE: If the system has always worked in autoboot mode, this fact means it is likely that no DE users have been assigned to allow any successful preboot authentication.
  • A user, to gain access to Windows when presented with preboot authentication, must either authenticate at the preboot screen or go through one of the standard recovery mechanisms to gain access to Windows.

How do I re-enable reactive autoboot and disable preboot authentication to go back to my previous workflow?
The user must successfully authenticate at preboot or go through the needed recovery process to access Windows. After Windows loads and the DE services start, reactive autoboot is re-enabled automatically.

What Intel Active Management Technology (AMT) Integration features work with Reactive Autoboot?
  • Although in theory you can use the Location Aware use case from the Intel AMT integration with reactive autoboot, the combined usage does not make sense for two main reasons. First, while reactive autoboot is enabled, the AMT functionality is not used in preboot because the system boots directly into Windows. Second, from a security and usability perspective, it is better to use the AMT functionality and the 'Location Aware' use case to enable a secure and authorized automatic booting of the system into Windows. If you have enabled this functionality, it is the more secure solution compared to reactive autoboot.
  • You might consider using AMT to remove or reduce Help desk calls from end users when the reactive autoboot functionality enables preboot. Although this functionality might reduce or remove the need for a Help desk call to continue past the preboot environment, you can still encounter a scenario where the Help Desk call is required. More importantly, the AMT functionality provides data security by requiring an automatic preboot authentication to be provided by the server. By contrast, autoboot has no preboot authentication and provides no data security.
  • When both the AMT integration and reactive autoboot are used, and if the user fails to authenticate too many times, although the end-user experience appears to be the same with these methods, there are back-end differences:
    • Reactive autoboot is an insecure solution that boots into Windows using cryptographic information already present on the client.
    • The Intel AMT integration is a secure solution that contacts ePO and requests permission to boot into Windows; it then receives the needed cryptographic information to do so.

    Example Scenario:
    • On a client system using reactive autoboot, the AMT functionality in preboot is not used. When a user fails to authenticate repeatedly, reactive autoboot enables preboot and restarts the system.
    • Preboot uses AMT and contacts the ePO and receives permission to boot. If ePO does not respond or returns a negative response, the user is in the same situation as traditional reactive autoboot without AMT.
    • The user is returned to the Windows logon screen and reactive autoboot is enabled because the system has booted into Windows. The user can continue to enter incorrect passwords until Windows disables the user.
    • This scenario might force a Help Desk call. Reactive autoboot is a client-side activity, and there is no communication with the ePO server and no time to communicate with the server when the functionality responds to failed logon attempts.

    IMPORTANT: If you have enabled the Intel AMT 'Location Aware' use case, McAfee recommends that you use that functionality and not reactive autoboot, because it provides data security by authenticating from the server. If needed, you can set a Windows policy to disable the user if they fail to authenticate after a set threshold.
Back to Contents

What is Fast Initial Encryption (Used Sector Only)?
Fast initial encryption is the ability to install the DE product on a system and perform encryption in a matter of minutes (compared to several hours that are required in normal circumstances). Fast Initial Encryption (Used Sector Only) key features:
  • Fast Initial Encryption primary function is for the initial encryption of a newly installed/imaged system. The system is sitting on a desk of an IT Technician and is not being used by an end user. You can see the 'In-House Provisioning' or 'Provisioning by a third party' use cases from the Offline Activation FAQs.
  • This feature cannot be used with an Opal drive. There is no need to use Fast Initial Encryption with an Opal drive because the drive is technically encrypted all the time. The DE activation process enables the locking mechanism for the drive. Currently, an Opal drive goes from Inactive to Active and fully encrypted in a matter of minutes. Also see the Offline Activation FAQs.
  • You cannot use Fast Initial Encryption as part of the normal activation process.
  • To view a detailed document covering the advantages of encrypting your computer in minutes using Fast Initial Encryption functionality, see KB81093.
  • Fast Initial Encryption can be used with a normal Hard Disk Drive (HDD) or Solid State Disk (SSD). But it is important to read the considerations about Used Sector Only (see below).

Additional Fast Initial Encryption (Used Sector Only) general facts:
  • Fast Initial Encryption removes the power failure protection (which provides protection against data loss in a power-failure or hard-shutdown scenario), and performs the initial encryption as quickly as the hardware allows. It also encrypts only the sectors that are currently in use.
  • Fast Initial Encryption differs from the way DE 7.1 and earlier releases worked. Traditionally, the product assumes that it is encrypting a system that is in use. It prioritizes the end-user experience to minimize impact on the end user's daily routine. This fact has the benefit of allowing the user to continue working while encryption occurs and provides protection against power failure or a hard shutdown. In this standard deployment, the encryption process takes longer to complete because the product encrypts every sector of the volumes/partitions that were specified in the encryption policy. Even blank sectors that contain no data are encrypted.
  • Fast Initial Encryption only encrypts used sectors. The product queries the operating system for which sectors are in use by the file system. The product then encrypts only those sectors that are flagged as being used in the volumes and partitions specified in the encryption policy. On a new installation, this number is generally a small subset of the total size of the disk.
  • When new data is written to the disk, as new sectors become used, they are encrypted.
  • Fast Initial Encryption is only available on Windows with DE 7.1. Because of Apple changes, MNE has replaced the EEMac product.
  • To enable Fast Initial Encryption as part of an offline activation package, use one of the following two options:
    • SkipUnused (Default value is disabled)
    • DisablePF (Default value is disabled)
  • This feature is not enabled by default for offline activation. You must explicitly enable Fast Initial Encryption.
  • Fast Initial Encryption is available only as a part of the offline activation process. The offline activation option is called Skip Unused Sectors.

Additional Fast Initial Encryption (Used Sector Only) user experience facts:
  • When Fast Initial Encryption is enabled, the user must type Yes when using Used Sectors Only. This act ensures that you have read the disclaimer and understand the usage of this functionality. It is important to read the considerations about Used Sector Only.
  • When a user does not type Yes when prompted, the offline activation package is not built and the process fails. You need to rebuild the package again and correctly type 'Yes' or remove the 'Used Sectors Only' option from the package.

Does the Fast Initial Encryption option Used Sector Only affect HDD and SSD in the same way?
There is a larger impact and implication on SSDs because of the way SSDs operate. For more information about performance issues reported on some SSDs, see KB66256. Additional Used Sector Only general facts:
  • The Used Sector Only option means that there will be sectors on the disk that are not encrypted. The product only encrypts the sectors that the Operating System states are in use. All other sectors (white space) are left in an unencrypted state until they are used, even if those sectors contain previously deleted sensitive data. Any new sectors written during normal operation are written in an encrypted state.
  • The recommendation for using Used Sector Only option applies to both a new HDD and SSD. This functionality can be used before any sensitive company data is written to the disk.
  • When you are recycling an older drive that was fully encrypted with DE, this functionality can still be used, assuming all volumes that contained sensitive data were previously encrypted. If that condition is not met, McAfee recommends that you not use this functionality.
  • To view data that shows the improvements when using Fast Initial Encryption (Used Sector Only), see KB77844.
  • IMPORTANT: Do not use this functionality on disks that previously contained sensitive company data. Encrypt the entire volume/partition/disk.

Can I restart a computer while the hard-disk is being encrypted?
There are two scenarios to consider:
  • You cannot restart while using Fast Initial Encryption and when the DisablePF feature is enabled. A system restart under these conditions would lead to a loss of data.
  • With Full Disk Encryption (FDE), a restart is possible. With FDE, encryption continues when the computer has restarted. But, be aware that if the computer is shut down before the disk encryption process has completed, your data might not be fully protected at rest.

What is the maximum size HDD that DE supports?
Whatever the BIOS or UEFI supports, DE supports. BIOS is technically limited to 2.2 TB, where UEFI is limited to 9.4 ZB.
For further details about the UEFI limitation, see http://www.uefi.org/sites/default/files/resources/UEFI_Drive_Partition_Limits_Fact_Sheet.pdf

Can I still perform a normal or offline activation with Power-failure Protection enabled and encrypt all sectors, not just the ones in use?
Yes. You must explicitly enable Fast Initial Encryption for it to be used. If it is not enabled, the normal process for activation and initial encryption is used.

Can I disable the Power-failure Protection option but allow the Used Sector Only encryption functionality?
Yes. Any combination of the two options can be selected. But, because of the potential security concerns when using 'Used Sector Only' encryption on recycled drives (dirty disks), it is possible to disable this option. It is important to read the considerations about Used Sector Only

Back to Contents

What is UEFI?
UEFI (Unified Extensible Firmware Interface) defines the next-generation firmware interface for your personal computer. The Basic Input and Output System (BIOS) firmware, originally written in assembly and using software interrupts for I/O, has defined the PC ecosystem since its inception. But, changes in the computing landscape have paved the way for a modern firmware definition to usher in the next generation of tablets and devices. Additional UEFI facts:
  • UEFI is managed through the UEFI forum, a collection of chipset, hardware, system, firmware, and operating system vendors. The forum maintains specifications, test tools, and reference implementations that are used across many UEFI computers.
  • The intent of UEFI is to define a standard way for the operating system to communicate with the platform firmware during the boot process. Before UEFI, the primary mechanism to communicate with hardware during the boot process was software interrupts. Modern PCs can perform faster, more efficient block I/O between hardware and software, and UEFI allows designs to use the full potential of their hardware.
  • UEFI allows for modular firmware design that enables hardware and system designers greater flexibility in designing firmware for the more demanding modern computing environments. Whereas I/O was limited by software interrupts, UEFI promotes the concept of event-based, architecture-neutral coding standards.
  • DE 7.1 supports UEFI version 2.3.1 and later.
  • Windows 7 (64-bit) and Windows 8 (32-bit and 64-bit) and later systems support a UEFI Boot Process.

What are the key features of using UEFI with DE?
  • There are different recovery tools for systems with a UEFI boot process. Because it is a different boot process, a different recovery tool is required to handle the different boot processes.
  • DETech is also a UEFI application. There is a DETech application that is used for recovery on systems with a UEFI boot process.
    NOTE: You cannot use the (legacy) BIOS DETech tools with a UEFI booting system.
  • IMPORTANT: A system with a UEFI boot process does not work with MBR partitioned disks. Windows requires a new mechanism for disk partitioning, called GPT, to boot under UEFI.
  • All supported tokens and readers should work in both BIOS and UEFI with the following exceptions:
    • All biometric tokens
    • SafeNet’s eToken USB tokens
    To review the supported tokens for authentication in DE 7.1.x, see KB79787.
    To review the supported Readers for authentication in DE 7.1.x, see KB79788.
  • DE preboot is an application. If you consider that UEFI is like an Operating System, the DE preboot becomes a UEFI native application. In comparison, the BIOS preboot version is an OS of itself. In both, the DE preboot needs to run first so that after a successful authentication, the encryption key can be loaded and the boot process can continue. In the UEFI world, when a user successfully authenticates at the DE preboot, the EEPC preboot application simply terminates and allows the next application in the chain to run (traditionally the OS Boot Loader).
  • Not all touch-screen devices are supported in UEFI. If you think of UEFI more like an operating system, the OEMs need to provide software drivers for the hardware contained in that device. For UEFI, the preboot supports both the Simple Pointer Protocol and the Absolute Pointer Protocol. One or both of these protocols are expected to be implemented for all touch-screen devices encountered. If a manufacturer or OEM of the UEFI implementation has failed to implement either of these mechanisms, support for the touch-screen device cannot be guaranteed.
    NOTE: McAfee has found in its own internal testing that not all UEFI implementations from OEMs actually implement these interfaces. In these instances, the creator of the UEFI implementation on that system is leaving out sections of the UEFI specification.

  • GPT drives are supported with UEFI. They are supported as boot or secondary disks.
  • UEFI implementation across all vendors. UEFI implementations differ by hardware vendors. Depending on the UEFI implementation, issues can range from missing protocols required to support Opal drives, to issues in USB support provided in the preboot environment used by DE when operating in native UEFI mode.
  • Opal drives supported in UEFI:
    • Support for Opal self-encrypting drives on UEFI systems is available only on Windows 8 or later logo-compliant systems that were fitted with an Opal self-encrypting drive when manufactured.
    • Support for Opal self-encrypting drives under UEFI is not offered when retrofitting Opal drives to pre-Windows 8 systems, or to Windows 8 systems that were not shipped with Opal drives from the manufacturers. The reason is because a UEFI security protocol that is required for Opal management is mandatory only when a self-encrypting drive is fitted at the time of shipping. Without the security protocol, Opal management is not possible.
    • NOTE: This fact does not affect support for Opal drives under BIOS. For a list of supported drive models, see KB81136.

Is there support for GUID Partition Table (GPT) drives? Windows 7
As a boot disk, no. As a secondary disk, yes. Also, it is up to the OS to support the secondary drive in GPT mode, and for the BIOS to support large disks for DETech (Standalone) to be able to recover them.

Windows 8 and later
Primary and Secondary GUID Partition Table (GPT) disks are supported on Windows 8 with DE 7.1.0 and later.

  • UEFI-based systems can only boot from a primary GPT disk.
  • BIOS-based systems cannot boot from a primary GPT disk. On these systems from EEPC 7.0 and later, GPT disks are only supported as a secondary drive.

What is the User experience when the system is using UEFI?
Both preboot environments look and behave the same. An end user would not be able to tell the difference between the UEFI and the BIOS preboot environment.

Why must I create and use DETech WinPE recovery media when the DETech Standalone version includes more functionality, such as being able to do an Emergency boot?
  • The WinPE version is much faster than the standalone version.
  • The WinPE version also allows you to access the encrypted hard disk, fix Windows problems, or copy user data off to another drive before reimaging.
  • You can also run any of the Windows tools as well, and access the network.

    NOTES:  DETech Standalone is not backward-compatible. Always use a matching DETech recovery media version. If the client has DE 7.1 installed, create a DETech 7.1 Standalone recovery media to perform any recovery actions.

    IMPORTANT: It not possible for McAfee to provide customers with a WinPE recovery CD because a valid Microsoft license is needed.
Back to Contents

What is Secure Boot?
Secure Boot is a feature enabled by UEFI, but Microsoft mandates specific implementations for x86 (Intel) PCs. Any system with a Windows 8 logo sticker has Secure Boot enabled.

UEFI has a firmware validation process, called Secure Boot, which is defined in Chapter 27 of the UEFI 2.3.1 specification. Secure Boot defines how platform firmware manages security certificates, validation of firmware, and a definition of the interface (protocol) between firmware and the operating system. It creates a root of trust starting in UEFI, which validates the next module in the chain before loading and executing it to ensure that it has not changed since it was digitally signed. With the Secure Boot architecture and its establishment of a chain of trust, the customer is protected from malicious code executing in the boot process. Only signed, certified 'known good' code and boot loaders can run before the operating system itself loads. Additional Secure Boot general facts:
  • DE 7.1.x does support Secure Boot.
  • DE is signed, so the Secure Boot process trusts it.
  • Secure Boot does not work on Windows 8 or later BIOS-based systems. It works only on UEFI-based systems.

What is Hybrid Boot / Fast Startup / Fast Boot?
In previous versions of Windows, a traditional shutdown would close all user sessions, services, and devices, and would also close the kernel to prepare for a complete shutdown. Windows 8 closes the user sessions, but instead of closing the kernel session, Windows 8 hibernates it. The result is faster shutdown and start times.
NOTE: Microsoft Windows 8 adds support for Fast Boot (previously known as hybrid boot); with the release of Windows 10 and later, this feature is now known as Fast Startup. Additional Hybrid Boot, Fast Startup, Fast Boot general facts:
  • DE 7.1.x does not support Hybrid Boot / Fast Startup / Fast Boot. This Microsoft feature is not supported because some DE features are impacted if the above is enabled.
  • Single Sign On (SSO) works in a Hybrid Boot. DE supports SSO on a resume from hibernate, unlike the previous EEPC releases.
  • DE 7.1 includes enhancements across all areas of performance, which are unexceptionally experienced with an AES-NI capable processor. In internal testing, DE has experienced comparable encrypted/non-encrypted boot times using Hybrid Boot.

I see references to Windows RT. What is it?
Windows RT (formally known as Windows on ARM) is a version of Windows 8 for ARM devices. Only software written for the Windows 8 Modern UI interface runs on Windows RT, except for Microsoft Office 2013 RT and Internet Explorer 10. Any application written using the Win32 APIs, which is most current applications, does not run on Windows RT.

What is a Windows  Tablet?
A Windows Tablet is a tablet-style device capable and certified to run Windows. There are two major categories of Windows tablets:
  • Tablets powered by Intel processors
  • Tablets powered by ARM processors
Additional Tablet general facts:
  • DE 7.x does not support Windows Tablets using an ARM processor and Windows RT
  • DE 7.x does support Windows Tablets using an Intel processor. These tablets are seen as any other Windows system. But, examine the following cautions:
    • CPU capability
    • Touch-screen support
  • CPU capability on the Tablets. The product development team has noted that some previews of Windows tablet devices from manufacturers contain lower powered processors, some of which do not have AES-NI capabilities. Customers must be aware of CPU capabilities to ensure that the end user has an optimal experience when the system is encrypted.
  • Touch Screen Support on Tablets.
    Some Windows Tablets have keyboards, so touch-screen support is not an issue. For the devices that do not have keyboards, they require that the end user authenticate using the touch interface in preboot.
Back to Contents

What is offline activation?
Offline activation is the ability to activate DE without a connection to ePO. Additional Offline activation general facts:
  • High level process for offline activation:
    • An administrator creates an offline package on the ePO server. This package contains the first policy that needs to be created, and a list of 'offline users.'
    • After the package is created, it can be distributed to the necessary clients with the MSIs needed to install DE. When DE is installed successfully, the offline package is run and the policy is applied and enforced.
    • You can now log on with the 'offline users' in preboot.
  • There are no audit logs in ePO to find information about a system activated via offline activation because the system has never communicated with ePO; there is no information about that system.
  • If a device is activated only via offline activation, you are not able to prove that it was encrypted. If the system has never communicated with ePO, there is no information in ePO that can be used for auditing purposes if there is loss or theft. After the system communicates with ePO and goes into an online mode, all normal information will be present in ePO to prove the encrypted state of the system.
  • Add Local Domain Users (ALDU) does not work offline activation. ALDU is a two-step process that requires ePO to perform the user/system assignment. Because ePO is not available with offline activation, ALDU cannot complete and cannot be used.
  • To define the initial policy for offline activation, use the parameters available in the offline package creation utility.
  • When a system that was enabled by offline activation successfully communicates with the ePO server that generated the McAfee Agent, DE, and Offline Activation package, it discards all offline users and asks ePO to provide the assigned users.

What are the Use Cases for offline activation?
  • The three primary use cases addressed by offline activation are:
    • In-house provisioning.
    • Provisioning by a third party.
    • A remote system that will never connect to ePO.
NOTE: There are other use cases where offline activation can be useful; but, DE 7.1 focuses on these three use cases.
  • An in-house provisioning use case for offline activation is where you might have your own provisioning process. The process might state that a system needs to have the operating system installed, plus all company-approved applications, and must be fully encrypted before it is handed to the end user. At the point of provisioning, you might not have network connectivity because the devices might be sitting on a shelf in a separate room.
  • Provisioning by a third-party use case for offline activation. You might have an external third party to provision your devices. In this scenario, you don't want to open up your firewall to allow connections to ePO, yet you require that all laptops need to be encrypted before delivery.
  • The use case for offline activation for a remote system that never connects to ePO. You might have a client, used in a remote location, that has no network connectivity, but it might be collecting sensitive data and needs to be encrypted. You can distribute a CD with the MSIs required to install McAfee Agent, DE, and also an Offline Activation package. These MSIs can then be run to install and activate DE and encrypt the system.

How does recovery work for offline activation?
If the administrator has selected to save the encryption key, the key is written in an encrypted manner to a file on a disk. It is then the responsibility of the end user to transfer that encrypted key to the administrator using a company-approved method. When administrators have the encrypted key, they can decrypt it when needed using the ePO server that created the offline package. The result of this decryption process is a standard XML file that can be used with the DE recovery tools.

Additional Offline activation general facts:
  • There is only one recovery option available for an offline activation. This option is a local recovery using the DE recovery tools.
  • If the administrator disabled local recovery, the only choice is to use the DE Recovery tools to correct any issues with the system. It is also possible to connect the system to ePO, at which point the users and policies would be replaced with the information provided by ePO. But, this scenario requires the ability to boot into Windows.
  • There are no additional recovery options for offline activation if local recovery is disabled and you have not saved the encryption key.

What are the key features about offline activation for installation?
  • Consider systems activated by offline activation as unmanaged systems. The reason is because you might not see them in ePO, and you will not be able to manage them in ePO.
  • IMPORTANT: There is not a standalone, non-managed version of DE for systems that are offline activated. Offline activation might allow you to create a standalone system that is encrypted per a specific policy. But, after the first policy enforcement is complete, you cannot update the policy or the users. There is no local console and no method to update the policy or user information. But, a key recovery mechanism is supported. For details, see the offline user recovery FAQs below.
  • For offline activation, the important fact is that DE can be installed on the system. The installation method you use - for example, a CD/DVD to end users with MSIs they can run, or a more automated method - depends on your specific environment.
  • The following installation requirements are required for offline activation:
    • McAfee Agent
    • McAfee Endpoint Encryption Agent
    • DE
    • Offline Package that was created by the Administrator
  • A system can be activated through offline activation to ePO at a later time for ePO management.
  • When an offline activated system connects to ePO, the following occurs:
    • Assuming that the offline activation was done for provisioning purposes, the system will at one-point connect to ePO.
    • When the system can successfully communicate with ePO, the client moves into an Online mode.
    • Online mode is defined as a normal connection between the McAfee Agent and ePO; consider it the same as a normal install.
      In addition:
      • It discards the offline policy that was enforced, and it also discards all offline users. It receives the real policy from ePO, the list of assigned users as per a normal activation, and saves its encryption key in ePO. You could view it as a second but automatic activation.
        IMPORTANT: Remember that all offline information is discarded if the user is not known to the ePO server before connection. If the offline user is known to the ePO server, the ePO policies are deployed, but any data they have stored while in offline mode is not discarded.
Back to Contents

What is an offline user?
An offline user is one who is used for preboot authentication and that exists only in a specific offline package. Additional Offline User facts:
  • An offline user is different from a normal user in DE. Offline users exist only in that specific offline package. These users do not exist in Active Directory, and basically do not exist anywhere except in this offline package.
  • You cannot add more offline users to an offline activated system after activation is complete and it has been out in the field for a while.
  • An offline user starts with the default password
  • You can recover a password if an offline user forgets it because end users can use the local recovery functionality to recover.
  • Considerations for using tokens (other than a password) for offline users:
    • Passwords and smart cards that support Self-Initialization can work in offline activation.
    • Smart cards that are PKI only cannot work because there is no backend to retrieve the needed information to authenticate the user.
    • Biometric support is not possible.
    • Self-Initializing tokens are identified in the DE Supported tokens article KB79787.
Additional Offline User recovery facts:
  • When an administrator disables Local Recovery, offline users are locked out. If there is another user on the system they can use, they might be able to boot the system. Or, connect the system to ePO. But, this alternative requires being able to boot into Windows.
  • When the offline end user has forgotten both their password and their local recovery answers, the user is now locked out. If there is another user on the system, they might be able to boot the system. Or, connect the system to ePO. But, this alternative requires being able to boot into Windows.

If you have an offline user called Bob and an AD user called Bob, when he goes from offline to online, what would happen to the password for Bob?
Assuming that AD user Bob has signed into the system at least once, and ALDU was active on the ePO policy, then Bob is assigned to the system after the offline Bob was discarded.
NOTE: From this point, the AD user Bob can have two possibilities. If logging on at preboot for the first time, he has the default password. If not, and if ePO already has credentials for Bob, those credentials from ePO are on the system.

Is an offline policy the same as a policy defined in ePO?
No. There are some policy settings that require interaction, such as Add Local Domain Users (ALDU). These policy settings cannot be used in an offline activation. Additional Offline Policy general facts:
  • You cannot update the policy of an offline activated system after activation is complete and after it has been out in the field for a while. Offline activation only enforces the first policy. There are no possible updates after the first policy is applied.
  • When a system that was enabled by offline activation successfully communicates with the ePO server that generated the McAfee Agent, DE, and Offline Activation package, it discards the offline policy and asks ePO to provide the appropriate policy.
  • The following settings are available for an offline policy:
  • Back up the Device Key
  • Path to the recovery key
  • Enable temporary autoboot
  • Enable autoboot
  • Don’t display the previous username
  • Enable SSO
  • Enable boot manager
  • PBFS Size
  • Opal PBFS Size
  • Require user changes their password
  • Username must match Windows logon username
  • Enable self-recovery
  • User smart card PIN
  • Enable USB in preboot
IMPORTANT: When the computer is fitted with an Opal drive, offline activations use Opal Encryption first. OPAL preferences are hard-coded in the Offline Activation Packages and do not use the custom policy settings. Back to Contents

What happens to the encryption keys during offline activation?
When the administrator configures the offline activation package, there is an option available to indicate whether the keys are saved or not. The decision of whether to save the keys, and to which location, is solely at the discretion of the administrator. It is not something the end user can choose or manipulate. Additional Encryption key general facts:
  • When you have received the encrypted key, an administrator can decrypt it and export the information in the XML format used by the DE recovery tools.
  • If you save an encryption key from a system that has completed the offline activation process, you are not able to import the key to ePO for recovery purposes. But, you can store all your keys in a secure location and use ePO to decrypt them and generate the needed recovery XML files.
  • If the encryption keys cannot be saved because of some other fault, the hard disk on the client must be reformatted and the Offline Activation process restarted.
  • The encryption key is not written to a plain text file on the disk. The encryption key is always encrypted; if a third-party intercepted the key, it would not be useful for them, nor would they have a way to identify to which system it belonged.
  • The only location where the encryption key for an offline activation can be decrypted is the ePO server that created the offline package. No other ePO server can decrypt the key.
  • All offline activations do not have the same encryption key. During the first policy enforcement, the encryption key is generated. This fact ensures that all offline activations have a different key.
Additional Encryption key use cases facts:
  • Regarding the encryption key for the system in the in-house provisioning use case:
    You might or might not want to save the key. Remember that on the first connection to the ePO server, it uploads the key. Because this scenario primarily covers new systems, if any physical defect is found that causes the disk to crash, or you become locked out of a system, there is little user data, if any, to lose.

    NOTE: You can save the key to a USB stick, or a specific network share in case a recovery is required.

  • Regarding the encryption keys for the system in the provisioning by a third-party scenario:
    It is likely that you do not want the third party to be able to save the encryption key, so you would specify to not save the key anywhere. If the third-party had copies of each encryption key for all systems in your organization, that would be considered a security risk. Because this scenario primarily covers new systems, if any physical defect is found that causes the disk to crash, or you become locked out of a system, there is little user data, if any, to lose.
  • Regarding the encryption keys where the encryption keys for the system never connect to ePO:
    It is likely that you will want to save the encryption key to a USB stick or to the hard disk. This step is optional and is purely at the discretion of the administrator. It is then your responsibility to ensure that the encryption key is safely transported to ePO for safekeeping. This transport can be achieved by any mechanism that your organization approves for encryption keys. After the ePO administrator has a copy of the saved key, it can later be used for recovery purposes.
Back to Contents

What is included in the PreBoot File System (PBFS)?
The PBFS contains all needed information to provide the user with the ability to authenticate. This information includes but is not limited to:
  • The files needed for the preboot environment
  • Language files for all supported client languages
  • Fonts to display characters from all supported languages
  • The theme assigned to the client
  • The users assigned to the client
Additional PBFS facts:
  • If you deploy to a client and increase the size of the PBFS in the policy later, the PBFS size does not change on the deployed client. The reason is because the PBFS size setting is applied only when the PBFS is created or when it is re-created during any recovery procedure.
  • It is possible to create and customize preboot themes in ePO.
  • You cannot force during preboot an English keyboard when first installing DE 7.x to a non-English operating system. The reason is because by default, the DE installer displays the localized keyboard associated with the localized Windows operating system that the product is installing to.

How long does it take for a newly created user to be available in PBFS?
There is no short answer to this question. The following scenarios try to cover the most common situations:
  • Scenario 1
    If only one uninitialized user is assigned to a system, only one ASCI is required given that the user is verified by the EE LDAP Sync task in ePO. NOTE: An uninitialized user is a user that has not previously logged on any DE system. So no token data is present for this user.
  • Scenario 2
    If a new uninitialized user is added to a system that already has users assigned, it might require two ASCIs before the user is fully available in the PBFS.
  • Scenario 3
    If an initialized user is newly added to a system that might or might not already have users assigned, two ASCIs are required until the user is fully available in the PBFS. The reason is because this user has its token data already initialized.
To summarize: When a user gets assigned to a system, the policies for this system are incremented and during the policy enforcement, an event to request user data is triggered. When that event is returned by the ePO server, all users that have been assigned are checked/downloaded to the client. If for those users, a difference in the local token data and ePO stored token data is found, a second event is triggered to update these details.

For an uninitialized user where there is no token data, the secondary event is not needed to pull all required user data down to the client and then into the PBFS. As for the other scenarios, it requires two events to make a user fully available in the PBFS.

In addition, if the customer is using the policy option Add Local Domain User (ALDU), there is a 2.5 ASCI timeout that is triggered if the ALDU request is not responded to. If this timeout is exceeded, a new policy enforcement is required to upload user data for verification.
What are the DE 7.x custom theme requirements?
Create the custom theme according to the following requirements:
  • An image with dimensions 1024 x 768
  • Ensure that the file format is .PNG
  • A file size of about 600 KB
NOTE: Users upgrading from EEPC 6.x must be aware that a new default theme is shipped as part of DE 7.1.x. If you are using customized themes with EEPC 6.x, re-create your custom themes from DE 7.1.x default theme after upgrade. This approach ensures that the correct user interface is displayed and the correct audio is heard. Failure to do so continues to display the EEPC 6.x user interface and use the EEPC 6.x audio. Those users who want to deploy the new default theme to all their existing endpoints, or have their own custom theme, must follow the steps outlined in the DE 7.1 Release Notes. These steps make sure that they are using the correct theme during PBA. For details, see PD24866.

What is the Pre-Boot Smart Check (PBSC)?
The PBSC is functionality in DE that performs various preboot hardware compatibility checks to ensure that the DE preboot environment can work successfully on a system. It tests the areas that have been identified to cause incompatibility issues in the past. Additional Pre-Boot Smart Check general facts:
  • The goal of the Pre-Boot Smart Check is to help with providing a hassle-free deployment of DE full disk encryption by checking for common error conditions in the preboot environment. Without the checks enabled, productivity could be affected where deployment issues might lock users out of the system. Pre-Boot Smart Check deactivates DE if there is an issue, and allow the system to roll back to Windows-only authentication.
  • The Pre-Boot Smart Check functionality is not enabled by default because it introduces one or more system restarts to the activation process. Some customers can accept this situation, and others might not.
  • When Pre-Boot Smart Check finds a problem, either a failure to load preboot or a problem handing over to Windows, the system restarts automatically or the user must forcibly restart the system.
    This allows PBSC to try a different set of compatibility configurations to overcome the problem. If any configuration works, and the system boots into Windows, the DE becomes fully activated and the encryption policy is enforced. If all compatibility configurations are tried, and unrecoverable problems are encountered, DE preboot is bypassed, the system boots into Windows, and DE is deactivated. At this point, an audit is sent to ePO alerting the failure, and subsequent activations on the system are blocked.
  • When a system passes the Pre-Boot Smart Check, it activates DE and enforces the encryption policy.

What happens if a system fails the Pre-Boot Smart Check?
If a system fails the Pre-Boot Smart Check, it does not activate DE. So, DE activation (and encryption if set in the policy) does not proceed, and the system "rolls back" to Windows-only authentication. Additional Pre-Boot Smart Check failure general facts:
  • The administrator sees in ePO, for a system that is still running through the Pre-Boot Smart Check, that the system is not activated and not encrypted. They can view the audit log to get the latest information about any progress from the last time the system synchronized with ePO.
  • The Administrator is able to know that a system has not activated because when it fails the Pre-Boot Smart Check, the failure is audited.
  • For an administrator to see that a system has failed the Pre-Boot Smart Check, view the audit log for the system.
  • If a system fails the Pre-Boot Smart Check, it keeps trying to activate DE at the next policy enforcement. But, activation is immediately abandoned. All subsequent activations are immediately abandoned until either of the following happens:
    • You disable PBSC from policy
    • You delete the registry value: Software\McAfee Full Disk Encryption\MfeEpePc\SafeFailStatus\Status

    NOTE: Also, a workaround could be to set up an automatic response in ePO based on the Event ID. That way, when an event arrives in ePO (the event that indicates PBSC failure), ePO can automatically assign a new policy to that system. That policy would be configured to disable DE and thus stop future activation attempts. See the ePO documentation for further information.

How can I know if the Pre-Boot Smart Check made any changes to the configuration or if the system worked straight out of the box?
This information is not exposed in DE 7.1. It is transparent to the end user and happens automatically.

If the Pre-Boot Smart Check has not made any changes and the system worked out of the box, does that indicate that I can disable that check for deployment purposes?
It is at the discretion of customers whether they disable the check. But, variability is common among systems that have the same model number. For example, a user could have gone into the BIOS and changed their USB settings.
Changes to USB settings might affect integration with that BIOS, so keeping PBSC would add value here. But, if you use BIOS passwords to keep your users from making such changes, you might be safe not using PBSC.

Back to Contents

What versions of Intel Active Management Technology (AMT) are supported by ePO Deep Command and DE?
To see which versions of AMT are supported, see KB79422.

NOTE: The AMT version is part of the information that an administrator can view on a computer that is reported back by ePO Deep Command. Additional Intel AMT general facts:
  • An Administrator can learn how to determine if they can use Intel AMT functionality on a particular system by viewing the system properties in ePO. In ePO, you can see the AMT information for that specific system. McAfee ePO Deep Command Discovery and Reporting (free) also provides this information for all managed systems in ePO, and displays it in a dashboard. To be compatible with DE, Deep Command must report the AMT status as Post configuration. Also, DE requires AMT to be version 6.0 or later.
  • How the Intel AMT information about a system is transferred into ePO.
    • First, you have installed the Deep Command extensions, including the Discovery and Reporting extensions, and checked in the packages on the ePO server.
    • You must deploy the Deep Command packages to the clients, which report back if AMT is enabled. In addition, if the system has actually activated AMT, the client reports back what AMT features are supported.
    • Deep Command adds a schedule server task to ePO that automatically tags the systems with AMT. This task is scheduled to run daily and can be altered. See the ePO Deep Command documentation for more information.
    • If the system has not activated AMT, see the Deep Command Discovery and Reporting Summary Dashboard to obtain AMT support information from a client.

How many types of Intel AMT actions can be queued against a system?
Two types:
  • Transient Actions
  • Permanent Actions.

    Examples of Permanent and Transient Actions:

    Transient action is an action that is executed x number of times and then removed from the action queue. Below are some examples:
    • Reset User Password
    • Unlock x number of times
    • Unlock from until
    • Emergency Boot
    • Restore MBR
    Permanent action is an action that remains in the action queue until it is removed by the administrator:
    • Unlock Schedule
    • Unlock Permanently
Additional Permanent and Transient facts:
  • For each Intel AMT action, you only assign to a system/user a maximum of one Transient action and one Permanent action at any time.
  • You can only have one Intel AMT Transient and one Permanent action because this situation was a design decision for this first implementation of integration with Intel AMT. If additional use cases arise, this decision can be revisited. The underlying architecture has been designed to handle more actions if required.

What does Client Initiated Local Access (CILA) and Client Initiated Remote Access (CIRA) mean in relation to Intel AMT?
The definition of what is local and remote is defined as a part of the AMT provisioning process.
  • CILA is an AMT request from an internal network address.
  • CIRA is an AMT request from a remote network address.
NOTE: The default policy setting for CIRA is disabled by default. This decision was a conscious one by the product development team to protect customers from accidental exposure.
CIRA is supported and must explicitly be enabled. By disabling CIRA by default, it means that if a company has an Agent Handler exposed to the Internet, it will not respond to any AMT requests over the Internet. The product development team believes that customers need to decide whether they want to enable this functionality.

When I watch a Wake and Patch (Remote Unlock) or a Contextual Security (Unlock) on a client, the preboot seems to wait for about 20 seconds or more before it proceeds to boot into the operating system - is that normal?
There are many factors involved in determining how long this time might last. The speed of the network and the workload of the ePO server are two possible factors. A known issue exists in AMT firmware, which might lead to a 20-second delay before CILA events leave the endpoint. The effect of this issue on DE is that it might take over 20 seconds for an Out-of-band unlock to occur in a CILA environment. McAfee is investigating this issue. To review other DE 7.1 Known Issues, see KB84502.

What Deep Command policies and settings are required for DE 7.1 integration?
ePO Deep Command 1.5.0 and the Intel AMT policies are required. Ensure that the following are configured correctly in the policies:
  • Remote Access must be enabled.
  • Enable Client Initiated Local Access (CILA). Choose the correct agent handler.
  • For the Connection type, select BIOS and operating system.
  • If you want Client initiated Remote Access (CIRA), ensure that you have configured the following:
    • Home Domain Suffix
    • DMZ agent handler
    • Allow User initiated tunnel

What are the first DE use cases implemented in DE 7.1.x using Intel (AMT) and McAfee ePO Deep Command?
The first four use cases implemented in DE 7.1.0 are:
  • Reset Password
  • Contextual Security
  • Wake and Patch
  • Remote Remediation
Back to Contents

What is the Reset Password Use Case?
This functionality uses Intel AMT to send new token data out to a client. In this use case, a user has started their system and has forgotten their password. They can call a helpdesk or administrator and request that their password be reset. The administrator creates a one-time password that is pushed out via the Intel AMT to the client while in preboot. Using Intel AMT is a faster alternative for a password reset than the long-established challenge/response method. Additional Reset Password general facts:
  • The following are the high-level steps for the Reset Password Use Case:
    • The end user starts their computer, fails to log on, and calls the help desk.
    • The end user goes to the Recovery section in preboot and provides the help desk user with their ePO Username.
    • The help desk user finds the System the user is using in ePO.
    • The help desk user uses the Intel AMT functionality to reset their password with a temporary one-time password.
    • For the specified system to receive the new token data, ePO writes the item to the work queue, and then the preboot reads the work queue and fetches the key by using the network stack provided by Intel AMT.
    • The client receives the new token data and automatically leaves the recovery screen and goes back to the password screen. This fact is an indication for the end user that the new password has been received. Also, the end user hears a beep to indicate that the new token data has been received.
    • The end user then authenticates with their one-time password and sets a new password.
  • When a user requires a password reset, and because Intel AMT actions work on systems rather than users, to determine what system the user is on, then on the client, in preboot, the user can go to the recovery screen where they can view the Machine ID and Machine Name. They can give this information to the administrator or help desk and they can use that to find the computer in ePO.
Additional Reset Password Administrator role facts:
  • When an administrator needs to verify that a change went through successfully, or validate why it does not appear to work, the administrator can find the information in the AMTService.log.
    • An event is not generated in ePO because there is no ePO API to do generate an event from the agent handler.
    • The administrator can find the AMTService.log file on the ePO server at <ePO_Install_folder>/<Agent_Handler_Install_Folder>\DB\Logs\AMTService.log. It is also collected as part of the server MER.
  • When an administrator cannot determine what system the end user is using, and although it is possible for the admin to send the Intel AMT command to all systems that the user can access, the product development team does not recommend it.
    Assume that the user can access two laptops. They start laptop-1 and they receive the instruction to change their password. They go through the process and start Windows. They now turn on laptop-2, which also receives the request to change the password. Their token data is updated to the one-time password, and they are asked to change it again. While in theory this could work in a controlled environment or where the user is aware, there is a good chance it might cause end-user confusion.
Additional Reset Password user experience:
  • Administrator has just used the Intel AMT functionality to change the user’s password. The end user knows that the new recovery password has come through to the client. If the end user is sitting on the recovery screen (where they told the details of their Machine ID to the Administrator), they see the recovery screen disappear and be replaced with the logon screen. This indication confirms that the new password information has been received.
    • If the end user left the recovery screen and then waited for the updated password to be received, they might see the logon screen disappear and quickly reappear.
    • Also, when the new token data is received, the end user hears a beep.
Back to Contents

What is the Contextual Security Use Case?
The Contextual Security use case (also known as Location Aware) is a new authentication feature in the DE preboot environment. It gives systems the ability to authenticate without user intervention. Instead of asking a user for credentials, the preboot uses Intel AMT to initiate a network connection to ePO. Then, the preboot retrieves a key that it uses to authenticate in the preboot and then boots the computer into the operating system. The preboot environment and ePO can determine if the system is in the office or connecting via the Internet. Contextual security gives administrators the ability to configure systems to authenticate automatically via ePO and AMT while in the office, but when the system is out of the office it shows the preboot authentication screen.

Some example use cases where Contextual Security is useful are:
  • Customers who want to not show the preboot environment while their end users are in the office, but show it when they are outside the office or if the system is lost/stolen.
  • Customers who want to encrypt a system that is always in the office and not impact the end user with the notions of preboot and have them automatically authenticate via ePO and AMT. Also show the preboot if the computer is stolen from the office.
  • Customers who have shared computers used by many individuals. Think of a meeting room, training room, or laptops and desktops in a hospital environment, etc.
  • Customers who want to remove password synchronization issues by never showing preboot, while having its protection if the computer is lost/stolen. Users first authenticate at Windows even though behind the scenes, DE has automatically authenticated via ePO and AMT.

How does Contextual Security work?
When the preboot starts, it tries to reach out to ePO and asks for permission to boot. ePO is the master and decides whether to return the unlock key. If the client cannot reach out to ePO or ePO fails to return the unlock key to the client, the preboot environment is displayed and it waits for an end user to successfully authenticate. If ePO sends the unlock key, the computer is unlocked. The unlock keys are sent to the client down a secure channel, secured by the AMT hardware. Additional Contextual Security facts:
  • Contextual Security authentication actually occurs on the client and the necessary information comes from ePO.
  • Contextual Security does not bypass preboot. The preboot environment is always there and always active. Preboot still shuts down and boots the operating system when a successful authentication occurs. In this use case, the authentication comes from ePO.
  • Single Sign On (SSO) does not work in this Contextual Security use case because the authentication in preboot is done against the computer and not a user. Because DE does not know which user to log on, it cannot replay any captured SSO data.
  • With Contextual Security, the end user only needs to log in once. In this scenario, the user authentication takes place at the Windows prompt and not the DE preboot prompt.
  • Using Contextual Security means that the user only ever logs on to Windows with their latest Windows password. This fact can remove any concern about password synchronization for users who continually use this functionality.
  • With a mobile user who spends time in and out of the office, these users need their credentials to authenticate at preboot when they are not in the office.
  • The computer automatically bootasinto Windows as long as ePO sends back a positive response; it automatically boots the operating system after the response has been processed.
  • If a computer is stolen when using Contextual Security, it displays the preboot environment. This display happens because the system cannot communicate with ePO and waits for a user to authenticate.
  • The Most Unexceptional use case is to only use this for desktop systems or laptops that do not leave the office network.
Additional Contextual Security Administrator role facts:
  • For administrators to enable the Contextual Security functionality, they selectsone or more systems, select the 'Out of Band – Unlock PBA' action, and then specify the duration of the unlock, either permanently or to a schedule.
    NOTE: An administrator can also choose whether the action is actionable for local, or local and remote computers.
  • When an administrator receives complaints from a user that, from time-to-time, Contextual Security is not working, then to verify that on the ePO server, review the 'AMTService.log'. This file does roll over and has a file size limit (default size limit is set by Deep Command and is configurable).
  • When the administrator enables Contextual Security functionality, they can enable it permanently or for a defined period of time.
    For the defined period options, an administrator can specify one of the following:
    • One or more reboots
    • From start date/time to end date/time
    • A weekly schedule for blocked or available times
  • For mobile users, it is better to always enforce preboot authentication because technically an end user does not log on at preboot in this use case. DE is not aware of password updates because it does not know to which preboot user to apply any password updates.
  • When using Contextual Security, the system remains in the preboot environment and retries every five minutes when the ePO server is busy and cannot respond to the system.
  • If the system fails to reach ePO on the first attempt it tries again. It tries to contact ePO every five minutes. This behavior is true for CILA (Local) requests. But, for CIRA (Remote) requests, the computer only contacts ePO once. If it does not receive a response, the system must be restarted to reach out again.
  • When the ePO server becomes unavailable and the client cannot contact the ePO Server, if the user does not know their preboot credentials (a possibility if the user has always used this Contextual Security functionality), they are stuck in the preboot environment. Their only option is to call the help desk and do a system recovery with the challenge/response process.
  • When CIRA is enabled, it means a system that is not on the network cannot automatically boot. DE makes no decision on whether to display PBA. If DE 'Out of Band' management is enabled, then DE will try to send a call for help.
    The AMT chip then checks the environment and sees if it is plugged in on the Remote or Local Network. If it is plugged into the local network, it posts a CILA to the ePO server. But, if it detects that it is connected on a Remote network, and if a CIRA server was specified, it tries to securely connect to it. If any of the calls for help, whether CILA or CIRA, result in a successful connection with the server and the server decides to send the encryption key, then PBA unlocks and goes into Windows. Otherwise, if no key is received, it remains at PBA.
Additional Contextual Security user experience:
  • Example Use case:
    What do users do when they use a desktop system in the office with Contextual Security functionality, have never needed to log in to preboot before, but then see the preboot screen, and they do not know their credentials. Users have several choices:
    • First, they could wait five minutes for the next attempt to reach out to ePO. This is true because it is a CILA (Local) request.
    • Second, they can turn their system off and on again. This will cause the preboot to immediately reach out to ePO again when it restarts.
    • Last, they can always authenticate by entering the username/password of another known user who can authenticate at preboot, although this might not be available in all situations.
Back to Contents

What is the Wake and Patch (Remote Unlock) Use-Case?
This use-case covers the need to urgently or regularly schedule wake and patch computers. These computers are shut down and need to be woken so that the patch can be applied to them. The Wake and Patch (Remote Unlock) use cases are very similar to the Contextual Security use cases. The following questions already answered for Contextual Security also apply to Wake and Patch (Remote Unlock):
  • How does this work?
  • Is this bypassing preboot?
  • If I were a user standing in front of the computer, would I see it automatically boot into Windows?
  • Does Single Sign On (SSO) work in this use case?
  • What happens if ePO is busy and cannot respond to the system?
  • If the system fails to reach ePO on the first attempt, will it try again?
  • How does an administrator enable this functionality?
  • Can this functionality be set permanently or just for a specific time period?
  • Does authentication actually occur on the client and the necessary information comes from ePO?
Additional Wake and Patch (Remote Unlock) general facts:
  • When the ePO server is busy and does not respond after a wake on LAN request, the client system will stay in preboot and try again every five minutes. This is true for CILA (Local) requests. But, for CIRA (Remote) requests, the computer will only reach out to ePO once. If it does not receive a response, the system will need to be rebooted for it to contact the ePO server.
    To reach a system periodically, it needs to be configured to send CIRA messages periodically using the Alarm Clock. The Alarm Clock feature switches the system on at a certain time as specified.
Additional Wake and Patch (Remote Unlock) Administrator role facts:
  • An administrator can see how many systems made it into Windows for the patch process. This can be seen via the 'DE: Product Client Event' Query with an appropriate filter. This depends on the systems having communicated with the ePO server to send the audit information.
  • An administrator will not be able to determine which systems did not make it past preboot when using the Wake and Patch feature. This is because if the system does not boot into Windows, there will not be an entry in the 'DE: Product Client Event' Query.
  • For an administrator to stagger the Wake and Patch (Remote Unlock) or the interval where they will reach out to ePO, an administrator will need to stagger the Deep Command Power on Command, or their equivalent Wake on LAN request. Systems are powered on when remediated in the SILA (local) environment (when the action is server-initiated). In other cases, the client will contact ePO; therefore, it can be assumed to be on because it contacted the ePO server.
Back to Contents

What is the Remote Remediation Use Case?
This use case offers administrators the ability to perform an Emergency Boot, or replace the DE MBR on a client system via AMT without needing to physically touch the computer. This enables an administrator to fix an issue on a client system that is half a world away.
  • Example Use case 1:
    Administrator is in Santa Clara and he is trying to run an emergency boot on an end user who is currently in Japan and needs a recovery urgently before an important meeting.
    Using this process requires no end user intervention. They can simply watch you repair their client system. For CILA (Local), this is correct. For CIRA (Remote), it will initially fail, but after the system connects via CIRA it will be acted upon.
    NOTE: The time taken for how long the Remote Remediation takes in the above example is largely dependent on the network speed and how long it takes to get the image down to the client system. When it has booted onto the image, it will take the same amount of time as the Emergency Boot takes today if you have done it manually. It actually follows the same process, but in an automated fashion.

  • Example Use case 2:
    The Remote Remediation process was successful and the user has gained access to Windows. The user can give their presentation, but does not have a connection to the corporate ePO server.
    In this scenario the user will need to go through the same process again when they restart their client. This will be the case if the preboot was damaged, then the client would have been emergency booted. This cannot be repaired until the client can successfully communicate with the ePO server.

How does Remote Remediation work?
At a high level, a small disk image (1.44 MB in size, but only 300k of it is used) is pushed down via AMT to the client system. When it is received on the client, it will be restarted and boots using boot network from IDE-R. That image will then perform the necessary remediation actions and start the process to boot Windows. Additional Remote Remediation general facts:
  • Remote remediation will only work on computers with a BIOS boot process.
  • Remote Remediation functionality does not work in a UEFI environment. IDE Redirection does not work in UEFI and this functionality is required for remote remediation.
  • The possible actions for Remote Remediation are:
    • The first is to perform an emergency boot
    • The second is to replace the MBR.
Additional Remote Remediation Administrator role facts:
  • To use Remote Remediation functionality, an administrator selects one or more systems, then selects the 'Out of Band – Remediation' as the action and finally specifies either 'Emergency Boot' or 'Restore Endpoint Encryption MBR' before clicking OK.
  • For an administrator to get notifications of the progress of the Remote Remediation, the administrator is only informed that it has started and when it has finished. Upon completion, the administrator is told whether it was successful. The audit is on the client and is only sent back to ePO on the next Agent to Server Communication (ASCI). The administrator can run a query on the client events to find the clients with an UNLOCK event.
  • An administrator would want to replace the MBR if a third-party product accidentally overwrote the MBR while the system was encrypted. Or, if the system were infected with an MBR virus, you would need to get the system back into Windows so any other remediation could then take place.
  • When selecting a remediation, an Administrator can select a specific disk image. There are different images for BIOS boot and Opal and non-Opal remediation.
    Automatic is the default option and the one you must use all the time unless directed otherwise. The automatic option uses the information received from the client to select the correct image. If this information is not available, it does not perform the remediation. What this option allows you to do is specify the exact image that is sent down to the computer.

    IMPORTANT: If the administrator selects the wrong disk image for the client (when the image is selected manually), the User Interface (UI) indicates that you could potentially damage the disk by using the wrong image. This option was added for the event when the Encryption provider or BIOS type is not available.
Additional Remote Remediation user experience facts:
  • Notification of the progress of the Remote Remediation to the end user. A message is displayed on the screen when the image has downloaded and the remediation process starts. For the download of the image to the client via AMT, in some instances you can see a blinking glyph in the top right corner of the screen. This light is an indication that AMT is receiving network traffic. Again, the duration is largely dependent on network traffic and speed. If the network is fast, the end user might see Windows suddenly load.
  • When a Remote Remediation is performed, a user might not see the blinking glyph. That functionality is only included in AMT version 7, so if you have AMT version 6, you do not see it.
  • When a user performs a Remote Remediation and runs out of time and must leave their current location (disconnect from the network), they do not need to start the whole process again. The reason is because the process starts again automatically. When the administrator has added the request for remote remediation, it sits in the action queue until it has been completed or deleted by the administrator. The result is that it tries to perform the remediation each time you switch on the client until it is successful.

How is Remote Remediation initiated on the client when it is local?
Here is an overview of the process when the client system is connected to local enterprise network:
  1. The user boots the system and finds that it is not working.
  2. The user calls the administrator and asks for help.
  3. The administrator selects the appropriate remediation action and the action starts processing immediately. This action can also be referred to as SILA (Server Initiated Local Access).
  4. If the client system is found and can be connected to, Redirection starts and repairs the system automatically.
    But, if the client system cannot be found in the local network, the action fails and the status remains as pending in the queue. This situation can then only be processed when the system calls in. In this situation, the system cannot call because preboot is broken, and so a similar flow as described in the next scenario below could also be used.

How is Remote Remediation initiated on the client when it is remote?
Here is an overview of the process when the system is connected through a public network:
  1. The user boots the system and finds that it is not working.
  2. The user calls the administrator and asks for help
  3. The administrator selects the appropriate remediation action and the action starts processing immediately. In this situation, the action fails because it cannot find the system in the enterprise network.
  4. The administrator asks the user to initiate a 'Call for Help' from the BIOS. This call varies from one OEM to another, but it tends to be under boot options and in some systems you could simply press CTRL+ALT+F1.
  5. When this is selected, the system connects to Stunner (Deep Command Gateway Services) and the Agent handler detects this and sends a message to Deep Command.
  6. Deep Command processes the action associated with the system. In this case, it is the remediation action.
NOTE: Remediation over CIRA can take considerably longer than when performing the same action inside the enterprise. On some systems, it could potentially take up to 20 minutes depending on network usage during processing. Back to Contents

What reports can an administrator use to know that the AMT action has completed successfully on the client?
DE only has one server-side action, which is for remediation. To determine if it completed, an administrator must look at the ePO Server Task Log by running a query on the event audit log to see the client events. All other actions (Unlock/Reset, User password) are client-initiated. When the administrator configures these actions, there is an entry in the ePO User Audit log to record that the request has been added to the 'DE: Out‑of‑band action queue'. Then when the client PBA requests help, it creates an audit item on the client. This audit item is sent to ePO on the next ASCI when Windows is loaded. These events appear in the 'DE: Product Client Events' query.

What reports or logs can an administrator view to determine what and where things went wrong and failed to complete the action successfully?
The administrator must look at the AMTService.log and the DE: Product Client Events query.

Where can an administrator see that one (or more) of the AMT actions has been successfully completed on a client (or multiple clients)?
Run the DE: Product Client Event query.

Can an administrator create reports on the AMT actions, for example, to show how many systems have automatically booted today using the Remote Unlock functionality?
Run 'DE: Product Client Events' query with an appropriate filter. This query relies on the systems having successfully communicated with the ePO server to send the audit information.

What troubleshooting can an administrator undertake for an AMT Out-of-Band issue? What are the first steps they must perform?
The administrator must establish whether the issue stems from a CILA (local) task or a CIRA (remote) task.

In the case where a CIRA (remote) task was performed, what does the administrator do now?
Ask the administrator to boot the client system and access the BIOS, or boot to Windows and use the Intel Management and Security Status to request help. Ask them to check the 'AMTService.log' to see if a request has been received. If it has, the support call will involve DE Technical Support. If not, it will involve Deep Command Technical Support.

What if the AMT Out-of-Band issue stemmed from a CILA (local) task?
Ask the administrator to use the Deep Command action to boot the client into the BIOS. If successful, the support call will involve DE Technical Support. If not, it will involve Deep Command Technical Support.

Back to Contents

Rate this document

Glossary of Technical Terms

 Highlight Glossary Terms

Please take a moment to browse our Glossary of Technical Terms.