SafeGuard Enterprise: How to update to SafeGuard Enterprise 5.50

Hi ssij,

You wrote

"Your last suggestion (removing the CP component from the SGNClient.msi file and reinstalling it) seemed to work for this one machine, but it makes it difficult to script an install, and doesn't answer the question as to why the approved update procedure is failing consistently on my machines."

I'm glad I was able to help, but the scripting is possible. If you are running into issues with the other devices, it's going to be a daunting task to figure it all out within the forums. Would you be kind enough to open a case with Sophos Technical Support so they can collect log files from you to see where the disconnect exists?

You wrote:

"My best guess is that when the SGNClient is upgraded, the ClientConfig.scc is either re-created or remains as-is, but by removing the v5.40 CP Client in step two, that file is also removed by the installer.  Thus, re-installing the CP component in the SGNClient.msi re-creates the file and allow the v5.50 CP client to properly install."

You are absolutely correct in your second sentence quoted above. The ClientConfig.scc file is recreated when the SGNClient.msi is executed and includes the Configuration Protection component for an add or remove.  In step 2, you need to remember to execute the old SGN_CP_PortProtectorClient.msi v5.40 and then the new SGN_CP_Client.msi v5.50. From the way I read what you wrote, it sounds like you are using the SGN_CP_Client.msi to uninstall the SGN_CP_PortProtectorClient.msi. If not, then I'm really confused as to the state of the software installed on that device.

You wrote:

"If my guess is correct, removing the v5.40 CP Client BEFORE upgrading the SGNClient to v5.50 might solve this problem, but the CP Client doesn't seem to like that (asks for a uninstallation password).  Do you know of a way of getting around this?"

Your guess sounds correct, but it's the SGNClient.msi which is providing the password. If you attempt to add or remove the CP component using the SGNClient.msi, then restart without running the next msi on the list, then that msi will fail to install or uninstall. Make sense? There is no way to get around the password other than using the SGNClient.msi to control the installation or uninstallation of the second CP installer.

You wrote:

"I guess it would also be possible to copy the ClientConfig.scc file to a temporary location before uninstalling the v5.40 CP Client and copy it back after the uninstall is complete, but will that cause any other strange problems (with policies being applied, etc)?"

I wouldn't move the ClientConfig.scc file. The secondary CP installer is looking for it in a specific place and if it's not there then the install will fail. Sorry, but I couldn't tell you how it will impact policy application because I leave the ClientConfig.scc file alone.

Hang in there, we'll get through this.

Hi ssij,

You wrote

"Your last suggestion (removing the CP component from the SGNClient.msi file and reinstalling it) seemed to work for this one machine, but it makes it difficult to script an install, and doesn't answer the question as to why the approved update procedure is failing consistently on my machines."

I'm glad I was able to help, but the scripting is possible. If you are running into issues with the other devices, it's going to be a daunting task to figure it all out within the forums. Would you be kind enough to open a case with Sophos Technical Support so they can collect log files from you to see where the disconnect exists?

You wrote:

"My best guess is that when the SGNClient is upgraded, the ClientConfig.scc is either re-created or remains as-is, but by removing the v5.40 CP Client in step two, that file is also removed by the installer.  Thus, re-installing the CP component in the SGNClient.msi re-creates the file and allow the v5.50 CP client to properly install."

You are absolutely correct in your second sentence quoted above. The ClientConfig.scc file is recreated when the SGNClient.msi is executed and includes the Configuration Protection component for an add or remove.  In step 2, you need to remember to execute the old SGN_CP_PortProtectorClient.msi v5.40 and then the new SGN_CP_Client.msi v5.50. From the way I read what you wrote, it sounds like you are using the SGN_CP_Client.msi to uninstall the SGN_CP_PortProtectorClient.msi. If not, then I'm really confused as to the state of the software installed on that device.

You wrote:

"If my guess is correct, removing the v5.40 CP Client BEFORE upgrading the SGNClient to v5.50 might solve this problem, but the CP Client doesn't seem to like that (asks for a uninstallation password).  Do you know of a way of getting around this?"

Your guess sounds correct, but it's the SGNClient.msi which is providing the password. If you attempt to add or remove the CP component using the SGNClient.msi, then restart without running the next msi on the list, then that msi will fail to install or uninstall. Make sense? There is no way to get around the password other than using the SGNClient.msi to control the installation or uninstallation of the second CP installer.

You wrote:

"I guess it would also be possible to copy the ClientConfig.scc file to a temporary location before uninstalling the v5.40 CP Client and copy it back after the uninstall is complete, but will that cause any other strange problems (with policies being applied, etc)?"

I wouldn't move the ClientConfig.scc file. The secondary CP installer is looking for it in a specific place and if it's not there then the install will fail. Sorry, but I couldn't tell you how it will impact policy application because I leave the ClientConfig.scc file alone.

Hang in there, we'll get through this.