Stop Blaming M365—Your Network Is the Culprit

I used to think tweaking M365 settings was the answer to every
slow Teams call—until I watched our network diagrams and
realized: that culprit isn’t in Redmond, it’s lurking in my own
firewall.If you’ve patched, optimized, and toggled every policy
but users still complain, it’s time for a behind-the-scenes look
at what really drives cloud performance—your physical and virtual
network. Ready to find the real bottleneck?


Why the Blame Is Misplaced: Unmasking the Real Bottleneck


If you manage M365 in just about any organization, you know the
drill: Monday morning and the help desk lines start lighting up.
“Teams kept dropping my call.” “SharePoint took ages to open that
document.” “Is Microsoft down again?” It’s almost a ritual—users
send those tickets, admins scramble to check the health
dashboard, Exchange barely blips and everything looks green. So,
naturally, the next step is tweaking every policy you can think
of. Maybe shave down those retention rules, tinker with
conditional access, check for old add-ins, even reboot half your
servers just in case. And after all that? Your users swear it’s
still taking ten seconds to open PowerPoint files. It’s enough to
make you start doubting the whole M365 stack.Here's where it gets
interesting—because the real problem usually kicks in long before
your data even hits those Microsoft servers. It’s a tough pill to
swallow. We’ve all pointed the finger at M365 itself when
performance crawls, but the data rarely lines up with that story.
Microsoft’s entire cloud architecture is built for scale. Their
core services are redundant across regions, sitting behind walls
of global CDNs, and have enterprise-grade failovers. The boring
truth is, Microsoft’s backbone is almost never the problem. Most
of that lag people complain about doesn’t trace back to Redmond
at all—it gets lost somewhere inside your own network rack, miles
from any Azure data center. There’s a reason IT pros keep looping
back on the same issues. Picture a Teams meeting going off the
rails: voices start cutting in and out, screen shares look like
PowerPoint from 1999, and someone asks in the chat, “Is Microsoft
having problems?” You run your checks. Microsoft 365 service
health: green. Your infrastructure: patrolled by more monitoring
dashboards than anyone knows what to do with. Still, the call
lags, and everyone’s sure Microsoft is at fault. Except, the real
culprit is probably closer than anyone suspects. More often than
not, the data never even gets a clean shot at the cloud—because
it’s busy tripping over a badly-configured local gateway,
overworked proxy, or a well-meaning firewall rule that’s years
out of date.Let’s throw in some real-world perspective. There’s a
healthcare company that spent months battling user complaints
about slow SharePoint syncs and flaky Teams meetings. New laptops
didn’t help, nor did swapping out Wi-Fi gear or rolling out even
more monitoring tools. The breakthrough came from a random
network admin who traced the M365 traffic logs straight to a
single firewall rule—a leftover setting forcing every bit of
Microsoft cloud data through four layers of packet inspection and
deep scanning. One simple change: allow trusted M365 endpoints to
pass through with minimal inspection. By the next morning, not
only was SharePoint flying, but even Microsoft Teams calls felt
smoother than anyone remembered. All without raising a single
Microsoft support case.That’s not a one-off scenario. Microsoft’s
own telemetry shows the vast majority of performance issues arise
before their infrastructure even gets involved. One long-running
analysis of M365 network incidents flagged just how often the
“problem” is really a homegrown policy, a routing misfire, or an
aging VPN configuration that survived three IT directors. The
official guidance is blunt: prioritize local egress for M365
traffic, and avoid “hairpinning” your data back to the mother
ship if you want reliable performance. Cloud architects have been
repeating it for years—but inside the average organization,
legacy controls and old behaviors keep slowing everyone down.Some
of the research from Microsoft’s global cloud networking group
puts it plainly: users see the best performance when traffic
travels the shortest possible route—straight from the client, out
the nearest egress point, and directly to Microsoft’s backbone.
Anything else creates hops, delays, and unnecessary points of
failure. If your security stack or proxy inserts extra
authentication challenges or tries to decrypt every packet,
expect Teams and SharePoint to protest in slow motion. Tracing
these bottlenecks isn’t just an exercise in blaming the firewall;
it’s usually the low-hanging fruit that IT teams overlook because
they’re sure “the network is locked down and fine.”These
invisible tripwires cause daily chaos. The kicker is that so many
organizations treat M365 like an on-premises workload, locking it
behind the same choke points they built for the 2010 era.
Meanwhile, Microsoft has engineered their stack for direct,
modern internet connectivity—hoping you’ll trust their perimeter
as much as your own. The result? Endless cycles of
troubleshooting, where admins try every M365 tweak in the book
but miss the obvious: until you fix the network path, you’re just
applying bandages.So, if every support call and monitoring
dashboard still points at the cloud, it’s time to look closer to
home. Ignore these network tweaks, and you’ll waste time chasing
digital ghosts. Catch them early, and you’ll see the kind of
overnight improvement that takes user complaints from a daily
occurrence to an occasional memory. The logical question now:
what are the specific network mistakes that keep tripping
everyone up? That’s where things get revealing.


