Updates failing for two servers utilizing the new Early Access program for Intercept X.

Hello,

Can you confirm that by local location you mean Update Cache?

Also could you check that other non-EAP machines are updating successfully? If your EAP machines are still on the EAP, the machines should be updating every hour. Have there been any subsequent successful updates?

Thanks

Nathan

Correct.  

All my other machines are updating just fine, it's only the two servers in the EAP program.  I've tried doing manual updates and they fail as well.  I just wasn't sure if the Update Cache downloads the EAP updates and that's why both servers are failing.

Update Cache should support the EAP transition. Could you collect some SDU logs and send them to us? I am sending you a private message now.

Thanks

Nathan

Hello,

Could you look at the autoupdate logs from one of the two EAP servers? The logs should be here: C:\ProgramData\Sophos\AutoUpdate\Logs\sophosupdate.log 

It might be easiest to rename the current log file:

C:\ProgramData\Sophos\AutoUpdate\Logs\sophosupdate.log

Then initiate an update to generate a new log just containing the last update and post the results here.

Regards,

Stephen

I'm unable to rename the log file.  I just sent in the SDU logs from both servers having issues.

I'm unable to rename the log file.  I just sent in the SDU logs from both servers having issues.

Thanks for the logs. A quick look suggests corruption in one of the downloads.

Please can you advise if there is a firewall, either between the client and the update cache, and/or the update cache and the internet?

Regards,

Stephen

There's the Windows firewall on the client machine and update cache.  From Update Cache to the Internet it would go through our Sophos UTM.

When going to https://FQDN:8191 I do get the self-signed certificate error, but when advancing it says "HTTP Error 404.  The requested resource is not found."

Also, this was in the log on the Update Cache machine:

[2018-06-29T21:11:50Z] [36e4] Error: [HTTPServer::HttpReceiveRequestCompletion::CompleteOperation:494] Error opening mbsutil01.morrison.local:8191/.../12f278a50356ace6580c8aeb20dc0b09915fd8106f5239cb65389e2b8820af5e.dat: Could not open file: [3] The system cannot find the path specified.

Hello,

It looks like the firewall is blocking the download of that file, when the manifest.dat is checked validation is failing as we do not have all of the files expected. if you manually try to download that file, you might see an error. 

I don't know enough about our UTM product, but I think there is an option for file caching, or something similar that we need to suppress in order to resolve this issue. 

I'll see if I can find out what we need to do to resolve this. 

In the meantime, if you are able to download that file you could copy it to these two servers to pass the validation. 

Stephen