SecureDoc v7.27 Release Notes

View All

New Features and Enhancements


Linux OS support

Supported Linux Versions on Private Clouds (e.g. VMWare vSphere/Microsoft HyperV):
 RHEL 7.2 Kernel 3.10.0-327
 RHEL 7.3 Kernel 3.10.0-514
 CENTOS 7.2 3.10.0-327
 CENTOS 7.3 3.10.0-514
 Ubuntu 14.04.3 Kernel 3.19.0-25-generic
 Ubuntu 16.04/16.04.1 Supported kernels: Kernel 4.4.0-21-generic, Kernel 4.4.0-31- generic/ Kernel 4.4.0-53-generic/ Kernel 4.4.0-59-generic/ Kernel 4.4.0-62-generic/ Kernel 4.4.0-64-generic

Supported Linux on Public Clouds:
 Amazon: RHEL 7.2 Kernel 3.10.0-327, RHEL 7.3 Kernel 3.10.0-514, Ubuntu 16.04 Kernel 4.4.0-64-generic,
 Microsoft Azure: RHEL 7.2 Kernel 3.10.0-327, RHEL 7.3 RHEL 7.3 Kernel 3.10.0-514

Non-supported Linux:
 Any private/public cloud with Ubuntu 16.04.2 Kernel 4.8+, Ubuntu 16.04/16.04.1 Kernel 4.4.0-65+, Ubuntu 14.04.4+
 Microsoft Azure: Ubuntu 16.04 kernel 4.4.0-64-generic, Ubuntu 14.04.4+

Ability to encrypt multiple disks (Volumes) on Linux VM for all supported OS

SecureDoc Linux (SDLinux) now supports the encryption of multiple data Partitions/volumes in addition to the root. Please refer to the 7.27 Quick Deployment Guide, for a full list of supported capabilities of this function as well as installation instructions.

Support Secure-delete Linux VMs (at pre-boot & OS levels)

Linux clients encrypted with SecureDoc can now be Secure-Deleted via console or web command. Secure-Deleting VMs is Final and cannot be recovered. Additional functionality for recovery to be introduced in future releases of SecureDoc.

Support multiple subscription ID from Azure and AWS for importing devices into SES for management

SecureDoc now has the capability to add multiple accounts from public cloud providers in the form of individual profiles.

Emergency disk and/or recovery tool to recover data from a corrupted Linux VM

SecureDoc now has capabilities to recover data back from an Encrypted Linux client that is not bootable. The process requires a second SecureDoc encrypted client available which can mount the drive/volume in question. The mounted drive can them be decrypted with a key file similar to SecureDoc Windows functionality to obtain any data within. Please refer to the quick deployment guide for additional information on the functionality of this feature.
In our current release current stage, SDLinux does not support decryption and Emergency disk. Furthermore, the recovery tool Sergei made only applicable to healthy SD Space cases.


Limitations – Windows


SecureDoc CloudVM does not support moving of parent folders between two different Organizational Units (OU’s) in the Active Directory

If any parent folder is moved from one OU to a different OU, then duplicate OU names are created in the SecureDoc Enterprise Sever (SES).

Recommendation: Users should avoid the movement of parent folders between Organization units, if at all possible.

The deployed installation packages (which contains the profile options) created using the SESWeb cannot be modified

Recommendation: At this stage, if a different profile behavior is required for a given device, the device should be decrypted, SecureDoc should be uninstalled, a new profile/package deployed to the device and the device re-encrypted.

Child Virtual Machines fails at registration if the parent machine is permanently deleted from SES

The cloned and/or child virtual machines move to the same folder where a parent machine moves. If a parent is moved to the Recycle Bin (to save a license), the clones and/or child virtual machines will also move to the Recycle Bin. Recommendation: The parent virtual devices should either be active or present in the Recycle Bin.

Self-Help warning messages, such as “Self-Help questions must be answered before continuing” and “Self-Help recover is not available for this user

Please contact your administrator” is prompted after the User logs into SecureDoc Control Center (SDCC).

Recommendation: Users are advised that, though self-help recovery is incongruous in the context of Cloud-hosted servers (since they auto-boot), at this point the standard behavior of the SecureDoc Key File applies, which natively normally requires responses to Self-Help recovery questions.

Installation packages cannot be created and prepared in an environment where SES Console and SDConnex are installed on physically separate instances (VM’s or real hardware)

The SecureDoc installation package creation fails if SES administrators use a different server (i.e. SDConnex is configured on a different server using the key file and Database from the other server) for creation of web installer packages.

