9.204-19 possible bug relating to Office 365 traffic

office365 does have local components if you have installed the office suite that comes with it.  What is happening is probably updates to your installed clients.  It is not like windows updates but uses the "vaunted" click-to-run virtualization technology.  I bet these are updates related to new updates/features released for Office365.

Yes but my average over a year is 1-2 Mbit. This produces sustained traffic of up to 100Mbit/s until I block it or throttle it. I have less than 5 seats on the LAN side with Office 365. They cannot possibly need 1TB worth of updates. Something is up with this.

I have updated to 9.204 on all 3 of our sites and not seeing this, but we are running click to run from a local share...

I have updated to 9.204 on all 3 of our sites and not seeing this, but we are running click to run from a local share...

click to run on a local share does NOT give you the updates..they are still pulled form MIcrosoft's servers..[:)]

Yes but my average over a year is 1-2 Mbit. This produces sustained traffic of up to 100Mbit/s until I block it or throttle it. I have less than 5 seats on the LAN side with Office 365. They cannot possibly need 1TB worth of updates. Something is up with this.

I would put the two ip ranges into the exceptions or the bypass list..maybe they are getting hung up by the a/v engines.

Good insight, William.  Hi, benzene, and welcome to the User BB!

Let that traffic flow and look at the Web Filtering Live Log as well as the others listed in #1 in Rulz.  Any clues?

Also, check what traffic with those IPs is occurring on the 'Bandwidth Usage' tab of 'Logging & Reporting'.

Cheers - Bob

Hi

We are having the same problems with the application Ms Office 365 "eating" all the bandwith available.  With Ms Office 365 "unlock" = 985 Mbs, when "lock" = 50 Mbs

Any ideas ????

Thank you

I'm gonna bump this ancient thread because it was never really answered and I recently pulled my hair out with this myself with Office 2013 Retail which uses the same update mechanism. It was absolutely crushing our bandwidth. I tried all of the suggestions out there to snip this (turning off check for updates, renaming the application responsible for updates, etc...). I was seeing traffic from this application in the neighborhood of 60 GIGABYTES per day! Different workstations at random would just go nuts, sometimes just a single one, sometimes 2 or 3. No pattern of time or day. To compound matters this updater uses multiple IP addresses.

I finally isolated that there was just one of the many Microsoft IP addresses it was contacting that was consuming all of the bandwidth. The IP resolves to one of their farms in Australia. I didn't want to snip it at the UTM because it was even pounding our LAN traffic just trying to get out. Instead I pushed out a firewall rule in SEP Management console down to every workstation so it is dropped before it can even leave each box.

The even weirder thing is once I snipped this and regained control of our bandwidth, each of the Office suites began functioning correctly and merrily on getting their true "small" differential updates.

My understanding from researching this is that this is a "feature" of Office 2013 retail and the much more expensive enterprise license version doesn't have this bandwidth sucking "feature". How nice.

This is the IP address I snipped at each station:  70.37.81.47

Hope this helps someone else.

I can confirm this "Bug". It seems the Web Protection (Proxy) can't handle the returning traffic pakets from Microsoft (for Office Updates). The Updates were initiated by Clients but the returning pakets drop at the external interface. As workaround a proxy execption (e.g. inside the .pac-file or inside the ie webbroswer) for the MS Update Servers (DNS: officecdn.microsoft.com) and an additional firewallrule that allows http- Traffic from internal network to officecdn.microsoft.com should solve this.

regards

I can confirm this "Bug". It seems the Web Protection (Proxy) can't handle the returning traffic pakets from Microsoft (for Office Updates). The Updates were initiated by Clients but the returning pakets drop at the external interface. As workaround a proxy execption (e.g. inside the .pac-file or inside the ie webbroswer) for the MS Update Servers (DNS: officecdn.microsoft.com) and an additional firewallrule that allows http- Traffic from internal network to officecdn.microsoft.com should solve this.

regards

this isn't a proxy issue per se.  there's no need for the firewall rule as what you are doing is redundnat to my solution.  Put the dns host you found into the proxy bypass(not the exceptions) and let it go.  The issue is usually at the server end in that it doesn't like it's traffic being scanned.