Please note that WinMagic is deprecating SecureDoc V4 PreBoot Authentication (PBA) support for SEDs in favor of the fuller function, more capable, V5 PreBoot Linux (PBL). The existing V4 support for SEDs will remain in the product for the time being but will not be maintained or enhanced. We recommend that customers migrate to V5 PBL over the course of the next year.
WinMagic has done extensive work to improve, streamline and augment the security surrounding the initial deployment of Key Files during the process of installing the SecureDoc Client software, bearing in mind that many customers have widely divergent requirements relating to how devices are used during and after initial installation. Some customers install SecureDoc while the primary device user is on or will be on the machine, while others may need to protect new devices before the end-users of those devices have been defined, as well as other scenarios.
Please refer to the When SecureDoc server is upgraded to version 7.1SR5 HF4 from previous versions (6.5 or earlier) and the Device Provisioning Rules sections under the Creating Installation Packages for Windows chapter in the SES User Manual to understand how these new settings work, in order to inform your own use of these new features, particularly as they operate in a way that cannot be easily migrated from the previous methodology to the new methodology. Upon upgrading from an earlier version, you will need to adjust each of your existing Installation Packages to reflect the deployment methodology that will meet your security design.
System requirements and supported devices, including tokens and SmartCards, for SecureDoc v7.1 SR6 are listed here.
Note: It is strongly recommended to initially install Full-Text Indexing feature (Full-Text Search) into the Database Engine, before performing an SES installation. More information can be found here: http://msdn.microsoft.com/en-us/library/ms143786(v=sql.100).ASPX
During the installation of SES, if Full-Text Indexing has not been installed, a message will appear indicating the absence of the Full-Text Indexing. This message will not allow the user to stop the installation of SES which will require retrofitting Full-Text Indexing into an existing SQL Server.
Note: Use of the SES Console will require the user to have at least local admin rights on the server or client device (e.g. Admin desktop) on which it runs, in order for the console to function properly.
VMware – SecureDoc PBA is not supported on Windows 10 RS2 clients running in VMWare (only). VMWare customers should not install Windows 10 RS2 in VMWare clients if intending to use SecureDoc (until a solution is found).
This limitation is between SecureDoc and VMware on Virtualized devices using UEFI BIOS, but does NOT affect VMWare devices that utilize a legacy BIOS.
VMware on UEFI requires UEFI binding to be used, and since SecureDoc only supports UEFI Driver Hooking, SecureDoc won’t support Windows 10 RS2 on UEFI virtualized devices.
Note that there is no impact on physical devices running Windows 10 RS2 and SecureDoc, so on physical devices SecureDoc 7.1 SR6 officially supports Windows 10 RS2. To accommodate Windows 10 RS1 (and prior versions) under VMWare, certain configuration changes are required, as follow:
Note: There is no SES User Interface option for this change at present, so this must be done manually though the Profile’s “Edit Manually” button option:
Add the following to the desired Device Profile:
This will enable/force UEFI Binding for VMWare-hosted Windows 10 devices up to RS1.
|Addendum to above||
VMWare hosting a Windows 10 RS1 (or below) virtual device will not work with SecureDoc PBLU (Pre-Boot Linux environment for UEFI devices) and requires either PBU (SecureDoc native pre-boot for UEFI devices) or PBL (Pre-Boot Linux for Legacy/BIOS devices).
Customers should convert any Virtual Devices that they intend to upgrade to Windows 10 RS1 or below to use either PBU or PBL Pre-Boot Environments.
All existing SecureDoc devices that have Profiles enabling SecureDoc File Encryption (SFE) – versions (V71.SR6 and earlier) - must have SFE disabled before attempting to upgrade to Windows 10 RS2. This applies to devices intending to upgrade from Windows 7, 8 or an earlier version of Windows 10.
The software library upon which the SFE feature is built causes problems during the upgrade to Windows 10 RS2, causing it to fail. By disabling this feature in the client device, the upgrade can be permitted to continue.
Once the upgrade to Windows 10 RS2 has completed, the SFE feature can be re-enabled, but will need to be disabled yet again in the event of any further Windows 10 upgrades.
NOTE: For SecureDoc V7.1SR6 and earlier versions on Windows 10 TH1, RS1 and upgrades from these, Windows Driver Signature Enforcement must be DISABLED on the client device, or SecureDoc File Encryption will not work.
The ‘manual communicate to SDConnex’ feature within the SecureDoc command line tool has been corrected, now communicates when triggered.
Issue: After a command prompt is called on the client device with Administrator rights, entering the command >sc control “WinMagic SecureDoc service” previously would result in the client not communicating with the server.
This issue is now resolved and the command will successfully trigger communication with the server, as indicated by the small confirmation pop-up message appearing above the tool-tray near the bottom right of the desktop whenever the command has been executed and the server successfully reached.
SDFV2 and SDOTFV2 – Mac devices could not be recovered because the Master Key Chain (MKC) would not be securely stored on the device, and after first transmitting this data to the database it was deleted from the device. If device data had been deleted from the SES Database, it would make it impossible to create a Device Emergency Disk, causing difficulties in device recovery.
Issue: After deploying SDOTFV2 package and completing device encryption, the device transmits its Master Key Chain to the SES Database (after which it was deleted from the device). If the device record was deleted from the SES console (and database), the device could not re-send its Master Key Chain to SES since it did not reside on the device anymore.
This issue is now resolved. The Device will retain its Master Key Chain on the device in a protected form, and can (re)transmit it to SES if required.
Gemalto IDPrime MD830 smart card had issues with the built-in Alcor smart card reader.
This issue is now resolved, and Gemalto IDPrime MD830 smart cards can now be used with the built-in Alcor smart card reader.
Improved the warning message for SD Mac after performing the OSX upgrade – for each minor upgrade on 10.11.x and 10.12.x.
Issue: SecureDoc at Pre-boot is not displayed on Mac account User Login page.
This issue is now resolved. SecureDoc will trigger the display of a message indicating that SecureDoc has recognized that the Mac OS has undergone an interim/minor update, and that SecureDoc’s Pre-Boot has adapted to that, and lastly that the device will need to be rebooted.
Excluded user accounts were still being created and added to endpoint devices.
Issue: The user exclude list of the Windows Account feature permits definition of User Accounts for which Key Files should not be created and which should not be associated with devices. In the original issue, although users were added to the exclude list, when a user logged into Windows, those excluded users were still incorrectly being added in the SES database and getting key files on the devices.
This issue is resolved and such user accounts will not have a key file created, nor will they be associated with the device in the SES console.
Incorrect display of Admin ID in Audit Log for SESWeb.
The original problem was that, rather than showing the current logged-in user ID of an Admin user logged into the SESWeb console, the log entries that recorded what that Administrator had done in the console (e.g. what changes or commands were executed by that User) would continue to show the User ID of a previously-logged-in User.
This issue is now resolved in SES Web where the correct user is now displayed under the Admin ID column in the Audit Log page for actions/commands by that user.
Timing improvements made to permit SecureDoc Client to update information in SED Shadow MBR more dependably.
Improvements were made to the Shadow MBR synchronization sequence on SED’s during the User’s initial login process to the operating system, ensuring that SecureDoc can update information in the Shadow MBR during boot-up. These improvements resolve several rare cases seen during the Secure Moment process of the deployment where the temp user account was not being removed from the system – and the device would remain in provisioning mode.
SDConnex reports an error after it stalls for a period of time.
Issue: A customer reported that after a random period of time (typically some 2+ days), SDConnex might start reporting the error "Service error while processing request status=0x60090". Once this error occurs, it prevents communication between the SecureDoc clients and SDConnex, requiring the SDConnex service to be restarted to resolve this issue. Not all customers were affected by this issue.
This issue has been fixed in SDConnex.
|SD-21607||SecureDoc Mac officially supports Mac OS 10.12.4.|
Changes to the Password Propagation functionality to reduce lag time when user has key files on 100+ devices.
This issue has been resolved: To prevent SES from creating and sending down a high volume of key files to the client devices, a change in the current password propagation feature was made to control and avoid disruption to the SDConnex communication traffic. If a user currently resides on 100 or more computers, the password propagation feature will be disabled for that user.
The DataCacheManager functionality has been removed from SDConnex.
This change completes the elimination of the DataCacheManager functionality by removing the last configuration elements of it from the SDConnex User Interface.
Windows 10 RS2 is officially supported under SecureDoc.
We are now certified as fully supporting Microsoft Redstone RS2 on the latest release on physical devices.
Note however that VMWare does not (currently) support Windows 10 RS2, so SecureDoc similarly will not work with VMWare-hosted Windows 10 RS2 virtual devices.
The throughput and scalability of SDConnex command handling has been significantly increased for all commands. Our lab tests showed more than doubling performance of previous versions.
Improvement: The throughput and scalability of SDConnex command handling has been significantly increased for all commands. Our lab tests showed more than doubling performance of previous versions.
This issue has been resolved and enhanced.
Password Rules button missing in SecureDoc prompt for device owner credentials.
This issues is now resolved. A password rules button was added to the “No Provisioning” dialog to allow users to see the current password rules, to which their new password must conform, when creating new SecureDoc credentials.
SDWeb – Crypto-erase command not properly logged in the Audit Log when generated from within SESWeb console.
In this issue, any device Crypto-erase commands submitted from within the SESWeb console were not being logged in the Audit Log.
This issue has been resolved: Logging of these commands has been improved in SESWeb, which now captures and logs Crypto-Erase events performed on client devices.
Pressing Enter key on the SecureDoc Set Device Primary Owner Credential panel should emulate clicking the OK button, not emulate clicking the Password Rules button.
This issue has been resolved: Improvements were made to the GUI on the Set Primary User dialog of the SecureDoc Set Primary Owner panel to have the OK button receive focus, and not the Password Rules button. Pressing Enter on this form is the same now as clicking the OK button.
Resetting the default value of Crypto-erase confirmation set to “No” (cancel out of the prompt without changing anything).
The SecureDoc User Interface has been enhanced to include a simple safety improvement:
The Improvement: If the user were to press the Enter key on first seeing the prompt panel, the default behavior now is that the ‘No’ button has focus so the device will NOT be crypto-erased and the prompt panel will close.
This improvement requires that the user must intentionally click the ‘Yes’ button to continue to decrypt the drive.
Under SecureDoc for Mac’s SDFV2, MacBook Pro customers may encounter an issue with the device not recognizing that is already plugged into mains power. It will prompt to be plugged in, in preparation for encryption, but though already on mains power is unable to continue.
Issue: During encryption on the MacBook Pro the progress is paused and a message is prompted asking “Please plug in power to continue encryption” while the power is currently plugged in. This issue was encountered primarily on systems containing Core Storage, but did not always occur.
Where this error appears, it became clear that it pertains to such Core Storage devices, and users would need to restart the system in order to permit the encryption to continue.
Solution: WinMagic now automatically reboots such devices in order to permit the device to continue on to complete initial encryption.
SDFV2/SDOTFV2 Automated feature to prevent installation of SecureDoc CloudSync on El Capitan and Sierra.
Issue: CloudSync is currently supported on Yosemite OS. WinMagic is working on a means to prevent automatic installation on both El Capitan and Sierra versions of Mac OS X.
Unable to force direct boot to Windows on SED-equipped Lenovo desktop clients and some Dell laptops.
Issue: Lenovo and some Dell desktop devices using SEDs (detected on Lenovo ThinkStation P710/ThinkCenter/Dell Precision 7710 models) were unable to boot past the BIOS in order to boot Windows.
Work-around: SES Administrators must enable the UEFI “Force direct boot to Windows” option in the Advanced Settings panel of the Boot Configuration section of the device Profile for affected devices.
Then, warm-rebooting the platform with Ctrl+Alt+Del at the BIOS screen will cause the newlyunlocked drive to load the Windows Boot Manager and boot to Windows successfully.
SDOT FV2 doesn’t support receiving key files from SES (to be added to Pre-Boot) that were requested using the built-in Mac Account feature in FV2.
This issue is currently being investigated and will be resolved in the coming version to properly handle the key file request from SDOT FV2 clients.
Touch screen issue with checkboxes in the SD Control Center when selecting Hard Drive from which to uninstall Boot-logon.
Issue: BSOD can occur under the following scenarios:
Work-around: When requesting to click on the check boxes in SDCC, attach and use a mouse instead.
Limitation: Dell Venue 11 – SecureDoc PBA requires the Boot Parameter settings to be enabled in the profile.
Work-around: At the boot configuration page enable “Use persistent mode”. Once you’re in Windows, startup SecureDoc Control Center and set “reboot=warm” in boot control | Advanced settings |boot parameters. Then restart Windows, and on pre-boot disable “Use persistent mode” setting.
Unable to utilize USB mouse on Dell E6450 devices after SecureDoc installation completes
Issue: USB mouse do not work properly after SecureDoc installation completes on Dell Model E6450 devices (only).
Work-around: The issue is resolved with updated drivers, please be sure to install the drivers here: https://downloadcenter.intel.com/product/65855/Intel-USB-3-0-eXtensible-HostController-Driver
Ideally, these updated drives should be installed in advance of SecureDoc installation to assure end-users of the smoothest device behavior.