SecureDoc V8.1 Release Notes

Alles anzeigen


Contacting WinMagic

5600A Cancross Court
Mississauga, Ontario, L5R 3E9
Toll free: 1-888-879-5879
Phone: (905) 502-7000
Fax: (905) 502-7001

Human Resources:
Technical Support:
For information:
For billing inquiries:


Supported Operating Systems

SecureDoc CloudVM System Requirements

Platforms Server Client

Public Cloud
Amazon EC2
Microsoft Azure

Private Cloud
VMware vSphere
Microsoft Hyper-V
Citrix Xen

Scale Computing

Citrix XenDesktop

SES Server Platforms
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016

SES Server SQL Platforms
SQL 2012
SQL 2014
SQL 2016

Windows Versions
Windows Server 2016
Windows Server 2012R2
Windows Server 2012
Windows Server 2008R2
Windows Server 2008
Windows 7
Windows 10

Linux Versions
Ubuntu 14.04.3
Ubuntu 16.04.1
RHEL 7.2
RHEL 7.3
RHEL 7.4
CentOS 7.2
CentOS 7.3



New Features and Enhancements

Google Cloud support for both Windows and Linux
SecureDoc now supports Google cloud for both Windows and Linux. Users can deploy SecureDoc in Windows and
Linux VM for Google Cloud. Once on, users can create a VM instance and follow the
process to input their name, zone, machine type to create the new VM instance They can then proceed to deploy
SecureDoc packages.

Google cloud supported platforms:
- RedHat Enterprise Linux (RHEL) 7.4

- Ubuntu 14.04 (custom image format, see below)

- Ubuntu 16.04

- Windows Server 2012 R2
- Windows Server 2016

Limitation: Users are recommended to only create a new custom Linux image and migrate it to Google.

Support for XenDesktop (VDI)
CloudVM can now encrypt persistent VDI (Virtual Desktop Infrastructure).


Permanent AutoBoot feature added to SDLinux

SDLinux now has a Permanent Autoboot feature. The enhancement permits removal or addition
of permanent autoboot User after deployment is complete.

Limitation: Update Profile is not supported for this version.


Newly supported regions have been added to Azure GEO location policies list

Enhancement: The newly announced Regions for Africa and Asia Pacific have been added into
Azure GEO location policies list. The list in “Prevent Azure from Auto-Booting if found in the
following Region(s)” has added these 2 regions of Africa and 2 regions of Asia Pacific:
- Africa: South Africa West and South Africa North
- Asia Pacific: Australia Central 1 and Australia Central 2


SecureDoc can now merge a previously-encrypted Linux volume to a newly encrypted Linux
volume after application recovery process

SecureDoc is now enhanced to be able to a Merging a previously encrypted Linux volume to a
newly encrypted Linux volume after application recovery process.

Note: Does not support the scenario when the new instance OS disk is not encrypted.

Limitations – Windows


Manufacturer info registration not updated properly for Scale Environment Cloud virtual

Enhancement: The manufacturer info registration for Scale Environment CloudVM's were not
being correctly shown in the SES Console following device registration Scale VM's were being
registered as "Red Hat".
The Manufacturer info is now being displayed/Identified correctly depending on Scale VM's or

Limitation: This issue existed exists in SES 7.28


Error 500 when creating Emergency Disk (EMG)

Issue: Error 500 is displayed when creating Emergency Disk while client is installing BootLogon.
The issue occurs in Windows client while BootLogon is being installed and creating an Emergency
Disk in SES Web at the same time.

Note: This issue does NOT occur on Linux Client.


SecureDoc Enterprise Server (SES) fails to install SES on Windows Server 2008 SP2 (DotNet 3.5.1)

As of version 8.1 you cannot run SES on Windows Server 2008 SP2 because .NET 4.7 cannot be
installed on this OS. SES can only run on an Operating System which can support .NET 4.7

• .NET Framework 4.7 is NOT Supported on Windows Server 2008 SP2.
• Supported Operating Systems:

Windows 7 SP1 (x86 and x64)
Windows 8.1 (x86 and x64)
Windows 10 Anniversary Update (x86 and x64)
Windows Server 2012 (x64)
Windows Server 2012 R2 (x64)
Windows Server 2016 (x64)


Users are able to login to SecureDoc Control Center even when the setting “Prevent key file
from being stored on device during deployment” is in effect.