Recommendation: Users are recommended to ensure that the SES Web (IIS) Server also has been installed with SDConnex and the SES Console (which can be in a non-used state, but it brings to the server the Installer executables required for creating installation packages within SESWeb). In case of multiple SDConnex setups for the SecureDoc CloudVM product to function, make sure that there is at least one SDConnex instance running on the server where SES CloudVM is installed.

SecureDoc CloudVM extends limited support for Azure Classic VM’s

When Azure Classic VM’s are synced into SES Web, the instant state will be reported as “ReadyRole” instead of “Running”. Note: “ReadyRole” actually means the same as a status of “Running” for other devices. This is because the Classic instances, unlike the RM instances, have a different system state label.

SecureDoc CloudVM does not support Generation 2 (UEFI) Virtual Machines on Hyper-V environment and vSphere UEFI virtual machine

The SecureDoc pre-boot functionality does not work on the Generation 2 with UEFI virtual machines. Therefore, these Generation 2 VMs cannot be encrypted using SecureDoc CloudVM.

When the “Prevent KF from being saved locally on the machine at deployment” option in the SESWeb installation package settings is set to Yes

The key files will still be pushed down to:
 Users assigned to a package
 Windows accounts, if enabled
 Users assigned to a folder where a device is moved

Recommendation: It is strongly recommended not to enable this option. If you want to push a key file to a device, manually push them by assigning user to a device.

Encryption progress bar is NOT displayed on some Azure RM Virtual Machines with Standard A1 & A0 size

When the SESWeb package is created and deployed with the "Hide Encryption Progress from User" option set to NO, the encryption progress bar is not visible after the device restart.

Recommendation: Please note that (in this version) in some circumstances you may not see the Encryption Progress panel on Azure RM Virtual machines with Standard A1 and A0 sizes, even if the installation package was configured to display it.

The remote command “Lock Device” does NOT work

The client device fails to lock when SES administrator’s attempts to lock a selected client device by sending a remote “Lock Device” command from SESWeb.

Recommendation: In this version, if it is desired to lock the device, we recommend the Administrators seize control of the device’s desktop remotely, and then send it to screen lock.

New clones cannot be created from the crypto-erased parent machines

If a Master virtual machine is crypto-erased, the new child instances using that master image will also be crypto-erased. It is recommended not to crypto-erase a parent virtual machine if you want to create new clones from its image.

Recommendation: Do not crypto-erase a parent virtual machine if you want to create new clones from its image.

SESWeb will NOT support partition encryption and excluding partitions

The Encrypt partition only option has been removed from SESWeb. SecureDoc CloudVM installation packages cannot be created and deployed to the client devices with the “encrypt partition only” option.

Microsoft Azure Classic VMs are not removed to Recycle Bin upon termination from Azure

When the Azure Classic VMs are terminated from Azure GUI, they are still visible on the Devices tab in the SESWeb are not moved to the Recycle Bin. The SecureDoc CloudVM license count remains unaffected.

Recommendation: If it is confirmed that an Azure Classic VM has been terminated, the SES Administrator should manually delete that VM, sending it to the Recycle Bin.

Auto-Scaled up and down cloud instances are not moved to Recycle Bin

When the cloud devices are auto-scaled up and then down within the 3-hour interval, the terminated devices (auto-scaled down) do not get moved from the Devices tab to Recycle Bin.

Since these devices still exist in the Devices tab, their licenses are not freed up. SES administrators should manually move the terminated (auto-scaled down) devices to Recycle Bin to free up the licenses.

Recommendation: Manually move the terminated (auto-scaled down) devices to Recycle Bin to free up the licenses consumed by these terminated auto-scale devices.


Limitations – Linux


CloudVM Linux runs on the following flavors of Linux along with these Kernel versions

OS Kernel Version
Red Hat 7.2 3.10.0-327
Red Hat 7.3 3.10.0-514
CentOs 7.2 3.10.0-327
CentOs 7.3 3.10.0-514
Ubuntu 14.04.3 3.19.0-25-generic
Ubuntu 16.04/16.04.1 4.4.0-21 to Kernel 4.4.0-64


Please note that SecureDoc pre-boot requires a separate volume in which is created during the installation process. Otherwise, the installation process will fail if we are unable to create this special volume.

Recommendation: Please confirm if the kernel version of the VM device to be deployed is currently supported with SecureDoc’s supported list included above.

SecureDoc Linux solutions do not support Dynamically added disks or volumes

As encryption is a onetime process, this applies to any disks. Volumes added after the VM device is encrypted will not be detected and Encrypted by the solution.

