SVE update proces from 1.1 to 1.2 (SSVMs and GVMs)

Hello adrian yhy 

If you look in the guide at section titled: Migrate to Sophos for Virtual Environments you will find the process to help with moving from 1.1 to 1.2.  

The guides can be found here https://www.sophos.com/en-us/support/documentation/sophos-for-virtual-environments.aspx 

Q3) at the moment you will need to use an account that does not require MFA to log into Central - we are working on a fix for this. 

thanks 

Mark  

This is not very helpful....

I installed SSVM 1.0 or SSVM 1.1 on several ESXi already and have like 400 VMs.

Then recently there was an update which in Sophos Central required a reboot of the servers which would be the ESXi hosts.....This was a painful task of vMotioning VMs & rebooting servers etc but the expected result was an updated SSVM (SSVM 1.2 hopefully).....The very stupid thing is there is no versioning control or versioning visibility in Sophos Central (there are really stupid idiots designing the Sophos central webGUI).

BTW, there is also no version visibility or version check on the SSVM installer (eg telling user that they are installing version 1.1 and not 1.2 or the later versions). A lot of people did not knon they were installing SSVM 1.1 or SSVM  1.2 unless that have recently re-downloaded the installer and noticed the additional questions they have to fill in like password for sophospublic and additional SSVM IPs. Else nobody will know the difference.

There was a statement that SSVM 1.0 & 1.1 cannot be updated to the new SSVM 1.2 and that even if SSVM 1.0 & SSVM 1.1 is updated SSVM 1.2, all the fail over features will not work.....this statement was removed from your "guides" which was recently changed.

Do note that SSVM 1.1 was the version launched not to use the VMware vShield.

So now we have to "MIGRATE" SSVM 1.1 to SSVM 1.2 ? Then uninstall and re-install all the "thin-agents" on GVMs ?

Then if Sophos have a SSVM version 1.3....do we have to go through the *** all over again...."MIGRATE" the SSVM and re-install "thin agent" GVMs ?

This is not very helpful....

I installed SSVM 1.0 or SSVM 1.1 on several ESXi already and have like 400 VMs.

Then recently there was an update which in Sophos Central required a reboot of the servers which would be the ESXi hosts.....This was a painful task of vMotioning VMs & rebooting servers etc but the expected result was an updated SSVM (SSVM 1.2 hopefully).....The very stupid thing is there is no versioning control or versioning visibility in Sophos Central (there are really stupid idiots designing the Sophos central webGUI).

BTW, there is also no version visibility or version check on the SSVM installer (eg telling user that they are installing version 1.1 and not 1.2 or the later versions). A lot of people did not knon they were installing SSVM 1.1 or SSVM  1.2 unless that have recently re-downloaded the installer and noticed the additional questions they have to fill in like password for sophospublic and additional SSVM IPs. Else nobody will know the difference.

There was a statement that SSVM 1.0 & 1.1 cannot be updated to the new SSVM 1.2 and that even if SSVM 1.0 & SSVM 1.1 is updated SSVM 1.2, all the fail over features will not work.....this statement was removed from your "guides" which was recently changed.

Do note that SSVM 1.1 was the version launched not to use the VMware vShield.

So now we have to "MIGRATE" SSVM 1.1 to SSVM 1.2 ? Then uninstall and re-install all the "thin-agents" on GVMs ?

Then if Sophos have a SSVM version 1.3....do we have to go through the *** all over again...."MIGRATE" the SSVM and re-install "thin agent" GVMs ?

Hi adrian yhy 

I feel your pain, in order to add in the GVM migration capability and SMB security, unfortunately the product could not just be updated automatically as we had to ensure the functionality was secure (hence the addition of certificates) - this required additional steps in the installer process. 

This was not a decision that was taken lightly, but felt it was required to offer the best security solution.

We endeavour to not require uninstall/reinstall for future releases. 