Issue: The user is able to login to SDCC, and SES deploys a User Key File even when the settings
for password is “Prevent key file from being stored on device during deployment”.

Work-around: This issue requires 2 global options to be disabled:
1) Automatically update key file on device when user/device/group keys are modified
should be unchecked.
2) Enable password propagation should be unchecked.


[VDI] Cloned VM's created via the Machine Catalog provisioning are unable to get a network

Issue: Where a master image on XenCenter with SecureDoc already deployed and fully encrypted
and be able to autoboot at Preboot, if a clone VM is created it hangs at preboot and is unable to
obtain a network connection. In the case an encrypted cloned VM starts off in preboot which
doesn't have VDA client, the VM is unusable until the user logs in to Windows. This means this
scenario is not supported with the encrypted master image and cloning an encrypted VM.
SecureDoc needs to be installed AFTER cloning is done and not before.

Limitation: This is a limitation in 8.1 CloudVM.


Unable to assign SFE policy to device using SESWeb

The SFE policy can be assigned from SES Console Server but not in SES Web.

Limitation: Users do not have the option to create SFE Policy on web, it can only be created on
SES Console. The Administrator can only create SFE policies and assign them to devices from SES
Console Server.


[VDI] USB devices attached to VDI environments with RMCE do not detect and encrypt

Limitation: VDI environments encrypted with RMCE packages do not detect USB drives plugged
into the host computer and encrypt them. The USB drives are available within the VDI
environment and files can be freely transferred between the device and the VDI environment.


Failed to clone the VM from parent which was permanently deleted then restored into the
original folder by communicating client with SES

This is a pre-existing issue where if Parent VM is deleted from recycle bin completely, and then at
a later time Parent VM re-communicates and is added back into Folder, any new clones created
from this restored Parent VM cannot use PBN autoboot/register onto SES. However, if the Parent
is deleted and remain in the Recycle Bin, if subsequently restored via communicating with the
server, then the clones can register and PBN Autoboot as expected.

This issue is now resolved. A parent VM is necessary and used as template for other Scale Set
instances. Those Scale Set member/Clones will not be registered in SES if the parent VM was
deleted before. If the user deletes the Parent VM when there are no clones yet, you will not get a
warning message. If there are existing clones, and you delete the parent VM, then you will get a
warning message.

Note: All descendant scale set


Azure: Fails to create VM scale from parent VM with SecureDoc installed

Issue: Creating VM scale machines from a parent VM with SecureDoc installed unsuccessful. The
scripts used are meant for Unmanaged Storage (blob storage).
Azure has shifted from Unmanaged to Managed storage.
This is a limitation.

SecureDoc CloudVM does not support moving 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

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

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 reencrypted.

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.” are 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, so the User must provide answers to these 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-usable state), but the SES Server when installed brings to the server the Installer executables required for creating installation packages within SESWeb).

In case where multiple SDConnex servers have been configured 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 offers 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.

Even where “Prevent KF from being saved locally on the machine at deployment” option in the SESWeb installation package settings is set to Yes, there are scenarios under which users will still have a Key File stored on the device.

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: If it is important in the SES implementation (and where using the “Prevent KF from being
saved… “ option) to ensure that no User accounts are assigned to the Installation Package, the option to add
Windows accounts should be disabled, and the Administrator should not assign users to any folders where the
device exists (or to which the device could be moved). Then, if you want to push a key file to a device, manually push the key by assigning a user to the device.

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

Issue: When the SESWeb package is created and deployed with the "Hide Encryption Progress from User" option set to NO, the encryption progress bar is still 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 that are configured 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 engage Screen 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 cryptoerased. 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. This is another aspect of the limited support available for Azure Classic.

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



Contact Technical Support error occurs when sending Crypto erase device to SDLinux devices

Issue: SES Console is sending Crypto erase device command to SDLinux device but shows error
'781a contact technical support'. In the SES console, sending Crypto erase command to Linux
client still works properly but user may see a pop-up error message.

Note: Pop-up error issue does not occur when sending command from SES Web.

Limitation: This issue only occurs in Private cloud (VMWare, Hyper-V and VSphere) but not in
Public cloud (Microsoft Azure and Amazon).







SDLinux deployment on kernel 4-4.0-1020 of Ubuntu 16.04 LTS (HVM) is not supported

