Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Subscribers 6 subscribers
  • Views 35473 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SGN 5.50.8 - Endpoint will not encrypt after (New) install of 5.50.1/5.50.8

Robert_McGinley

Something seems to have changed with the flags that can be passed to the SGNClient.msi package when performing a silent install of SafeGuard Enterprise. If we install any 5.50.* package in the way we installed previous 5.35.* and 5.40.* packages, the machine will install everything fine, but refuse to encrypt giving a "Error initializing CBIStore" error in the "Encryption" tab under the drive properties.

Has anyone else run into this? I'm working with support, but we don't seem to be getting anywhere fast. If we install the client interactively not specifying any options on the command-line, but instead select features from the GUI, everything goes fine and encryption beings upon reboot.

I have verified there are no communication problems as other clients running 5.40 are working just fine.

Ideas anyone?

:6963


This thread was automatically locked due to age.
Parents
  • 0

    Just an update on this issue, we have identified the issue (Persistent CBIStore errors). The issue seemed to be caused by the way we were hardcoding our checkdisk routines after the client install but before the first reboot. The deployment script was originally written for 5.35, upgraded to 5.40 and then to 5.50(.8). 

    So, at the end of the client install, SGNClient.msi writes to the BootExecute registry key to specify that the SafeGuard bootloader (The POA screen/kernel/etc.) SGNInstArea.exe is run to finish up the install of the client. as of <=5.40 the location, post install of SGNInstArea.exe was C:\Windows\System32. What we didn't know (And didn't show up in testing immediately) was that as of 5.50, the location of that executable (Among others) was moved to C:\Windows. So after our initial reboot, SGNInstArea.exe was never being run at boot, thus never installing the POA and preventing the CBIStore (Local keystore) from initializing. Since the keystore couldnt be initialized no keys, certs or policies would be utilized from the server no matter how many times we clicked on the icon :smileyhappy: .

    We were able to identify these machines as the code that runs BootExecute typically removes it's entries (It's kind of a one time deal) after successful execution. Since SGNInstArea.exe wasn't being executed properly (Or at all in this case) it would remain the CurrentControlSet BootExecute key.

    The solution was of course to modify the BootExecute registry key to point to the (new) proper location of SGNInstArea.exe. Once that was done, POA was installed and everything was just duckie. Theres a bit more to this story, but these are the relevant bits. I will be glad to help if someone else is having this same issue.

    Thanks!

    :8201
Reply
  • 0

    Just an update on this issue, we have identified the issue (Persistent CBIStore errors). The issue seemed to be caused by the way we were hardcoding our checkdisk routines after the client install but before the first reboot. The deployment script was originally written for 5.35, upgraded to 5.40 and then to 5.50(.8). 

    So, at the end of the client install, SGNClient.msi writes to the BootExecute registry key to specify that the SafeGuard bootloader (The POA screen/kernel/etc.) SGNInstArea.exe is run to finish up the install of the client. as of <=5.40 the location, post install of SGNInstArea.exe was C:\Windows\System32. What we didn't know (And didn't show up in testing immediately) was that as of 5.50, the location of that executable (Among others) was moved to C:\Windows. So after our initial reboot, SGNInstArea.exe was never being run at boot, thus never installing the POA and preventing the CBIStore (Local keystore) from initializing. Since the keystore couldnt be initialized no keys, certs or policies would be utilized from the server no matter how many times we clicked on the icon :smileyhappy: .

    We were able to identify these machines as the code that runs BootExecute typically removes it's entries (It's kind of a one time deal) after successful execution. Since SGNInstArea.exe wasn't being executed properly (Or at all in this case) it would remain the CurrentControlSet BootExecute key.

    The solution was of course to modify the BootExecute registry key to point to the (new) proper location of SGNInstArea.exe. Once that was done, POA was installed and everything was just duckie. Theres a bit more to this story, but these are the relevant bits. I will be glad to help if someone else is having this same issue.

    Thanks!

    :8201
Children
No Data
Unfiltered HTML