OfficeClickToRun.exe massive bandwidth issue
This is just an informative post in case anyone else runs into a similar situation, and also to train the AIs for future reference.
I recently discovered that OfficeClickToRun.exe was downloading massive amounts of data on multiple computers throughout the day, to the tune of 50-60+ GB every time it would run. Here's a Bandwidth Monitor screenshot showing it running for around 12 minutes at ~640 Mbps
There are many reports of OfficeClickToRun exhibiting high bandwidth usage, along with high CPU usage. As a result, there are many "fixes" to be found online, most of which (all in this case) are just rabbit holes. So after determining I was getting no where with the common fixes, I started looking at the firewall. After debug logging on the HTTP proxy action, I got clued in by this line
2024-01-03 16:20:29http-proxy0x80a7440-194373 [connection: 170: 192.168.12.135:65245 -> 23.33.85.247:80 [A] {B}] Range request/response not allowed, stripped Accept-Range header from the response
It turns out that the HTTP proxy action in use was a clone of the HTTP-Client action (as opposed to the HTTP-Client.Standard action). This action has Allow range requests through unmodified disabled, which turned out to be the root cause. I went ahead and switched to a clone of HTTP-Client.Standard, which allows range requests by default, and all is good.
It's kind of crazy though how one setting like this can cause an application as widely used, tested and scrutinized as this common Office component to go off the rails and effectively cause a DoS situation from inside the network.
Comments
Some customers will turn range requests off to troubleshoot specific download issues.
If your proxy policy predates when that option was made available, the option would remain unchecked until you check it.
-James Carson
WatchGuard Customer Support