Issue: [AWS] Fails to deploy default package on Ubuntu 16.04 LTS (HVM) kernel 4-4.0-1020 (New Kernel). No driver file was found for new kernel version 4.4.0-1020 when deploying package on Ubuntu. This kernel is the special version for AWS:

Work-around: Download the new version of pre-build file for kernel 4.4.0-1020, and add the new
version in the publishing build.


Encryption of the root volume is skipped when performing online fast conversion on kernel
4.8.0-46-generic of Ubuntu 16.10

Issue: Ubuntu 16.10 kernel 4.8.0-46-generic: Online fast conversion skipped root volume with
error:adjustSectorBlockToConvert failed 0x7f2bb79c. The volume sda1 (root volume) was skipped

while other data/swap volumes successfully encrypting/encrypted after deploying the package.
This only occurs on Ubuntu 16.10 with kernel 4.8.0-46-generic.

Work-around: N/A.


SDLinux: Timeout interval should be disabled or made longer when driver is being downloaded

Due to slower network, if it takes over 30 seconds to download the driver, an error will be
displayed as no driver found when deploying package. This issue does not occur on a faster
network. The timeout is now set to 25 seconds as the default.

Limitation: In SES 8.1


Linux Cloud devices deleted completely (removed from recycle bin) are unable to re-register in OS time

Issue: Using Windows as the Client OS, when a device was deleted from SES including being
deleted from the recycle bin, upon its next communication attempt SDConnex will not be able
find it in the Database and will send an error to the client with a specific error code. When the
client receives this response it will send another request which will allow SDConnex to re-register
it as a new device.
However in Linux Cloud, devices are not able re-register.

Limitation: For Windows devices, users have special handling to allow re-registration of a
Windows CloudVM that was deleted and moved to recycle bin. After 2 communication requests, it
can re-register and move itself back to its original folder.
For Linux this feature has not yet been developed.


    Linux cloud device completely deleted from SES (including from the recycle bin), once restarted, will hang at pre-boot

    Issue: When Cloud devices (Windows or Linux) deployed with PBN Autoboot enabled, and is
    deleted (including from the recycle bin), the device hangs at pre-boot.

    Limitation: SecureDoc currently do not support device re-registration at pre-boot time. Windows
    supports re-registration at OS time, however Linux does not support re-registration at pre-boot
    nor at OS time.


    Azure: Fails to create VM scale from parent VM with SecureDoc installed

    Issue: Creating VM scale machines from a parent VM with SecureDoc installed unsuccessful. The
    scripts used are meant for Unmanaged Storage (blob storage).
    Azure has shifted from Unmanaged to Managed storage.

    This is a limitation.


    Ubuntu16.04 Kernel 4.11.0-1013-azure: Fails to boot into Linux OS after the installation

    Issue: Ubuntu 16.04 with Kernel 4.11.0-1013 or 4.11.0-1014 on Microsoft Azure fails to boot in Linux or hangs at pre-boot.

    Limitation: This is as existing limitation, where a custom Ubuntu 16.04 image is required for


    Unable to deploy SDLinux to default Ubuntu 14.04.3 LTS image on Google Cloud

    Issue: Deploying SDLinux to default Ubuntu 14.04.3 LTS image on Google Cloud failed while it is
    NOT occurring with the custom Ubuntu 14.04.3 LTS image on Google cloud or default/custom
    Ubuntu 16.04 LTS image on Google cloud.

    This is a known limitation.


    RedHat - Offline login with key file on USB is only working if USB with key file was not
    disconnected since last time it was used in the OS

    Issue: This occurred in RedHat in private cloud, the administrator will physically plug in the USB
    and authenticate at our pre-boot to boot the server that cannot reach SES due to connectivity
    issue. Currently this is only working if USB with key file inside was connected while Device is in OS
    and then restarted and the device gets back into preboot (USB connected all the time).

    This is a known limitation.

    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, regardless 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 versions

    Recommendation: Please confirm that the kernel version is supported by referring to the SecureDoc Linux support list. Additionally, 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.

    Missing IP information and Drive information will be added in future releases.

    On rare occasions the device does not start after installing RedHat7.2 Linux on client device 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 halted 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.

    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 encryption settings of: “Encrypt All Disks" and "Data-Only Fast Encryption" will switch to Thorough (every sector) encryption when faced with a volume containing 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. This feature can be readily visible
    when encrypting the client’s SWAP Space.


     Alles anzeigen Release Notes