Removed the following historical topics due to deprecation of the features or underlying technologies:
Cold-boot hardening, AOAC, Elevated Security
Intel AMT
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.
NOTES:
To review the FAQs for Endpoint Assistant (EA), see KB85917 - FAQs for Endpoint Assistant 2.x. 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.
The following historical topics have been removed due to deprecation of the features or underlying technologies:
Cold-boot hardening, AOAC, Elevated Security
Intel AMT
Contents
Click to expand the section you want to view:
What's 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?
The key purpose of DE is to protect the disk at rest, when the disk is unlocked. But, DE provides no data access protection. So, if you want a secure system, don't use the Autoboot feature. 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 or ReflectDrivers for in-place upgrade?
Yes. Microsoft has included a new feature in the Windows 10 Anniversary Update that allows for an operating system in-place upgrade through ISO and SCCM using a /Reflectdriversoption.
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.
Do you support the in-place Unified Extensible Firmware Interface (UEFI) conversion tool (MBR2GPT.EXE) with Windows 10 Creators Update and later?
Yes. A DE Master Boot Record (MBR) to GUID Partition Table (GPT) tool (MdeMbr2GptTool.exe) has been developed, which works on Microsoft Windows 10 (version 1703) Creators Update and later (64-bit only). The tool works with the Microsoft tool (MBR2GPT.EXE). The tool converts a software-encrypted DE drive from MBR to the GPT partition. It does so without the need to decrypt the disk.To get the DE tool and instructions, see KB89024 - How to convert an encrypted disk from MBR to GPT using Microsoft MBR2GPT.EXE and Drive Encryption MdeMbr2GptTool.exe tools.
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 (operating system) refresh from Windows 8
LTSC and LTSB are Microsoft terminology for a Sustaining build. These builds don't receive feature updates and would be limited to security updates in general.
Is a Windows operating system with DE installed on Mac hardware supported?
No. DE hasn't 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 uses a functionality that lays down a new WIM image. It's essentially an operating system Refresh Process and not a traditional upgrade or Service Pack upgrade. But, DE has a documented operating system Refresh Process that allows you to upgrade from Windows 8.0 to Windows 8.1. The process allows you to keep the existing data encrypted throughout the entire process. For assistance with this process, see the following Process Guides:
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 ask whether you want 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 - How to disable Windows Automatic Repair via a logon script for systems that have Drive Encryption installed.
Why must I use the DE 7.1 operating system Refresh Process when I don't 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. We don't adopt this approach because it leaves the system vulnerable to attack during the Windows upgrade process.
Microsoft has talked about a new feature calledDE. What is it?
Microsoft DE can be considered a scaled-down, non-managed version of BitLocker.
Additional DE information:
Microsoft DE is automatically enabled. It's enabled only when the hardware matches or exceeds its minimum hardware requirements.
The following happens if you deploy DE to a system that has 'Microsoft Device Encryption' automatically enabled:
Pre-activation checks determine that BitLocker is active. Remember that Microsoft DE is simply a non-managed version of BitLocker.
DE activation fails because the disk is already encrypted with Microsoft DE.
This status is reported back to ePO.
The above applies if both the following apply:
The option 'the system meets the minimum hardware requirements' is automatically enabled.
The hard-disk is encrypted.
IMPORTANT: The following apply if you have a new system that meets the Microsoft DE minimum hardware requirements, but have Windows 7 and DE 7.1 installed, and then decide to upgrade to Windows 8.1:
If you've not logged on with an MSDN account, the system doesn't try to enable Microsoft DE.
If you've logged on with an MSDN account, it breaks the operating system.
Does DE support Windows compressed drives?
No, Windows compressed drives aren't supported because no compatibility testing is undertaken.
Does DE work with the new Dell Cylance Advanced Threat Protection Technology, which can report if a Boot attack is detected?
No. DE isn't tested with Dell Cylance Advanced Threat Protection.
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 doesn't have a drive letter.
IRS provides a low-power S3 state. Here, instead of storing the 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 can't 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 isn't 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 stops the activation of DE if BitLocker is active.
Is Active Directory (AD) needed for a DE 7.1 installation?
No. You can install the installation (MSI) packages without access to AD because of the new User Directory feature included in DE 7.1. See the "Functionality" section for details.
Additional AD information:
AD is required to manage DE 7.1 clients via ePO.
Although AD 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 doesn't manage can remain encrypted without the need to be connected to AD.
Assigned users aren't deleted from the ePO database if the object name such as a Group or User is changed in AD. The object name change is detected on the next run of the 'LdapSync: Sync Across Users from LDAP' task and updated in ePO. During the following Agent to Server Communication (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 isn't yet installed, it can't 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 isn't 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 the latest DETech guide.
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:
Make sure that there are no LDAP Sync tasks running. If any are running, wait for them to complete.
Disable all LDAP Sync tasks before initiating the upgrade.
Install the DE 7.1.3 extensions.
Check in the DE 7.1.3 Agent and PC software packages.
Re-enable all LDAP Sync tasks.
Deploy the DE 7.1.3 software packages to the client system.
Restart the client system after the deployment task is complete.
I'm setting up a new ePO server and want to move DE clients across to it. Is this action supported?
Yes. This scenario is supported.
NOTES:
DE has a client transfer capability. The capability provides the ePO Administrator with a mechanism to allow systems to be transferred from one ePO server to another. The transfer occurs while preserving user assignments and user data. If the feature is enabled, a DE system detects a server change. It requests that the new DE managing server automatically assigns 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 Client System Transfer Guide is included in the release that describes this system transfer process in detail.
What do I have to consider if I install to a Windows 8.x system using native UEFI?
Recommendations if you plan to install DE 7.x on a Windows 8.x system, using native UEFI: We recommend that you only use the native UEFI mode if the system is explicitly Windows 8 certified. We also recommend that you upgrade your UEFI systems to the latest UEFI firmware level. Then, test on a specific native UEFI-capable system before wide-scale deployment.
NOTE: For other UEFI questions and answers, see the "Functionality" section below. 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 - How to migrate Drive Encryption Users from one domain to another.
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. Instead, force users to be prompted to enter a password that they choose.
Use a policy assignment rule with a different 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 isn't supported. It would introduce a security problem because every system would have the same security key.
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 FAQs applicable to DE 7.2.0 and later
How does DE 7.2.x use Intel Software Guard Extension (SGX)?
Intel SGX is an Intel Architecture extension, introduced with 6th Generation Intel Core processor platforms, that's 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 a suitable policy applied.
Can I repartition a disk that's encrypted with DE?
No. It's not possible to change the partitioning of a disk that's already encrypted. You need to fully decrypt the disk and uninstall DE before performing the repartitioning of the disk.
What's the key length used by the encryption algorithm AES256?
The key length used is 256 bits.
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 DETech to work properly in environments where pure hardware RAID is implemented. This expectation covers systems that have internal RAID cards or external RAID systems with a built-in controller.
NOTE: DE or DETechcan't support diagnostic or disaster recovery for a broken RAID configurationwhen hardware RAID is in use.
DE or DETech doesn't 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 or DETech works in RAID mode as long as the BIOS SATA mode of that computer can see the disk.
NOTES:
In Legacy or MBR BIOS mode, DE relies on Int13 calls to access the hard-disk (HDD) of the computer.
In UEFI mode, DE relies on the system input or 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 Drive (SED) HDD. DE must be set to the Advanced Host Controller Interface (AHCI) mode. The reason is because DE has its own controller driver and doesn't 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 it possible to encrypt a removable media storage device connected through a USB port?
No. DE detects and encrypts the drive only if it's detected through a SATA port.
What's 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 AD, DE can now also use these ePO-managed users for preboot authentication.
User data is now synchronized from AD and cached locally in ePO. This fact eliminates the need for constant round trips from ePO to AD. It results in significant performance improvements for user-based policy checks.
Additional general User Directory information:
User Directory removes the dependency on AD.
An Administrator must install the User Directory extension. You can do this install before or after you've 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 can't 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.
Regardingscripting, does the ePO WebAPI change for User: Machine assignments?
No.
What is Trusted Platform Module (TPM) autoboot?
TPM autoboot is a new offering in DE 7.1. It strengthens the traditional autoboot functions 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 takes measures, which can't be bypassed. 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 information:
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's no longer in plaintext.
TPM helps secure the key because the TPM can decrypt the key only if the system state hasn't changed. The key isn't decrypted if either of the below is true:
The TPM believes that the system state has changed.
A new TPM chip is present (new motherboard).
If it can't decrypt the key, the autoboot function 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 doesn't see the preboot environment and it simply boots into Windows.
TPM autoboot can be used with reactive autoboot.
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 or 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 hasn't been changed.
This fact means that after TPM autoboot unlocks the disk, it's not possible to boot to another boot path. If a different boot option is selected on startup, the autoboot function fails and the preboot is displayed.
Additional TPM Administrator role information:
The policy settings for TPM autoboot are under the title "User TPM for automatic booting" and has the following three options:
Never - The 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 if it's unusable, the TPM present on the system has the key written in plaintext to the disk. This action is 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 don't have a TPM.
IMPORTANT: If Microsoft updates the Windows bootLoader during a Windows update, the boot measurements have changed. As a result, TPM can't decrypt the key and you must go through a recovery process. The recovery process 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, hotfix, update, or new version, it updates both the following:
DE preboot EFI Application
Boot measurements
Similar to the Windows update scenario, users must make a Help Desk call to access their system after DE pushes an update.
The minimum requirements for TPM autoboot are as follows:
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 don't 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 AD.
The system must include the TPM UEFI protocol in the OEM's UEFI implementation (a requirement for Connected Standby systems).
Additional TPM user experience information:
When TPM can't decrypt the key, it displays the preboot environment and asks the user to authenticate. If TPM is in any doubt, it doesn't automatically boot the system, and instead displays the preboot environment and waits for authentication.
Can I now handle a larger number ofusers in preboot?
The preboot environment is now 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 enable any user to use any system.
What's 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 information:
DE 7.1 and later increase the number of users that preboot can support, although it's recommended to minimize the number of users assigned per node. The numbers have increased to thousands, rather than hundreds.
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. This can 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 system 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 ASCI to make sure that all information is up to date. Example:
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 several 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's multiplied by the number of transactions. If a system has a slow link, it can take a considerable amount of time to receive all changes. If the server handles user updates for many clients, the network traffic can also be significant. In the worst case, it might not receive all updates in a sync period.
What's a cold boot attack?
A cold boot attack is a way of extracting sensitive data from system memory. It does so 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
Cold-boot hardening doesn’t work with Virtualization-Based Security, which was introduced into Windows 10 RS1. Since this feature can’t be enabled on Windows 10 RS1 or above, it is now deprecated.
Is it possible to clone an existing hard-disk (HDD) to a larger disk, make the new disk bootable, and extend the size under Windows' 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 doesn't have networking functionality.
Why doesWindows 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 as follows:
A UEFI Boot Process
GPT Disk partitioning
Secure Boot
Hybrid Boot
Windows 8 Modern User Interface (UI)
Windows 8 Tablets
What'sAutoboot?
Autoboot is an account that effectively bypasses the protection provided by DE. With this option enabled, the users don't see the preboot authentication screen.
What'sReactive Autoboot?
Reactive autoboot is an enhancement to the traditional autoboot functionality that exists on Windows, and OS X. In autoboot mode, the drive is encrypted. But, the user doesn't see the preboot authentication screen, and boots directly into the operating system.
Unlike traditional autoboot, reactive autoboot has one other piece of functionality. When enabled, the product monitors Windows authentication requests. If a 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 operating system.
This functionality allows the authentication policy to automatically transition from autoboot (unlocked, insecure) to preboot (locked, secure). It's based on certain conditions designated by the Administrator.
Additional Reactive Autoboot information:
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)'.
Specify the number of failed logons or unlocks allowed.
The policy must then be assigned to the systems that require the reactive autoboot functionality.
Example for the use of reactive autoboot: You want to encrypt shared systems, which any user in the organization might need to access. As a result, you can't 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 isn't enabled when autoboot is enabled, the data isn't 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.
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 maximum value of 10.
It applies to all Windows authentication attempts. It applies to both Windows logons and unlocks 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 number of 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 are 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's under attack, it disables autoboot and restarts the system. There's no time to send an event to ePO, so ePO isn't aware of the lockdown as it's implemented.
No administrator action is required to re-enable reactive autoboot on a system where it's disabled, which can occur on a failed Windows Authentication attempt. After the client restarts the system and accesses Windows, reactive autoboot is re-enabled automatically. The system doesn't need to communicate with ePO to re-enable autoboot.
What's the User experience when the system uses Reactive Autoboot?
When users turn on their computers, they boot directly into Windows. Autoboot means that there's no preboot authentication. Users go directly to the Windows logon. Assuming that they always successfully authenticate to Windows, their experience doesn't change.
The user experiences 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 can't perform the following actions:
Authenticate using Windows credentials
Use Self-Recovery to pass preboot and access Windows
NOTE: If the system has always worked in autoboot mode, it's unlikely that any DE users have been assigned to allow any successful preboot authentication.
To gain access to Windows when presented with preboot authentication, to gain access to Windows, a user must perform either of the following:
Authenticate at the preboot screen.
Go through one of the standard recovery mechanisms.
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'sFast 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 or imaged system. The system sits on a desk of an IT Technician and isn't used by the user. You can see the 'In-House Provisioning' or 'Provisioning by a third party' use cases from the Offline Activation FAQs.
This feature can't be used with an Opal drive. There's no need to use Fast Initial Encryption with an Opal drive because the drive is technically always encrypted. 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 can't use Fast Initial Encryption as part of the normal activation process.
Fast Initial Encryption can be used with a normal HDD or SSD. But it's important to read the considerations about Used Sector Only (see below).
Additional Fast Initial Encryption (Used Sector Only) information:
Fast Initial Encryption removes the power failure protection, which provides protection against data loss in a power-failure or hard-shutdown scenario. It 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 work. Traditionally, the product assumes that it's encrypting a system that's in use. It prioritizes the user experience to minimize impact on the 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 a standard deployment, the encryption process takes longer to complete. The reason is because the DE encrypts every sector of the volumes and partitions. It encrypts any area that's specified in the encryption policy. Even blank sectors that contain no data get 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. As per 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're 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 isn't 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 information:
When Fast Initial Encryption is enabled, the user must type Yes when using Used Sectors Only. This act makes sure that you have read the disclaimer and understand the use of this functionality. It's important to read the considerations about Used Sector Only.
When a user doesn't type 'Yes' when prompted, the offline activation package isn't 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.
The 'Used Sector Only' option means that there are no sectors on the disk that aren't 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're 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're recycling an older drive that's fully encrypted with DE, this functionality can still be used, assuming that all volumes that contain sensitive data are previously encrypted. If this condition isn't met, you're recommended to not use this function.
IMPORTANT: Don't use this functionality on disks that previously contained sensitive company data. Encrypt the entire volume or partition or disk.
Can I restart a computer while the hard-disk is being encrypted?
There are two scenarios to consider:
You can't 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 is restarted.
What's 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 this document.
Can I still perform a normal or offline activation withPower-failure Protection enabled and encrypt all sectors, and not just the ones in use?
Yes. You must explicitly enable Fast Initial Encryption for it to be used. If it's 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's possible to disable this option. It's important to read the considerations about Used Sector Only.
What'sUEFI?
UEFI 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 system 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 information:
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 and more efficient block Input/output between hardware and software. In addition, UEFI allows designs to use the full potential of their hardware.
UEFI allows for a modular firmware design, which enables hardware and system designers greater flexibility in designing firmware for the more demanding modern computing environments. While I/O is 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's a different boot process, a different recovery tool is required to handle the different boot processes.
DETech is also a UEFI application. There's a DETech application that's used for recovery on systems with a UEFI boot process.
NOTE: You can't use the (legacy) BIOS DETech tools with a UEFI booting system.
IMPORTANT: A system with a UEFI boot process doesn't work with MBR partitioned disks. Windows requires a new mechanism for disk partitioning, called GPT, to boot under UEFI.
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 operating system by 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.
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 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 fails to implement either of these mechanisms, support for the touch-screen device can't be guaranteed.
NOTE: We've 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 leaves out sections of the UEFI specification.
GPT drives are supported with UEFI. They're supported as boot or secondary disks.
UEFI implementation occurs across all vendors. UEFI implementations differ by hardware vendors. Depending on the UEFI implementation, issues can range from the following:
Missing protocols required to support Opal drives.
Issues to support USB provided in the preboot environment, and 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 are fitted with an Opal self-encrypting drive when manufactured.
Support for Opal self-encrypting drives under UEFI isn't offered when either of the below is true:
Retrofitting Opal drives to pre-Windows 8 systems
Retrofitting to Windows 8 systems that aren't shipped with Opal drives from the manufacturers.
The reason for the above is because a UEFI security protocol is required for Opal management. It's mandatory only when a self-encrypting drive is fitted at the time of shipping. Without the security protocol, Opal management isn't possible.
Is there support for GPT drives? Windows 7
As a boot disk, no. As a secondary disk, yes. Also, it's up to the operating system to support the secondary drive in GPT mode, and for the BIOS to support large disks for DETech (Standalone) to recover them.
Windows 8 and later
Primary and Secondary GPT disks are supported on Windows 8 with DE 7.1.0 and later.
NOTES:
UEFI-based systems can only boot from a primary GPT disk.
BIOS-based systems can't 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's the User experience when the system is using UEFI?
Both preboot environments look and behave the same. A user can't tell the difference between the UEFI and BIOS preboot environments.
Why must I create and use DETech WinPE recovery media, when the DETech Standalone version includes more functionality, such as making 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 isn't 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's not possible for us to provide customers with a WinPE recovery CD because a valid Microsoft license is needed.
What's 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, which begins in UEFI, which validates the next module in the chain before loading and executing it. The validation makes sure that it hasn't changed since it was digitally signed. With the Secure Boot architecture and its establishment of a chain of trust, the customer is protected from malware 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 information:
DE 7.1.x supports Secure Boot.
DE is signed, so the Secure Boot process trusts it.
Secure Boot doesn't work on Windows 8 or later BIOS-based systems. It works only on UEFI-based systems.
What'sHybrid Boot / Fast Startup / Fast Boot?
In previous versions of Windows, a traditional shutdown closed all user sessions, services, and devices, and also closed the kernel to prepare for a complete shutdown. Windows 8 closes the user sessions, but instead of closing the kernel session, it 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, and Fast Boot information:
DE 7.1.x doesn't support Hybrid Boot, Fast Startup, and Fast Boot. DE features are impacted if they're 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, DEexperiences comparable encrypted or 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, such as the most current applications, doesn't run on Windows RT.
What's a WindowsTablet?
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 information:
DE 7.x does not support Windows Tablets using an ARM processor and Windows RT.
DE 7.x supports Windows Tablets using an Intel processor. These tablets are seen as any other Windows system. But, you must examine the following:
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 don't have AES-NI capabilities. Customers must be aware of CPU capabilities to make sure that the user has an optimal experience when the system is encrypted.
Touch Screen Support on Tablets: Some Windows Tablets have keyboards, so touch-screen support isn't an issue. For the devices that don't have keyboards, these devices require the user to authenticate using the touch interface in preboot.
What'soffline activation?
Offline activation is the ability to activate DE without a connection to ePO.
Additional Offline activation information:
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 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. This is expected behavior. Because the system has never communicated with ePO, there's no information about that system.
If a device is activated only via offline activation, you're not able to prove that it's encrypted. If the system never communicates with ePO, there's no information in ePO that can be used for auditing purposes in case of loss or theft. After the system communicates with ePO and goes into an online mode, all normal information is present in ePO. When the transfer is complete, it proves the encrypted state of the system.
Add Local Domain Users (ALDU) doesn't work via offline activation. ALDU is a two-step process that requires ePO to perform the user or system assignment. Because ePO isn't available with offline activation, ALDU can't complete and can't be used.
To define the initial policyfor offline activation, use the parameters available in the offline package creation utility.
A system discards all offline users after the system successfully communicates with the ePO server.
What are the Use Cases for offline activation?
The three primary use cases addressed by offline activation are as follows:
In-house provisioning.
Provisioning by a third party.
A remote system that never connects 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. The disk must be fully encrypted before it's handed to the 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.
Use case for offline activation for a remote system that never connects to ePO:
You have a client in a remote location.
The client has no network connectivity.
The system might collect sensitive data and needs to be encrypted.
You can distribute a CD with the MSI packages. The packages install MA, DE, and the Offline Activation package.
The MSI packages then run to install, 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 to a file on a disk. It's then the responsibility of the 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 creates the offline package. The result of this decryption process is a standard XML file that can be used with the DE recovery tools.
Additional General Offline activation information:
There's only one recovery option available for an offline activation. This option is a local recovery using the DE recovery tools.
If the administrator disables local recovery, the only choice is to use the DE Recovery tools to correct any issues with the system. It's also possible to connect the system to ePO. At this point, the users and policies are 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 when the following hold true:
Local recovery is disabled.
You've 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're not able to manage them in ePO.
IMPORTANT: There's no standalone, non-managed version of DE for systems that are offline and activated. Offline activation might allow you to create a standalone system that's encrypted as per a specific policy. But, after the first policy enforcement is complete, you can't update the policy or the users. There's 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 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:
MA
Endpoint Encryption Agent
DE
Offline Package created by the Administrator
A system can be activated through offline activation to ePO later from ePO.
When an offline activated system connects to ePO, the following occur:
Assuming that the offline activation is done for provisioning purposes, the system at one-point connects 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 MA and ePO; consider it the same as a normal install. It discards the offline policy that's enforced, and it also discards all offline users. It receives the real policy from ePO, the list of assigned users according to normal activation, and saves its encryption key in ePO. You can view it as a second but automatic activation. IMPORTANT: Remember that all offline information is discarded, if the user isn't 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've stored while in offline mode isn't discarded.
What's anoffline user?
An offline user is one who is used for preboot authentication and that exists only in a specific offline package.
Additional Offline User information:
An offline user is different from a normal user in DE. Offline users exist only in that specific offline package. These users don't exist in AD, and basically don't exist anywhere except in this offline package.
You can't 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 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 can't work because there's no back-end to retrieve the needed information to authenticate the user.
When an administrator disables Local Recovery, offline users are locked out. If there's another user on the system, they can boot the system or connect the system to ePO. But, this alternative requires the system to boot into Windows.
When the offline user has forgotten both their password and local recovery answers, the user is now locked out. If there's another user on the system, they can boot the system or connect the system to ePO. But, this alternative requires the system to boot into Windows.
If there's an offline user called Bob and an AD user called Bob, when Bob goes from offline to online, what happens to the password?
Assuming that AD user Bob has signed into the system at least once, and an ALDU is active on the ePO policy, Bob is assigned to the system after the offline Bob is discarded.
NOTE: From this point onward, the AD user Bob can have two possibilities. If logging on at preboot for the first time, Bob 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 ALDU. These policy settings can't be used in an offline activation.
Additional Offline Policy general information:
You can't 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.
A system discards all offline users after the system successfully communicates with the ePO server. 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 user name
Enable SSO
Enable boot manager
PBFS Size
Opal PBFS Size
Require user changes their password
User name must match Windows logon user name
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 don't use the custom policy settings.
What happens to theencryption keys during offline activation?
When the administrator configures the offline activation package, there's 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's not something the user can choose or manipulate.
Additional Encryption key general information:
After you've received the encrypted key, an administrator can decrypt it and export the information in 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 can't import the key into ePO. 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 can't be saved because of some other fault, the hard disk on the client must be reformatted. The Offline Activation process must then be restarted.
The encryption key isn't written to a plain text file on the disk, and the encryption key is always encrypted. If a third-party application intercepts the key, neither is it useful for them, nor would they have a way to identify which system it belongs to.
The only location where the encryption key for an offline activation can be decrypted is the ePO server that creates the offline package. No other ePO server can decrypt the key.
All offline activations don't have the same encryption key. During the first policy enforcement, the encryption key is generated. This fact makes sure that all offline activations have a different key.
Additional Encryption key use case information:
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. This scenario primarily covers new systems. There's little user data to lose, if any of the following occurs:
A physical defect is found that causes the disk to crash.
You get locked out of the system.
NOTE: You can save the key to a USB drive 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's likely that you don't want the third-party to save the encryption key; so you can specify to not save the key anywhere.
WARNING:If the third-party application copies each encryption key for all systems in your organization, it's considered as a security risk.
Because this scenario primarily covers new systems, there's little user data to lose when any of the following occurs:
A physical defect is found that causes the disk to crash.
You get locked out of the system.
Regarding the encryption keys, where the encryption keys for the system never connect to ePO:
It's likely that you want to save the encryption key to a USB drive or hard disk. This step is optional and is purely at the discretion of the administrator. It's then your responsibility to make sure 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.
What's included in thePreboot File System (PBFS)?
The PBFS contains all the needed information to provide the user with the ability to authenticate. This information includes but isn't limited to the following:
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 information:
If you deploy to a client and increase the size of the PBFS in the policy later, the PBFS size doesn't change on the deployed client. The PBFS size setting gets applied only when the PBFS gets created or re-created during any recovery procedure.
It's possible to create and customize preboot themes in ePO.
You can't 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's 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 via the EE LDAP Sync task in ePO.
NOTE: An uninitialized user is a user that hasn't previously logged on to 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.
In summary, when a user gets assigned to a system, the policies for this system are incremented. During the policy enforcement, an event to request user data is triggered. When ePO returns that event, all users that have been assigned are verified and downloaded to the client.
For an uninitialized user, where there's no token data, the secondary event isn't needed to pull all required user data down, and 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 ALDU, there's a 2.5 ASCI timeout that's triggered. This event occurs when the ALDU request isn't 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 should have dimensions 1024 x 768
The file format should be .PNG
The file size should be about 600 KB
What's PBSC?
PBSC is a functionality in DE that performs several preboot hardware compatibility checks. The checks make sure 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 PBSC general information:
The goal of PBSC is to help with providing a hassle-free deployment of DE full disk encryption, which is achieved by looking for common error conditions in the preboot environment. Without the checks enabled, productivity can be affected where deployment issues might lock users out of the system. PBSC deactivates DE if there's an issue, and allows the system to roll back to Windows-only authentication.
The PBSC functionality isn't enabled by default because it introduces one or more system restarts to the activation process. Some customers accept this situation, while others might not.
When PBSC finds a problem, such as a failure to load the preboot or a problem in handing over to Windows, either 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 have been tried, and unrecoverable problems are encountered, the DE preboot is bypassed. In this situation, 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 PBSC, it activates DE and enforces the encryption policy.
What happens if a system fails the PBSC?
If a system fails the PBSC, it doesn't activate DE. So, DE activation (and encryption, if set in the policy) doesn't continue, and the system "rolls back" to Windows-only authentication.
Additional PBSC failure information:
For a system that's still running through PBSC, the ePO administrator can only see that the system isn't activated, and not encrypted.
They can view the audit log to obtain the progress from the last time the system synchronized with ePO.
The Administrator can see that a system isn't activated, because the failure is audited.
For an administrator to see that a system has failed the PBSC, view the audit log for the system.
If a system fails the PBSC, 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 occurs:
You disable PBSC from the policy.
You delete the registry value: Software\McAfee Full Disk Encryption\MfeEpePc\SafeFailStatus\Status.
NOTE: Also, a workaround is to set up an automatic response in ePO based on the Event ID. In this 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 PBSC modifies the configuration?
This information isn't exposed in DE 7.1. It's transparent to the user and happens automatically.
If the PBSC hasn't made any changes, and the system works out of the box, does it indicate that I can disable that check for deployment purposes?
It's at the discretion of customers whether they want to disable the check. But, variability is common among systems that have the same model number. For example, a user might have gone into the BIOS and changed their USB settings.
Changes to the USB settings might affect integration with that BIOS; so, keeping PBSC adds value here. But, if you use BIOS passwords to keep your users from making such changes, it might be safe to not use PBSC.