Recommendation: Please create the final volume layout of the VM prior to encryption.

For conversion, please see the recommendation listed here:

i. We highly recommend encrypting a Linux VM using our “Fast” and “Offline” mode set to yes.

ii. Please do not forcibly power off a VM during the encryption process regardless of the conversion mode. Whether it’s in the “fast” or “thorough” Mode.

iii. If you are using the “fast” conversion mode and Offline mode set to No then do not perform any read and/or write operations while VM is running. Example: copying a file or working on a program, during the conversion process.

Concerning current public Cloud market place images

In Azure, SecureDoc does not currently support the deployment of Ubuntu and CentOS flavors, due to environments limitations on Azure.

Recommendation: Please use custom images with available free space or SWAP space in the mentioned flavors if to be deployed in Azure.

In AWS, Secure Doc does not support the newer kernel versions for Ubuntu 16 flavors.

Recommendation: Please confirm that the kernel version is supported by referring to the SecureDoc Linux support list. Additional the use of Custom AMI’s is also recommended if VMs are required in the above mentioned flavors.

Client’s info is not all sent back to SES database after deploying and encrypting

Specifically Public and Private IP addresses as well as attached volumes and drives.

Recommendation: Drive information can be recovered by navigating to the Compliance tab in SDWeb, and then selecting the Linux device in question. IP information and Drive information to be added in future releases.

The SecureDoc pre-boot functionality does not work on the Generation 2 with UEFI virtual machines

The Generation 2 VMs cannot be encrypted using SecureDoc CloudVM.

Recommendation: Please run SecureDoc solutions on Legacy VM devices (Non UEFI). Please note legacy Bios is by default enabled on most public and private cloud environments. Some environments (such as Microsoft Hyper-V) do allow Users to change between legacy and UEFI modes.

Cloned VM using Static IP feature is unable to by-pass pre-boot and shows no network connectivity

Recommendation: Please do not use static IPs in parent images meant for Cloning or Auto scaling related deployments.

We do not recommend customers to update the Linux kernel after encrypting the VM

SDLinux client device will not boot to Linux and will shut down.

Here are the supported Kernel versions:

OS Kernel Version
Red Hat 7.2 3.10.0-327
Red Hat 7.3 3.10.0-514
CentOs 7.2 3.10.0-327
CentOs 7.3 3.10.0-514
Ubuntu 14.04.3 3.19.0-25-generic
Ubuntu 16.04/16.04.1 4.4.0-21-generic
  Kernel 4.4.0-31-generic
  Kernel 4.4.0-53-generic
  Kernel 4.4.0-59-generic
  Kernel 4.4.0-62-generic
  Kernel 4.4.0-64-generic


Additional supported Linux distributions and clients to be introduced in future versions.

On rare occasions the device does not start after installing Linux on the machine with redhat7.2 client on Azure

Please note that this is an issue with Azure infrastructure and not an issue with SES.

Recommendation: Shutdown and Reboot the VM in question.

Installation of multi volume encryption is haled on reboot for a system with more than 16 volumes

Recommendation: Please ensure that (including root + SWAP) that the environment does not have in excess of 16 volumes.

Encryption does not start when creating multi volume Linux VM environment specifically where there are volumes after the given range of sectors used or SWAP

Recommendation: This issue mainly manifests in LVM type devices used in private cloud instances and custom public cloud images. Please do not create any data volumes after creating SWAP space. Create all required data volumes prior to defining the space which would be used for SWAP.

In Microsoft Azure, SDLinux solutions cannot be deployed on either CentOS or Ubuntu related flavors

SDLinux requires the boot - encryption does not start with Linux installation package for SES web for offline conversion of boot disk. This is a result of both Ubuntu and CentOS requiring the boot drive to be the primary drive.

Work-around: We recommend using a custom VM Image (environment) created with either available SWAP or Free Space for the SDSpace volume to be created on the root Drive.

SecureDoc Linux AWS-RHEL7.3 does not support Amazon EFS instance storage types

Please find more information from the following link: SecureDoc does not currently support Dynamically allocated\deallocated storage space.

Recommendation: Please use AWS’s EBS storage solutions.

An SDLinux package, created with the encryption type “Encrypt All Disks", "Data Only Fast Encryption" will switch to Through encryption when faced with a volume with an un-recognized file system

Recommendation: As SecureDoc supports Most modern file systems, this issue is only randomly visible. It is however by design as it provides the maximum protection for such volumes. Feature can be readily visible when encrypting SWAP Space.


 View All Release Notes

—  share  —