Three Routing Mistakes That Ruin Cloud Performance


It’s easy to look at your network diagrams and see clean
lines—all those labeled firewalls, the tidy proxies, the
connections you drew with a few clicks in Visio. But the truth
is, many IT teams don’t actually watch what their own
infrastructure does to M365 traffic once it leaves a user’s
device. If you haven’t scrutinized your actual packet flow
lately, you might assume things are fine. “The firewall’s doing
its job, the proxy’s humming along, and we’ve run the same setup
for years.” That kind of autopilot confidence is usually the
first warning sign. Because baked deep into most environments are
a few destined-to-slow-down-M365 mistakes that everyone assumes
keep them safer or make management easier.Let’s start with the
most classic offender. The central firewall or proxy choke point.
You know the model: every packet—including Teams calls,
SharePoint syncs, and file uploads—makes a round trip to HQ or
some overloaded regional hub before it ever meets the open
internet. It sounds secure—one place to control and monitor
everything. It also sounds manageable, because centralized rules
are easier to audit. But the impact on Microsoft 365 is a bit
like forcing all traffic to stop at a tollbooth in rush hour. You
see bottlenecks, stacking latency as your packets line up to be
inspected and scanned. Microsoft engineered their endpoints and
protocols for quick, direct routing—it’s built for a cloud-native
world, not for shoehorning through aging gateways. Suddenly,
users are asking why a Teams meeting with a colleague across town
feels like it’s bouncing off the moon. The second routing mistake
is a close relative: not allowing direct internet access for
those critical Microsoft endpoints. On paper, blocking outbound
connections unless they pass through corporate inspection makes
sense. Security teams sleep better knowing every request is
logged, even if it’s just PowerPoint phoning home. But M365
doesn’t play well with middlemen that don’t speak its language.
You end up with unpredictable delays, broken authentication
handshakes, or the classic “Your connection is not secure” error
that sends users running to unplug their Ethernet cables.
Microsoft even publishes a living list of endpoints that should
bypass security inspection entirely—they have their own layers of
defense and require that split traffic to hit performance
targets. Ignore this, and you hear about it every time someone’s
SharePoint library takes forever to load or Exchange Online times
out mid-search.Now, for the VPN misadventure. Routing all
Microsoft 365 traffic down the same slow, encrypted tunnels you
use for sensitive apps like SAP or Oracle isn’t keeping you
safer—it’s just piling on headaches. In theory, all your traffic
“comes from” the office, so conditional access matches up and
legacy network controls stay relevant. But most VPN concentrators
weren’t designed for constant cloud back-and-forth, especially
not the multimedia payload from Teams or the file churn of
OneDrive. If all of your branch offices and remote workers are
forced to “hairpin” their traffic—sending it from their laptop,
back to HQ, then to Microsoft and all the way back again—the
result is a slow march of jittery calls, choppy video, and chat
messages that arrive out of order. It’s the kind of network path
that looks technically correct but feels objectively painful in
real-world use.One example that’s hard to ignore: a retail chain
with dozens of locations, each with its own internet circuit, yet
somebody in IT wanted all Teams and OneDrive data to “look like”
it was always coming from headquarters. So every single Teams
call, even ones between two cashiers in the same store, had to
loop across the country and back just to cross the street. That
bit of “safety-through-centralization” meant their video calls
crawled, screen shares timed out, and managers gave up on
anything more complicated than a chat. Users were convinced
Microsoft 365 was allergic to Mondays. The reality? A simple
split tunnel configuration, letting Teams and other trusted M365
endpoints bypass the slow lane, restored their performance
overnight without touching a single app setting.This is where
Microsoft’s own documentation gets direct. Their advice is to
“enable direct Microsoft 365 connectivity at each office location
with local egress of internet traffic.” Split tunneling isn’t a
security compromise—done properly, it means productivity apps get
fast, reliable connections, while your true crown-jewel systems
stay behind the VPN. But here’s what holds people back: the
nervousness that direct egress opens new gaps, or that they lose
visibility over what’s happening on the wire. It’s a classic
risk-versus-reward standoff.What stands out, looking through
these repeated mistakes? Once you remove the bottleneck—by
letting trusted Microsoft 365 flows avoid excessive scanning,
zig-zag routing, or deep inspection—performance jumps up,
sometimes dramatically. You get fewer support tickets, happier
users, and none of the old tradeoffs you thought were
non-negotiable. Most of the time, this is an instant win: no M365
settings to tweak, no advanced troubleshooting, just basics done
right.But here’s the nagging question: how do you figure out
which hurdle is dragging you down in the first place? Users just
know their apps are slow—they don’t tell you if it’s the proxy,
the firewall, or that old VPN appliance limping along in the
server closet. So what’s the trick to catching the real culprit
before the next Teams meltdown?


