This article details the best practices to use prior to performing Symantec Drive Encryption 10.5.0 and above as well as Symantec Endpoint Encryption 11.3.1 and above.
The following best practices are recommended for preparing to encrypt your disk with Symantec Encryption Products. Please follow the recommendations below to protect your data during and after encryption. Before you encrypt your disk, there are a few tasks you must perform to ensure successful initial encryption of the disk.
Security Best Practices
Security is always top priority for Symantec, and Symantec Encryption is a critical component that adds to the overall security of the enterprise. In addition to an aggressive patching strategy and a layered approach to network defense, Symantec recommends using security products, such as Symantec Endpoint Protection (SEP) to lower the attack surface of unprivileged malware in general within the enterprise. Additionally, Symantec recommends the following measures to reduce risk of attack:
• Restrict access to administrative or management systems to authorized privileged users.
• Restrict remote access to trusted/authorized systems only.
• Keep all operating systems and applications current with vendor patches.
• Deploy network-based and host-based intrusion detection systems to monitor network traffic for signs of anomalous or suspicious activity. This may aid in the detection of attacks or malicious activity related to the exploitation of latent vulnerabilities.
Secure Boot: Enabling Secure boot on UEFI systems is recommended. Secure Boot is a security feature within Windows that will validate signed drivers. Disabling Secure Boot may be needed in order to perform testing with unsigned software, but once testing has been performed, re-enabling Secure Boot is recommended.
Important Note: Having Secure Boot enabled is not a substitute for endpoint security software such as Symantec Endpoint Protection, which provides a deep line of defense on systems. Encryption is another line of defense for data at rest as well as data in motion and should be used for systems and data containing sensitive information.
Symantec Encryption Development follows best practices in all Development Life Cycles. See the following article for more information on this topic:
Note on Windows 7 End of Life
All Encryption products are no longer supported on Windows 7 as part of Microsoft's End-of-Life date being reached as January 14, 2020. This announcement has been previously published via article 174001. Any fixes/updates targeted for future versions of Encryption products will be tested and certified on Windows 10. Symantec Enterprise Division strongly recommends upgrading to Windows 10 as soon as possible.
Although no longer supported, Symantec Endpoint Encryption 11.3.0 MP1 and Symantec Encryption Desktop 10.4.2 MP4 are the last versions that will install on Windows 7. Any subsequent release of Symantec Encryption products are not expected to install properly and will require Windows 10 to take advantage of any future updates.
To ensure all your security software has allowed the Symantec Endpoint Encryption (SEE) or Symantec Encryption Desktop (PGP) services, see our "exclusion/safelist/allowed listing" in the following article:
200696 - Symantec Encryption Services - Add Symantec Encryption programs to safe list or exclusions in security software
This is an important step in the deployment of Encryption software to allow full operation to occur successfully.
Symantec Encryption Management Server (SEMS) has many capabilities, including Symantec Web Email Protection (Secure Email Delivery), SED Client management\enrollment, Key Management, and much more. Depending on how busy the SEMS database is, only 8GBs may be needed as a minimum requirement. For larger databases (where the backups are 30GBs or more), it may be good to allocate 24-32GBs of memory to the server. The reason for this is SEMS 10.5 has the ability to allocate memory to the database where it needs it most and this will help speed up all processes and will have better overall improvement. SEMS 3.4.2 had the ability to assign 16GBs or lower, so if you have a large database, it is recommended to upgrade to SEMS 10.5 as soon as you can.
See also 150915 - Symantec Encryption Management Server Benefits and Considerations for upgrading
For Virtual Machine recommendations, see the following article:
Is it required to decrypt drives before upgrading Windows, such as Win10 1909 to Win11 22H2?
No, it is not necessary to decrypt the drives first. Not only is it okay to leave the drives encrypted, we have a process driver that will help the upgrade go through seamlessly during a "Live Update".
For deployments of Windows Updates, see the following articles for PGP or SEE:
179265 - How to automatically upgrade Windows 10/11 systems encrypted with Symantec Endpoint Encryption 11.x (SEE)
Symantec Endpoint Encryption and Symantec Drive Encryption secures your desktop or laptop disks (either partitions, or the entire disk), external disks, and USB flash disks. CD-RW/DVD-RWs are not supported using Drive Encryption.
3.1: Supported Disk Types
Note: Although not officially tested, Hybrid drives, which have a spinning disk component and a SSD cache component are known to work. Encrypting these drives has not shown any negative results as they operate very similar to any other supported disk types:
TIP: If a drive is being repurposed that has previously been used for testing, or previously had an operating system installed on it, and has been reformatted, ensure all the partitions have been completely removed using a cleanup tool, such as DBAN or Diskpart. Remnant partitions left on drives, especially if the drive was previously encrypted can cause issues when being repurposed for encryption.
Note: If you have a system encrypted with Bitlocker, Symantec Endpoint Encryption will not automatically encrypt these systems. Bitlocker encryption must first be decrypted in order for Symantec Endpoint Encryption to start encryption. If you are finding some systems are not encrypted, you can use the "Server Commands" to encrypt systems from the server side. If you are running systems with Bitlocker encryption, if you use the Server commands, make sure the endpoint is on SEE 11.3.1 MP1 as there were some cases where Bitlocker systems were also encrypted with Symantec Endpoint Encryption. This issue is resolved in the latest versions of our software.
3.2: Systems with Two ore more drives or two or more Internal "Fixed" drives:
If you have a system that has multiple drives, Symantec Endpoint Encryption will automatically encrypt all of those drives as long as policy has allowed it. If there are multiple drives configured as fixed drives, only one drive should be designated as the OS/Boot drive. The other drive should not have any system partitions on them at all, which could case the initial encryption to not start.
3.3: Opal Drives:
Symantec Endpoint Encryption 11 supports Opal Drive management. For more information on Opal drives, see article TECH226779.
Symantec Drive Encryption 10 (PGP Products) will support Opal drive as long as the self-encrypting hardware encryption is not used. Symantec Drive Encryptions' native encryption can then be used to encrypt these drives.
3.4: Unsupported Disk Types
3.5: Warning on Basic-to-Dynamic Disk Conversion: Never perform a conversion from a Basic disk format to a Dynamic disk on the boot drive of a system that has already been protected using Symantec Endpoint Encryption or Symantec Drive Encryption. This conversion, from a basic-type disk to a dynamic one will render the drive unusable.
3.6: VMware Virtual Machines: If you are testing with virtual machines and you find the fixed disks for the systems are not showing up as such, you may need to add the following to your .vmx configuration file:
ahci.port.hotplug.enabled = "FALSE"
devices.hotPlug = "FALSE"
If the above are not added, SEE may not automatically encrypt because it can't detect a proper drive. Other unusual behavior may occur.
The EFI partition is modified when a system is encrypted. It requires 40MBs of free space, which is typically not a problem for most default systems. If provisioning systems uses up a portion of the EFI partition, ensure there is enough space to then encrypt the machine. Operations such as flashing/upgrading the BIOS before encryption will use up some of this free space because a backup of the BIOS is commonly made inside of the EFI partition, which will reduce the free space. Although the default 200MB + is typically enough, making this partition 500MBs will ensure this partition will always have enough space. A symptom of this being an issue is the system does not auto-encrypt and even manually encrypting will not start the encryption.
See the System requirements articles for full details:
Symantec Encryption Desktop (PGP Desktop) System Requirements, Release Notes, User Guides
Symantec Endpoint Encryption (SEE) System Requirements, Release Notes, User Guides
In Windows, there is a Power Management setting called "Fast Startup":
This setting can affect how a system boots and could cause some unexpected behavior, such as keyboards not working properly at preboot, SSO not automatically logging in to Windows or other potential scenarios.
Disable this setting (uncheck) for best performance with Symantec Drive Encryption (Both SEE and PGP).
Check also the BIOS for any Fastboot/Quickstart/Quickboot settings. Fast/Quick Boot/startup does not allow all peripherals to be loaded during the boot process and can sometimes prevent external keyboards from working. It could also cause login failures, especially if USB 3.0 ports are being used. Fast startup does not offer a noticeable increase in speed during the boot process and so disabling these will not cause any performance issues in most cases. It may be necessary to disable both of these settings for benefits to be observed.
Note: Different BIOS vendors, such as Lenovo, Dell, or HP will call these boot settings differently. For Dells as an example, disabling Fast Boot is sometimes called "Thorough".
Before you encrypt your disk, be sure to backup the data so that no data will be lost if your laptop or computer is lost, stolen, or you are unable to decrypt the disk. Also be sure to make regular backups of your disk.
If Symantec Drive Encryption or Symantec Endpoint Encryption encounters a hard drive or partition with bad sectors, the encryption process will pause. This pause allows you to remedy the problem before continuing with the encryption process, thus avoiding potential disk corruption and lost data.
In Symantec Encryption Management Server or Symantec Endpoint Encryption Management Server managed environments, if a hard drive or partition with bad sectors is encountered, an event is added in the server logs.
Note: If a bad sector appears on any disk, it is best to replace the disk for best reliability as bad sectors can be a sign of other issues with the drive itself.
Be sure that you are using a keyboard with one of the supported languages.
For a list of the supported languages, see the following links for your operating system:
While the chances are extremely low that a master boot record could become corrupt on a boot disk or partition protected by Symantec Drive Encryption or Symantec Endpoint Encryption, it is possible. Before you encrypt a boot disk or partition using Drive Encryption, create a recovery disk.
See the following articles for Recovery using WinPE:
163334 - Legacy Symantec Drive Encryption 10.4 Recovery ISOs (this does not work for PGP Desktop 10.5 and above)
Because encryption is a CPU-intensive process, encryption cannot begin on a laptop computer that is running on battery power.
Do not remove the power cord from the system before the encryption process is over. If loss of power during encryption is a possibility or if you do not have an uninterruptible power supply for your computer consider choosing the Power Failure Safety option.
Almost all laptops are configured to use the Power Save or Balanced modes of Power Management. This can cause the CPU and Hard Disk to throttle back as well as hibernate to conserve energy. The problem with this is that it can either extend or interrupt the Whole Disk Encryption process making it progress much more slowly.
To ensure maximum speed for encryption we recommend changing the Power Management profile to be Performance or Always On for the duration of the encryption process.
Please consult your Laptop Manufacturers Documentation or the Help section of your Operating System for steps on modifying these settings.
As a good security practice, it is recommended to test Symantec Drive Encryption on a small group of computers to ensure that are not any conflicts with any software on the computer before rolling it out to a large number of computers. This is particularly useful in environments that use a standardized Corporate Operating Environment (COE) image.
The following software is not compatible with Symantec Drive Encryption:
Where possible, as a best practice, if you need to perform any disk recovery activities on a disk protected with Drive Encryption, it is recommended that you first decrypt the disk. Once the disk is decrypted, proceed with your recovery activities.
An example of this is a system is experiencing an issue with the operating system. It would be recommended to decrypt the disk first, and then perform any recovery, such as Windows recovery on the disk. Attempting to do a Windows repair on an encrypted disk could result in further issues.
Important tip: For highly critical disks it is always recommended to take a bit-for-bit (sector-by-sector clone) backup of the disk and then perform the decryption\recovery on the copy of the disk. This is because if something fails during the recovery process, you can always take another clone of the drive and try recovery steps again.
For data recovery solutions by a professional data recovery vendor, we recommend Kroll Ontrack who is familiar with the encryption process. Let them know Symantec/Broadcom Encryption referred you to them.
In order to perform an in-place upgrade, please consult the following articles to successfully upgrade:
HOWTO125875 - Upgrading Encrypted Computers to the Windows 10 Creators Update from Earlier Versions of Windows with Symantec Endpoint Encryption 11.1.2 and later
Note: Symantec Endpoint Encryption 11.2.1 MP1 included a new feature that allows automatic major Windows 10 updates (for example, Windows 10 1803 to 1809) without using custom upgrade scripts. In order to take advantage of this functionality, install the SEE client with the following command:
msiexec /i "SEE Client_x64.msi" WINSETUPAUTOMATION=1
For more information and options, see article HOWTO128509.
HOWTO125876 - Upgrading Encrypted Computers to the Windows 10 Creators Update from Earlier Versions of Windows with Symantec Encryption Desktop 10.4.1 MP1 and later
For Standalone or smaller environments:
HOWTO128509 Howto: Upgrade Standalone Windows 10 systems encrypted with Symantec Endpoint Encryption 11
HOWTO128505 Howto: Upgrade Standalone Windows 10 systems encrypted with Symantec Encryption Desktop 10.4.2
TIP: Always make sure no systems are pending a reboot when performing Windows updates. Rebooting allows previous Windows updates to be in effect as well as provide better stability for future Windows updates or SEE installs/upgrades.
The following information will help if performance degradation is observed after encrypting a Solid State Drive
155848 - SSD Performance issues with certain drives using Symantec Endpoint Encryption 11 or Symantec Encryption Desktop 10
For general information on how Symantec Endpoint Encryption should be installed, see the following article:
It is recommended to install Endpoint Encryption with verbose MSI options enabled as this information is useful in diagnosing many scenarios in troubleshooting.
To install Endpoint Encryption, run the following command with proper administrative permissions from the command line:
msiexec /i "SEE installation.MSI" /l*vx c:\path-of-log-file.txt
For instances where troubleshooting will require SEE client debugging, the following command will install the Endpoint Encryption client and automatically enable debug logging in the client. This is not always necessary, but is useful when it is required to also capture the SEE client debug logs:
msiexec /i "SEE installation.MSI" /l*vx c:\path-of-log-file.txt MALOGLEVEL=DEBUG
By default, SEE 11.3.0 and above will store the msiexec installation log in %tmp% unless you use the install path listed above.
For more information on debug parameters, see the following article:
It is also recommended that systems be rebooted just prior to the install/upgrade of Symantec Endpoint Encryption 11 to ensure the best success as pending reboots can cause the install/upgrade process to fail.
Symantec Endpoint Encryption includes a reboot-detection feature so if a pending reboot status is encountered, the SEE installation will halt.
It is a good idea to reboot a system to clear out this pending state for best success during an upgrade.
There is a method to disable this feature so that even if pending reboots are detected, the SEE install will continue. For more information on this, see the following article:
214719 - Symantec Endpoint Encryption Pending Reboot Feature
PRE_INSTALL_REBOOT_CHECK=YES Option is for SEE 11 only. This option does not work for Symantec Encryption Desktop 10.
Failing to reboot can cause some unexpected behavior, such as when Symantec Endpoint Encryption 11 has been installed, and then postponed, and later, another update, such as Windows is installed. Other scenarios exist which may put the install/upgrade at risk. For best success, it is recommended to reboot after install/upgrade.
TIP: Symantec has a pending reboot script that can be used to detect the reason for failed installs. For more information on this, see article 200298.
Although some deployments may opt to not immediately reboot, it is advised to reboot the system very soon after Symantec Drive Encryption has been installed or upgraded on a system.
Failing to reboot can cause some unexpected behavior, such as when Symantec Encryption Desktop 10 has been installed, and then postponed, and later, another update, such as Windows Updates are installed.
Other scenarios exist which may put the install/upgrade at risk. For best success, it is recommended to reboot after install/upgrade.
When changes are made to the preboot file system for Encryption products, two reboots may be needed.
Symantec Endpoint Encryption 11.x and Symantec Drive Encryption 10.x operate differently when it comes to slaving drives.
Symantec Drive Encryption (SED - PGP products) is able to accept encrypted boot drives on other systems with Symantec Drive Encryption installed an "enclosed" and be able to authenticate the drive. As an example, a boot drive encrypted with SED could be removed from the machine, and connected to another machine with SED installed, and can be prompted to enter the passphrase. The reason this works is Symantec Encryption Desktop is also able to encrypt external USB drives with its Drive Encryption component, and has actual code logic to detect these conditions. Slaving encrypted boot drives as an external USB drive is fully supported, and is a nice way to copy data from a drive that may not be otherwise booting.
Symantec Endpoint Encryption (SEE) operates differently, and does not support encrypting external USB drives with the Drive Encryption piece. Because this is not part of the code logic design, a drive that was encrypted with Symantec Endpoint Encryption and connected via enclosure to another machine with Symantec Endpoint Encryption Drive Encryption will not prompt for authentication. Using the eedadmincli.exe utility to authenticate the drive will work in most cases.
When it is necessary to decrypt the Primary/Boot drive and the other secondary drives are also encrypted, it is recommended to first decrypt the secondary disks, and then decrypt the primary/boot disk last. For example, if a system has 3 disks, the Primary/Boot disk will typically be labeled Disk 0, the next disk in line would be Disk 1, and the third disk would be labeled Disk 2. In this scenario, you would decrypt Disk 2 first, then Disk 1, and then Disk 0 last.
In configurations where an NVMe disk is being used, and the secondary disks are SSDs, the boot disk may be labeled as Disk 1, and the secondary disk may be labeled as Disk 0--take this into consideration when decrypting. In this scenario, Disk 0 (secondary disk) is decrypted first, then Disk 1 (Primary/Boot) is decrypted last.
SED is enrolled on a per-user basis so if there are users logging into non-persistent systems, their user profile may not be getting saved with the PGP policy files.
To ensure this is happening, see article 157763 to ensure the user's profile retains ownership of key program files so users are not prompted to re-enroll each time they login to their non-persistent/roaming profile.