9.204-19 possible bug relating to Office 365 traffic

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'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.

@William

your solution will only work for transparent proxy mode or tell me how to do that for standard proxy mode... As far as I know the execption list is only for transparent proxy...

If you have standard proxy and Office 2013 click 2 run versions you'll run into this issue

regards

@William

your solution will only work for transparent proxy mode or tell me how to do that for standard proxy mode... As far as I know the execption list is only for transparent proxy...

If you have standard proxy and Office 2013 click 2 run versions you'll run into this issue

regards

so few foiks have run standard i forgot to ask about that..[[:)]]  Then make an exception with every box checked...[[:)]]