Diagnosing the Culprit: Is Your Security Stack Slowing You Down?


Ever had that moment where OneDrive syncs a hundred files in no
time, but a Teams call next door lags and drops? That’s the
flavor of confusion a modern security stack can serve up,
especially as organizations mix and match proxies, firewalls, and
VPNs. Everyone wants tight security—inspect every packet, block
threats at every turn. But in the real world, making every cloud
app run through the same gauntlet rarely leads to either
top-notch security or happy end users. The idea that locking down
every bit of traffic the exact same way will protect everything
and keep it running smooth is one of those comforting myths that
doesn’t survive close scrutiny.Let’s look at how the different
chunks of your security stack play favorites when it comes to
M365. Say you have a proxy that forces all traffic through SSL
inspection. For Exchange and SharePoint, sometimes things limp
along, but then Teams turns into a slideshow the second someone
shares a screen. Why? Teams and other real-time services push a
lot of traffic types—UDP for media, different protocols for chat
and files—and most proxies just aren’t built to handle that level
of complexity on the fly. When everything gets decrypted,
inspected, and pieced back together, latency finds its way in and
the wheels come off. Some tools handle bulky uploads well but
choke on persistent connections. Others give a pass to
low-priority endpoints but hammer the critical ones that make
calls and meetings work.It gets even more interesting when
firewalls get into the mix. Modern firewalls love deep packet
inspection. That’s great—right up until they try to parse
Microsoft’s constantly updated list of service URLs and IPs.
They’re built for stable on-prem environments and get nervous
whenever Microsoft decides to add a new CDN or change an API
domain. Suddenly, random Teams workloads grind to a halt, while
OneDrive chatters away happily in the background, because its
sync traffic slipped through an open port the firewall still
recognizes. Everybody in the building starts speculating about
why OneDrive “just works” while SharePoint feels like dial-up.
Sound familiar?VPNs have their quirks, too. Routing all remote
users through the same “secure tunnel” sounds like good hygiene,
but it can amplify small bottlenecks. For users at home, all that
encrypted traffic makes a round trip just to pick up a shared
file or join a meeting. If the VPN concentrator isn’t sized for
live video and collaboration, the whole experience drags. Now,
you’ve handed users something worse than slow internet—you’ve
given them inconsistent results, where one workload is reliable
and another one sputters.This is the paradox no one really talks
about: aiming for maximum coverage can actually create weird
patchwork problems that drain productivity. Your proxy, firewall,
or VPN doesn’t treat every M365 service the same, which means
support tickets show up with notes like “SharePoint lag but email
fine” or “Teams chat instant, but calling dropped me twice.” Most
admins assume Microsoft is to blame, or that something changed in
the client. But really, your own security stack is picking
winners and losers, without telling you.Let’s get specific. SSL
inspection—intended as a line of defense—can unexpectedly strip
away headers, break persistent connections for Teams or Exchange,
and even derail authentication tokens. Even a minor delay in
decrypting and re-encrypting can throw off real-time voice or
video. Microsoft is well aware of this, which is why they
maintain a living, sometimes massive, list of endpoints that are
meant to be left alone. These aren’t vanity URLs—Teams media
flows, SharePoint uploads, Exchange syncs—they all have addresses
Microsoft wants bypassed from deep inspection. Ignore this list,
and plan on a steady stream of “is the internet broken?”
complaints.Now, how do you actually catch the troublemaker?
Real-world network monitoring pays off here. Microsoft offers a
free connectivity analyzer, which checks from a client’s
perspective and highlights any detours or delays hitting their
endpoints. Pull the logs from your own tools—packet sniffers,
flow analyzers, or just plain event logs on your proxy. If you
see big lags on TCP handshakes, or repeated dropped packets for
Teams calls, you’ve likely pinned it down. The trick is to go
service by service and see who’s getting stuck where. Find that
SharePoint feels fine but Teams stumbles? The odds are your
stack’s treating them differently, possibly due to some
“catch-all” inspection rule that nobody’s questioned in
ages.Here’s a true story that hits close to home. I worked with a
company that recently upgraded their security stack, proud of
their new proxy with advanced threat detection. About two weeks
in, the complaints started—Teams went from tolerable to nearly
unusable, but SharePoint was still zipping along. It turned out
the proxy was flagging real-time UDP traffic as
“anomaly”—something the team never thought to exclude. Flipping
the right bypass for Teams media traffic brought calls back to
normal in less than an hour. No new licenses, no escalations to
Microsoft, just a missed detail in the proxy config.So what’s the
fix that doesn’t throw your security posture out the window? It’s
all about maintaining a fresh, well-managed bypass list and
applying split tunneling for those services that demand low
latency and consistency. Microsoft even publishes the precise
addresses to trust. When your inspection stack and routing rules
match what M365 expects, things settle into a groove. You keep
phishing threats and risky domains under watch, but your core
productivity apps move at the speed users expect. Of course, if
the idea of opening up direct paths or split tunnels gives you
pause, there’s still more to consider—like bandwidth planning,
traffic prioritization, and convincing the business it’s worth
the change. And that’s where things can get even more
interesting.


