Endpoint Encryption

 View Only
  • 1.  SEE disables USB Ports after improper shutdown?

    Posted Feb 09, 2015 09:59 AM

    Greetings.  Here is my scenario.  My company mostly uses Windows XP, but we are moving to Windows 7 with each new machine or re-image being deployed.  We also use Symantec Endpoint Encryption, 8.1.2 MP5.

    We've noticed that on machines that have the encryption software, if the machine loses power at a certain point, upon reboot, the USB ports are disabled.

    Here's the problem...during normal operation, or sitting at the C-A-D screen, no issue, just need to wait out the 30 second timer on the Windows Boot menu, and the auto-selection will be, "Start Windows Normally".  We can't select anything else, because the keyboard and mouse do not work.  We have tried all different USB ports as well, USB 2 and USB 3, same result.  So not much of a problem...but a timed hinderance.

    BUT....if the power is lost when Windows is loading it's start-up files, basically when it says, "Starting Windows", the system defaults to a different boot menu with two options.  The default selection is "Launch Start-Up Repair (recommended)".. The problem is that utility never fails to repair the Windows boot order, and leaves the machine in a non-usable boot-loop.  The utility failure occurs with or without encryption and is a known Windows issue.

    So the only way around that is to decrypt the drive, slave the drive, copy user data, and then re-image.  Decrypting a mechanical drive can take over 30 hours, leaving the user without a machine for over a full day.

    We tried using BCDEDIT to ignore all failures, but it still defaults to that Launch Repair option..

    My thought is that SEE thinks someone is trying to access the Windows partition before it loads, so it disables the USB until Windows can take over in a proper loading sequence and initiate the OS correctly.

    On a laptop, it's not so much of an issue, because the on-board keyboard still works...but with all Desktops, and a large amount of laptops that are used in a type of kiosk/cart, where the laptop is secured and normal use has an exterior USB keyboard, the machine becomes a brick in a way.

    Is this a known behavior of SEE?  And if so, is there any way to disable it?

    Sorry for long question, but I wanted to give as many details as I could.  Please ask questions if I missed something.  This is seriously affecting a large deployment project of over 350+ machines..

    Thank You, 

    -Rick S



  • 2.  RE: SEE disables USB Ports after improper shutdown?

    Posted Feb 09, 2015 10:22 AM
      |   view attached

    Just to verify, the USB mouse and keyboard work normally except when power is interrupted during encryption?

    Check in the BIOS to see if there is a setting for Legacy USB support.  That will usually allow a USB device to be loaded in the preboot environment, which may also fix the issue you are running into.  There are a couple specific points where drivers are loaded, basically right after POST where preboot authentication takes over, and loading Windows.  If there is a Windows issue, it may not be able to load them properly in either spot.  You may also want to try a customized hardware package if it seems like the same issue is occurring on a specific model or only a few models.

    Attached is a walkthrough of creating a customized hardware package:
     

    Attachment(s)



  • 3.  RE: SEE disables USB Ports after improper shutdown?

    Posted Feb 09, 2015 10:35 AM

    Hi Mike..thanks for the reply.

    To clarify, it is not during the initial encryption stage, the drive is normally fully encrypted before we deploy.  The issue happens when Windows startup is interrupted by a power loss.

    So after we the hit power button, we see the normal POST check and Logo screen, then we get the small message at the top of the screen about Symantec Endpoint Encryption loading, then a black screen with a blue box with the SEE title as well, then it usually hands off to Windows to begin loading the OS.  If power is lost at that point only, the OS Loading gets corrupted and we find ourselves in that scenario.

    I've tested this on multiple models, Desktops and Laptops, and it is only on Windows 7 with Symantec Encryption.  So I don't think it's a USB Legacy setting.  Devices with no encryption do not lose the USB ports, and a user can simply arrow down to Start Windows Normally.

    I have just tried a file from Technet, that should disable the Start-Up Repair as an option, but it did not work, even when Run As Administrator was selected.

    So I'm back to square one...



  • 4.  RE: SEE disables USB Ports after improper shutdown?

    Posted Feb 09, 2015 11:51 AM

    I'd suggest giving SEE11 a whirl if you're still under maintenance.  Symantec have changed the PBA environment away from GE's one in favour of PGP's (which has historically been more robust).



  • 5.  RE: SEE disables USB Ports after improper shutdown?

    Posted Feb 09, 2015 12:16 PM

    The choice for which version is not mine to make unfortunatly.  I'm just a workrer bee, so to speak...

    The majority of our software is in lgacy state, due to being incompatible with today's tech.  Most common OS is XP, with a browser of IE7, still..if that gives you an idea.  Once a majpr project goes live in March, we'll start shutting down the legacy in favor of the replacements, but that still may not affect the version of SEE we will use.  Last time I asked, I think the new version of SEE being tested here was same revision, but a different MP number...



  • 6.  RE: SEE disables USB Ports after improper shutdown?

    Posted Feb 09, 2015 12:29 PM

    Yup, if sticking with the same (GE-based) version of SEE, then you're a good 9 Maintenance Pack versions behind as the latest is 8.2.1MP14

    http://www.symantec.com/business/support/index?page=releasedetails&key=55414

    These are definitely worth keeping up with as issues are still being fixed:

    http://www.symantec.com/docs/TECH187743

    Althoguh from the sounds of it, this may still be a current problem:

    http://www.symantec.com/docs/TECH208896