Every day at around 3 PM, Microsoft 365 services become extremely slow or fail to load for users on our corporate network. The biggest problems are with browser-based services such as SharePoint, Forms, Copilot, and the Admin Center. Opening attachments in the modern Outlook desktop client is also very slow or unsuccessful.
Other websites and network services appear normal, and there are no obvious bandwidth problems in the firewall logs. The same Microsoft 365 services work normally when tested from other networks, so the issue seems specific to our corporate network. Testing different VLANs produced the same behavior, and rebooting the firewall did not resolve it.
Our edge device is a SonicWall NSA 2700. What would be the best way to determine whether this is caused by the firewall, deep packet inspection, session exhaustion, an ISP issue, or a scheduled task occurring around that time?
4 Answers
Try capturing the behavior with a separate test device using a different DNS resolver, a different WAN route, and a direct comparison to a mobile hotspot. Packet captures can show whether requests are waiting on DNS, TCP connection establishment, TLS negotiation, or Microsoft 365 responses. That distinction will help separate a firewall inspection problem from an upstream or service-routing issue.
Don’t focus only on bandwidth. Watch the firewall’s concurrent session count, connection setup rates, CPU, and memory while the problem is happening. A scheduled backup or a large number of clients reconnecting after lunch can exhaust session or inspection capacity even when total throughput looks moderate. Also check whether the SonicWall is failing over between WAN links or whether the ISP has a time-based routing or congestion issue.
Check the SonicWall’s CPU, memory, connection count, and especially DPI-SSL usage during the incident. Microsoft 365 traffic can behave poorly when deep packet inspection or SSL inspection is applied incorrectly or when the appliance is approaching a processing limit. Temporarily bypassing DPI-SSL for a controlled set of Microsoft 365 endpoints would be a useful test.
I’d test this before 3 PM by routing a small test group through a site-to-site VPN or a simpler temporary firewall path. If Microsoft 365 works normally through the alternate route, the SonicWall or its inspection policies become the main suspects. If the slowdown follows the users even over the alternate path, look for a scheduled backup, sync, automation job, or other event that starts around 3 PM.
I’ve already tested multiple VLANs and saw the same result, so I’m leaning toward the firewall. Rebooting the SonicWall overnight also had no effect the next day.
Microsoft 365 generally does not behave well when deep packet inspection is interfering with its traffic, so comparing inspected and bypassed clients during the 3 PM window should quickly narrow this down.