Symantec EndPoint Encryption Installer

Symantec Endpoint Encryption (SEE) 8.0.1 is my first upgrade since Symantec purchased GuardianEdge.  It is a newer version inspite of being a lower number than GuardianEdge 9.5.x.    I guess it is really too soon to expect big changes.   I was hoping they would address some of the installer annoyances.

With SEE, you install a management server, then create the client install packages.   These are MSI packages.

Separate 32 bit and 64 bit Installer Files
I don’t do MSI package generation myself, but the software I’ve seen allows you to put both 32 bit and 64 into one installation file.   I would think this would make things a lot easier.   The main drawback would be the size of the install file.    I end up putting both 32 and 64 bit files into one installation package and call the appropriate one based on the CPU architecture.   So it doesn’t save me space and instead requires extra scripting work.   Is there some technical limitation I’m not aware of?

Upgrading versions of Symantec Endpoint Encryption (or GuardianEdge Hard Disk Encryption) requires using special switches.   When performing an upgrade, I need to use the command line MSIEXEC /i “\.msi REINSTALL=”ALL” REINSTALLMODE=”vomus”.   This upgrades the client by reinstalling all features of the product.

On the other hand, a regular install of Symantec Endpoint Encrytption, where it was not installed previously, uses more familiar switches (/qb).   In previous upgrades I’ve found that if I try to use the reinstall/reinstallmode switches on a fresh install it will not work.   I then have to script the install to use different command line options based on installation status in addition to 32 bit versions 64 bit.

To make matters worse,  some computers in my environment have Removable Storage Encryption and others don’t.   My install script is getting too complicated.

Full Control
When creating the installation package, you must save the client installation package to a local or network volume with Full control permissions set.  The SEE instructions say “This ensures the success of the upgrade package, as it will retain the Windows permissions of the location to which it is saved.”    Again, I don’t create MSI packages often.   Adobe Reader and Symantec Endpoint Encryption both create packages where a setup.exe calls the MSI.   However in neither case am I advised to change permissions on a folder.

I think I actually have seen issues that support has blamed on not creating the package in a directory with Full Control.    But I’m not sure what the actual problem is.

The old Files
In the past, when I’ve upgraded using the switches provided, I found I needed to have all the old install file available.   While people are generally on one version, I found it better to leave every version I’ve ever used in the install directory.   That can take up a lot of room.

I’m really lost as to the cause of this issue.   Shouldn’t MSI files be cached locally so even if it did need the original installation files it should have them, not require me to have them.   I am going to try one more time and removing the old install files from my SEE8.0.1 package and see if I still have issues.   Perhaps that was a problem only with older versions of the product.

Doesn’t Symantec own a MSI packaging company?   Hopefully some in-house expertise can cross divisions of the company to create a better product.


  1. Howdy. Glad to find someone with some GEHD/SEE experience. Any comments regarding GE 9.5.3 vs. SEE 8.0.1? Both should fix our catastrophic problem with the Dell E6410s, but we’ve been having all sorts of problems with clients losing communication with the manager with 8.0.0… presumably because Symantec retained that portion of Encryption Anywhere.

      • Already? We have a limited test deployment of SEE 8.0.1 clients and one of our HP laptops already got the “Dell E64xx” style error. Looks like I’ll be calling Symantec tomorrow about SP1…

  2. The fix for SEE with E6410 is usually a BIOS update on the machine. If you check the BIOS, make sure you are running at least A02 as per Symantec. This was addressed back in 7.0.8 I believe. The current BIOS release is A07 for this model, so should work.

    My current issue involves E6400 and SEE 7.0.8 SP2. After a working login of the pre-boot, Windows fails to load. It passes the notorious 6 dots now (updated BIOS fully) but goes blank and never loads. I know per SEE Support they say this is typically a MBR related issue, but they also say in 7.0.4 that the E6400 is compatible and fixed a slow boot issue then.

    This machine is headed to my office for testing, so I will soon know if it’s an AHCI BIOS setting causing this or not. Last tech, before having it sent to me ran the MS FixIt tool to enable AHCI in windows but I have yet to find out from him if he checked the BIOS to see if AHCI was already enabled, or if he switched it to AHCI. I know the first key for that Win Vista/7 FixIt tool changes msahci to Start|0, and this registry had it as Start|4. But all I know before the box gets here and I hear back from the techs.

    Any thoughts on this specific version, and model?

  3. I’m running into snags with Dell E6320 + Endpoint Encryption 8.0.1… where a scheduled disk check causes the machine to no longer boot, and attempting to boot into safe mode hangs at “classpnp.sys”

    Looks like this will be resolved around the 2nd week of June when 8.0.1 SP2 is released. I’m told by Symantec that 8.0.1 SP1 was by request only, but now pulled because it was causing more harm than good.

      • by sp2 you mean 8.0.1 sp2 which just came out?
        e6420 is listed in the release notes in the fixed issues section, although it doesn’t say what was fixed.

Comments are closed.