Updating SUMInstallSet to 1.7.0

Hello Christian,

how did you manually update SUM?

I'd have to check tomorrow, not unlikely that SUMInstallSet is static, i.e. created during the initial install or SEC upgrade and never updated. I'd thought that any supported SUM version should be able to update itself. Older versions definitely do not support HTTPS. Your source is a published SophosUpdate share?

Christian

Hello Christian,

QC said:

how did you manually update SUM?

I just try to understand the selfupdate process by reading the SUMSelfUpdaterLog.

• The Source of the Update is "C:\ProgramData\Sophos\Update Manager\Working\Decoded-SDDM\A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1\"
  • on a affected SUM its outdated or not present, so I used the directory from the central SUM
• every Update starts with "SUM Self-Updater" followed by the info of using "C:\Program Files (x86)\Sophos\Update Manager\.\SUM_Status.xml" --> so the SUMSelfUpdater.exe followed by the ".\SUM_Status.xml" should start the update.
  • And that's it! (SUMSelfUpdater.exe "C:\Program Files (x86)\Sophos\Update Manager\SUM_Status.xml")

QC said:

Your source is a published SophosUpdate share?

Our central SUM is published via SMB, HTTP and HTTPS.
After updating the central SUM, the update of newly installed child SUMs only works with SMB. HTTP and HTTPS are not working anymore. After updating via SMB, HTTP or HTTPS can be added as a source without the above error.

Christian

Hello Christian,

I just try to understand the selfupdate process
clever.

published via SMB, HTTP and HTTPS
I assume you also have endpoints updating from this share via HTTP, haven't you? SUM 1.6.1 (that's the version in SUMInstallSet, you're right, it's static) is able to update via HTTP and the only explanation I could come up with is that only HTTPS is available - but then endpoints wouldn't be able to use the HTTPS CID. Failed to read customer file content is an "early" error normally indicating a connection issue - this I'd rule out a 1.6.1/1.7.0 version (Warehouse structure) incompatibility.

a 1.7.0 SUM that provides updates over HTTP / HTTPS
to be exact, SUM does not provide updates. The OS publishes the share, SUM isn't actually aware how it is done. Additional software (IIS or some other web server) is required to publish via HTTP(S) - SUM neither knows nor cares if and how this is done. 

Christian

QC said:

I assume you also have endpoints updating from this share via HTTP, haven't you?

We do not have clients updating via the central SUM using HTTP / HTTPS.

You're right, before the SUM was updated to 1.7.0, the Sophos updates were released using SMB (OS Share) and HTTP (IIS). After updating to 1.7.0, there were errors in the event log for SUMs that had an HTTP SUM source. Version 1.7.0 always tries to access the source via HTTPS.
To work around this error message, we have additionally released the IIS web page with HTTPS and added it as the primary source.

If I understand correctly, it is not possible to update new SUMs since the update to 1.7.0, which should and can only update via HTTP. Unless I use the unsupported manual update path.

Christian

Hello Christian,

so IIS publishes the page only with HTTPS but not HTTP?

1.7.0 always tries to access the source via HTTPS but falls back to HTTP in case the connection fails. Thus there is no need to use HTTPS in IIS (unless you have a specific requirement). If you publish the CID with both HTTP and HTTPS then 1.6.x will be able to update and 1.7.x won't show the errors in the log.

BTW: The article says you can force HTTPS by setting the ConnectionMode value to 2. By default it is 0 so I tried with 1 and it seems SUM skips the attempt with HTTPS.

Christian

Hello Christian,

our central SUM is published via HTTP and HTTPS.

It makes no difference if we use HTTP or HTTPS, the error message is the same. I think it's because of the "(warehouse structure) incompatibility".
However, it is possible to automatically update using SMB. Then you can switch to HTTP or HTTPS!

QC said:

BTW: The article says you can force HTTPS by setting the ConnectionMode value to 2. By default it is 0 so I tried with 1 and it seems SUM skips the attempt with HTTPS.

Thank you for the information.

Unfortunately, it does not help with our problem because it's a general problem with web-based access. It makes no difference whether the access is performed using HTTP or HTTPS. If the source is 1.7.0, a new 1.6.0 can no longer automatically update via web.

Christian

Hello Christian,

an incompatibility would also affect updating over SMB, furthermore it fails "very early" when trying to download sumcf.dat.
Wouldn't this have affected most child SUMs that update from a HTTP source? I'm still leaning towards the simple explanation that the source isn't actually available over HTTP. Wonder if an 1.7.x forced to use only HTTP would be able to update or not.

Christian

Hello Christian,

an incompatibility would also affect updating over SMB, furthermore it fails "very early" when trying to download sumcf.dat.
Wouldn't this have affected most child SUMs that update from a HTTP source? I'm still leaning towards the simple explanation that the source isn't actually available over HTTP. Wonder if an 1.7.x forced to use only HTTP would be able to update or not.

Christian

Hello Christian,

now it works as it should. If you use the right source and not a combination of https: // and HTTP port number it works as expected. [*-)]

Thank you for your patience.

Christian

Hello Christian,

fine. Given the symptoms I was quite sure it had nothing to do with the version.

Per the standard no meaning (i.e. a specific protocol) is assigned to a port, not even a well-known, though there is a default port for the protocol.
Up to 1.6.x (haven't tested how 1.7+ behaves in this respect) HTTP and HTTPS were treated as synonyms (and SEC allowed both). In fact if I enter my source as HTTPS (it's only published via HTTP) in the console's SUM configuration the check nevertheless succeeds.

Christian