Thanks for the information!
I wonder what it is about the MS apps that are causing the issue? Maybe something to do with their encryption methodology? I think you mentioned occational problems connecting to secure sites via "https" but I haven't noticed that - at least not yet...
Hopefully they get this sorted out because it is extremely frustrating. In the meantime, thanks again for your help!
The problem is that everything is moving to the 'cloud'. Office365 is a subscription requiring you to log in and out to the 'service'. This is true even if their OneDrive isn't even being used... they track literally everything. I've seldom had a problem logging in, but the logoff procedure, which likely includes a lot more tracking data, is what seems to not get acked. So the apps hang as it waits for something or ultimately times out. More often than not I just kill the app, which sets off their error reporter, which will also hang until I kill it. Not a fun process.
I hear you! The satellite latency makes every Office365 operation a "cliff-hanger." I have the same issues as you on closing and also occasionally when opening an office app. If an office app hangs on opening, it's a two step process to kill it - first kill the splash-screen and then kill whatever is left in task manager.
My problem is I live and die by being able to work from both my home and work offices. VPN is hopeless so the "cloud" is the only file-sharing solution.
Unfortunately, I have now been forced to spend a lot more time in my work office!
You may find this interesting!
As expected, my desktop outlook app disconnected at 9AM today (right on time!). As I mentioned earlier, when my local outlook disconnects, I am also unable to connet to the web-based outlook at outlook.live.com/owa.
Based on your trace route suggestion, I tried to trace the route to outlook.live.com. What i found (see below) is very interesting (at least I think it is). From the several traces I tried, it looks like the packet never makes it out of the CenturyLink servers, stopping every time at IP address 67.132.132.134 which, according to whois, is a CenturyLink address in Seattle.
I would love to hear your thoughts!
Tracing route to l-0002.l-msedge.net [13.107.42.11]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.42.1
2 1 ms <1 ms <1 ms 192.168.40.1
3 1 ms <1 ms <1 ms 100.71.75.1
4 610 ms 557 ms 605 ms host17433001211.direcway.com [174.33.211.1]
5 598 ms 588 ms 607 ms host17433005213.direcway.com [174.33.213.5]
6 614 ms 613 ms 540 ms host17433004213.direcway.com [174.33.213.4]
7 604 ms 597 ms 616 ms tuk-edge-14.inet.qwest.net [65.153.170.53]
8 604 ms 627 ms 617 ms sea-edge-12.inet.qwest.net [67.14.41.58]
9 610 ms 577 ms 558 ms 67.132.132.134
10 * * * Request timed out.
11 * * ^C
And here is more interesting stuff. When outlook goes down on my PC, so does my onedrive connection. So I tried two traces below, the first to OneDrive.com which is just the basic microsoft landing page for onedrive information; the second to OneDrive.live.com which is the website for connecting to my web-based onedrive account. The packet makes it to the onedrive website, but fails (at the same address as outlook.live.com) to make it to onedrive.live.com.
Tracing route to onedrive.com [23.204.50.96]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.42.1
2 1 ms <1 ms <1 ms 192.168.40.1
3 1 ms 1 ms <1 ms 100.71.75.1
4 555 ms 607 ms 608 ms host17433001211.direcway.com [174.33.211.1]
5 608 ms 607 ms 627 ms host17433005213.direcway.com [174.33.213.5]
6 578 ms 607 ms 637 ms host174330033213.direcway.com [174.33.213.33]
7 606 ms 558 ms 577 ms tuk-edge-14.inet.qwest.net [65.153.170.53]
8 642 ms 628 ms 604 ms sea-edge-15.inet.qwest.net [67.14.41.162]
9 650 ms 657 ms 677 ms 63-233-86-42.dia.static.qwest.net [63.233.86.42]
10 602 ms 638 ms 597 ms ae2.sabey-sea2.netarch.akamai.com [23.203.145.149]
11 602 ms 597 ms 597 ms a23-204-50-96.deploy.static.akamaitechnologies.com [23.204.50.96]
Trace complete.
C:\Users\sjohn>tracert onedrive.live.com
Tracing route to l-0004.l-msedge.net [13.107.42.13]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.42.1
2 1 ms <1 ms <1 ms 192.168.40.1
3 1 ms 1 ms <1 ms 100.71.75.1
4 601 ms 618 ms 582 ms host17433001211.direcway.com [174.33.211.1]
5 609 ms 557 ms 587 ms host17433005213.direcway.com [174.33.213.5]
6 599 ms 637 ms 579 ms host174330033213.direcway.com [174.33.213.33]
7 619 ms 607 ms 604 ms tuk-edge-14.inet.qwest.net [65.153.170.53]
8 615 ms 637 ms 637 ms sea-edge-12.inet.qwest.net [67.14.41.58]
9 607 ms 577 ms 637 ms 67.132.132.134
10 * * * Request timed out.
11 * ^C
All I got to say is good luck if the problem is with CenturyLink. I doubt even HughesNet has much clout with them, as evidenced by how long this has been going on.
Might actually have better luck getting MS to jump in. But again, good luck!
My theory is there's a long delay somewhere upstream in the path: The thing in common is the CenturyLink backbone. I've seen it in file downloads as well, where there's an initial burst, then about a one minute delay until it picks up again normally. That one minute delay is likely what's causing things to hang.
Pretty sure there are ICMP blocks in Microsoft's network preventing the traceroutes from completing correctly. So, I wouldn't worry too much about that part of it.
@BirdDog wrote:All I got to say is good luck if the problem is with CenturyLink. I doubt even HughesNet has much clout with them, as evidenced by how long this has been going on.
Might actually have better luck getting MS to jump in. But again, good luck!
Agreed. The best HN can do is poke them in the eye and hope they react. The choices for capable backbone providers to each gateway is getting narrower and narrower as CL gobbles them all up. So recontracting with another upstream provider isn't really an option for them.
Bummer... :-(
The Cloud.... it's evil.