Proving the Case: Selling Network Changes to Leadership


You’ve found the network quirks and you know what’s slowing down
M365, but reality check—getting your higher-ups to buy in is a
different animal. Most organizations aren’t keen to tinker with
their carefully layered security controls unless there’s proof
that the effort is worth it. Suggest a new switch or firewall
rule, and someone’s bound to ask, “How do we know this won’t just
cause other problems?” The default stance is caution—especially
from leadership that hears “network change” and imagines
downtime, audit headaches, or extra risk. That’s fair; their job
is to weigh the balance between keeping the lights on and not
accidentally letting something slip past the gates.The sticking
point almost always circles back to data. Leadership wants more
than gut instincts, no matter how much noise is coming from the
help desk. Maybe they’ll listen to stories of users complaining,
but they definitely perk up when you start showing numbers. So
the question is, how do you get those numbers and what makes them
compelling? Here’s where a little homework goes a long way. You
run baseline tests before any changes—measure current latency for
Teams calls, record SharePoint upload times, and note how long
OneDrive syncs actually take. Then you tweak the routing: bypass
the proxy for just the core Microsoft 365 endpoints, set up split
tunneling for Teams. Repeat the measurements after. The
differences aren’t usually subtle, either. In a side-by-side
comparison: Teams call setup drops from seven seconds to under
two, SharePoint files that used to crawl now show up in half the
time, and those random connection drops start to vanish. You can
plot that on a line graph or put it as plain old averages—either
way, it’s the kind of before-and-after that translates into
something boardrooms understand.Let’s talk specifics, because
numbers make or break this conversation. Teams calls, for
instance, work best when latency stays below 100ms. File syncs on
OneDrive get painful when upload speed drops below five megabits
per second per user. Microsoft doesn’t always spell out the
minimums for everything, so this is where your own metrics fill
the gap. If you have a remote branch that hairpins all traffic to
HQ, it’s not hard to see latency hit 150ms or even 200ms at busy
times. Suddenly, half the complaints make sense. A regional
office routes SharePoint through an overloaded proxy for
inspection—the upload speed looks fine in a test, but real user
experience lags, especially when those inspection engines get
bogged down at peak hours.Now, you could stop at just user
anecdotes, but putting real bandwidth requirements in front of
the decision makers helps draw a line between what users feel and
what’s happening under the hood. If you can say, “Teams needs 1.5
Mbps per meeting participant just for audio and video,” and then
show that users routinely get half that because they’re stuck in
a security queue, it’s not about wishful thinking. It’s about
technical reality. Show the gap between the cloud-ready path and
the bottlenecked one, and questions about “why do we need to
invest?” start to fade. Even better, map support tickets or help
desk volume to the performance metrics—“We saw a 30% drop in
Teams complaints the week after we updated our routing”—and the
pattern tells itself.It helps to reference results from peer
companies and real-world case studies too. Healthcare orgs, for
instance, often have strict controls, but many have proven that
adopting Microsoft’s guidance for direct local egress didn’t
compromise their security posture. Instead, they reported
smoother Teams meetings and less downtime in SharePoint. One
manufacturing company tracked everything: before the change,
daily Teams outages averaged ten minutes of lost productivity per
user, not to mention the time spent troubleshooting. After fixing
their network routing, not only did complaints plunge, there was
a measurable uptick in project velocity—simply because
collaborating didn’t grind to a halt every time a firewall
hiccupped.The bigger picture is this: when you translate network
tuning into measurable business outcomes—reduced downtime, fewer
support tickets, and time saved across the board—you turn a “nice
to have” tuning request into a cost-avoidance or even a
productivity booster. The return on investment comes out of
overhead costs shrinking; that means fewer emergency IT
escalations and more time spent on innovation instead of
firefighting.The case isn’t just technical—it’s practical,
economic, and user-centric. If you show leadership that your
changes pay off in the form of happy, productive employees and a
support staff that spends less time on the phone, you’ve got the
foundation of a strong argument. Most executives love hearing
that network investments aren’t just padding the
infrastructure—they’re actually buying peace of mind and making
collaboration tools truly usable.With the right charts and a few
well-chosen anecdotes from your own data, you can usually move
the conversation from “why change anything?” to “how soon can we
make this work?” Once leadership sees that network investments
can quiet down help desk tickets and push projects forward,
you’re not fighting an uphill battle. Instead, you’re giving your
organization a tangible way to get more value from the hundreds
of thousands they’re already spending on Microsoft 365. And when
you finally shift the focus from endless app troubleshooting to
rooting out network snags, users notice, too. So if you’re tired
of the blame game and want to shift your M365 performance from
pain point to bragging right, there’s a simple next step. Let’s
get into what you can actually control and start putting those
network fixes to work.


Conclusion


We’ve all sat through Teams calls where you’d swear the audio is
traveling back in time. The bottleneck isn’t in some Microsoft
data center—most of the time, it’s the switch, cable, or firewall
sitting under your nose. If you really want smoother M365
performance, don’t keep blaming the cloud. Map your own network,
see old patterns for what they are, and rethink if that gateway
still earns its keep. There’s always a reason for slowdowns—and
more often than not, it’s a piece of your own puzzle. For more
real-world M365 advice, hit subscribe and get the upper hand.


Get full access to M365 Show - Microsoft 365 Digital Workplace
Daily at m365.show/subscribe