Office 365 updates failing

Hi Edward,

the normal process for digging into this may require live monitoring.. if you export the logs to a syslog server you should be able to see every request.. the fields you care about ar rsn act= a full description of the log can be found here: swa.sophos.com/.../InterpretingLogFiles.html

generally tho,

double check your authentication and deployment policy against my kbs :

https://community.sophos.com/kb/en-us/126692

https://community.sophos.com/kb/en-us/126599

if your in explicit proxy .. make sure  you do you have the check box "authenticate every request" enabled.

in general there should be no reason ms products wont work, i have seen all sorts or weird stuff like ms back end servers with 0 ssl certs or applications making requests to dead links..

if your still having issues, open a support case when you have time to live monitor.

Hi again, I'm posting this just in case anyone else runs into the problem with 364 updates and Proxy settings.

After lots of faffing about, hair pulling, swearing, network traffic analyzing and coffee drinking - I seem to have it working. So far, tested successful on two machines and working as expected.

I think what actually appears to be happening is that certain parts of the office 365 updater DO NOT use the current user to work, instead relying on localsystem user.  The issue with this is - the localsystem user does not understand the proxy settings we put in to IE - so when it tries to run that part - its not that Sophos is somehow blocking it. It's actually not even hitting sophos for this bit of the update. As such running the following command issues the proxy settings to the localsystem user and voila - after that it worked straight away. Obviously - edit this per your own requirements.

bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxy.company.com:3128 "<local>*.company.com; 172.19.*; 172.20.*;"

Hopefully this may help anyone else having a mare with it like i have been!

Thanks again Red_Warrior!

Hi again, I'm posting this just in case anyone else runs into the problem with 364 updates and Proxy settings.

After lots of faffing about, hair pulling, swearing, network traffic analyzing and coffee drinking - I seem to have it working. So far, tested successful on two machines and working as expected.

I think what actually appears to be happening is that certain parts of the office 365 updater DO NOT use the current user to work, instead relying on localsystem user.  The issue with this is - the localsystem user does not understand the proxy settings we put in to IE - so when it tries to run that part - its not that Sophos is somehow blocking it. It's actually not even hitting sophos for this bit of the update. As such running the following command issues the proxy settings to the localsystem user and voila - after that it worked straight away. Obviously - edit this per your own requirements.

bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxy.company.com:3128 "<local>*.company.com; 172.19.*; 172.20.*;"

Hopefully this may help anyone else having a mare with it like i have been!

Thanks again Red_Warrior!

The newer update mechanisms of Windows and Office mostly rely on the netsh proxy settings and ignore user-settings completely which is OK as many users aren't allowed to install any updates on their own anyway.

If this outgoing traffic on the gateway isn't allowed by firewall- / masquerading/NAT-policies (nearly in most cases where you use a dedicated proxy) you have a problem with those connections if you don't set the netsh proxy explicitly. If the web appliance has comparable rules like a UTM I would recommend allowing web traffic from user agents "OfficeClickToRun" and "Microsoft-Delivery-Optimization/10.0" without authentication, too.

Hey glad to help,

sounds like whats going on is perhaps not so much running as another user, but more like its trying to authenticate (or communicate) on a port other that 80 or 443.  if this is the case the appliance would not answer and the request would time out.

adding the proxy exclusion is a good option as well.. It also helps in similar cases where outlook trys to look up auto discovery addresses for the email box and fails.  (the most common fix is to black hole the auto-discover address to 127.0.0.1 forcing outlook to check locally) 

another thing you could try .. is look in the logs un UA= .. (user agent)  .. then under authentication create an authentication profile.. under the user agent string select custom.. then add the first part of the agent..  once thats done go into the second tab under the auth menu and make a profile using the exception and set it to not use authentication (enter the ms domains)  and that will allow an un authenticated request with the update tool only, to that specific site.. 

cheers