At the moment we are looking at improving the installer workflow and making it easier for customers to install, one of these is making sure the version number is more obvious. 

Documentation and KBAs will also be improved within the next update to ensure customers have the information required. 

Genuinely thank you for your feedback, it does make our products better. 

Mark  

I do understand that everyone is trying to make their product better....but some foresight is required...

1. Making versions know BEFORE installing (if you have installed SSVM 1.1 and SSVM 1.2 you will know the diff...else you would not)

2. Let people know limitations of "updating" SSVM 1.1 to SSVM 1.2 openly. 

3. Plan and give better error messages...like for the error u'apis' (when you use a 2FA account to install SSVM 1.2)

1. Making versions know BEFORE installing (if you have installed SSVM 1.1 and SSVM 1.2 you will know the diff...else you would not)

>yes we are looking into how we can show that - but after version 1.2 the product will auto update (like it did from 1.1- 1.2) when new releases come out. Because the products auto update in Central we do not show version numbers in the console. But I understand the issue with making sure you have SVE 1.2. 

2. Let people know limitations of "updating" SSVM 1.1 to SSVM 1.2 openly. 

>This was in some of the KBAs - but may have needed to be clearer (and if removed then i apologies, not sure why that was) 

3. Plan and give better error messages...like for the error u'apis' (when you use a 2FA account to install SSVM 1.2)

We are planning to improve the error messages when installer fails and also how to rectify them. 
MFA will be fixed in the next version.

I think I cannot even find the version of the GVM and or SSVM via sophos central or any version history (if it was installed 1.1 then updated to 1.2 or 1.2 installed).

You can run the following command on the SVM: cat /etc/release

I have spoken to the engineers and I will log the request on your behalf to add the version info to the SVM details page in Central. 

thanks Adrian. 

1. Then what is the use of having sophos central ?

2. Does the command line tell the user if the SSVM 1.2 was a "SSVM 1.2 installed" or "SSVM 1.1 update to sSVM 1.2 " ?

I had a "fun" time adding SSVM IPs during the SSVM 1.1 update to SSVM 1.2 saga by modifying a IP text file of the SSVM console....only to find out SSVM 1.1 update to sSVM 1.2 does not work for the fail over functions (I wasted 1 week testing the fail over functions, Sophos support suggested restarting SSVM, GVMs and even rebooting ESXi).

SVE 1.2 was against the usual grain of our products auto updating from Central because of the certification authority we had to implement for Guest VM migration. From version 1.2 onwards the product will keep it updated automatically, so when 1.3 arrives the product will update itself. 

The command line doesn't say what version was previously installed, again after you install 1.2 all the updates will be automatic so it will always be up to date. 

The next may bot be directly related to SSVM 1.2 but this was what I found during the post SSVM & GVM 1.2 tests....

1. There are no individual VMs "scan now".....in case there are some suspected abnormalities for certain VM and you do not want to scan the whole lot of VMs linked to the SSVM.

2. There are no file type scan options for VMs.

3. Eicar test....

I performed tests using the eicar test files...I only managed to successfully test a few....I have to wait a few hours as there are a few VMs linked to the SSVM and I cannot run a "test scan" (all policy settings are enabled).

i. View Eicar "script" on browser.....Sophos blocked the browser (test successful)

ii. Download Eicar "batch file" via browser downloads (download successful, test failed)

iii. Download Eicar "txt file" via browser downloads (download successful, test failed)

iv. Copy Eicar batch file "eicar.bat" to VM "c:\temp" from a "unprotected" PC (copy successful, test failed)

v. Copy Eicar txt file "eicar.txt file" to VM "c:\temp\" from a "unprotected" PC (copy successful, test failed)

vi. Rename Eicar "eicar.txt file" in VM "c:\temp" to eicar.bat file (rename successful, test failed)

vii. Execute eicar,bat (execute successful, test failed)

Test failed means the AV or protection did not work as expected.