Network Principles for Office 365 Connectivity

Posted on by Tony Redmond in Office, and Office 365

Microsoft Cloud Network

The Joy of Network Connections

In the good ol’ days, the definition of offsite access to corporate resources was dial-up connections over a VPN. And although the VPN allowed secure access to web sites inside the corporate firewall, the experience was awful and slow.

The software wasn’t much better. Until Outlook 2003 came along with “drizzle mode synchronization,” we enjoyed the unique experience of single-threaded synchronization. The net effect was that anytime someone sent you a presentation, you waited. And waited. And then waited some more. But at least we had time to sip a cool drink while the presentation downloaded.

Networks for the Cloud

I sometimes wonder if corporate networks are stuck in a rut when the time comes to embrace the cloud. Information Security teams have a difficult job to keep networks secure, but that’s no reason to cling to an array of VPNs and proxy servers with the same enthusiasm as a drowning man clutches a gently-deflating life vest.

We’ve known that proxy servers can interfere with Office 365 traffic for years (here’s an article from 2015). Microsoft made a big effort at the Ignite 2017 conference to emphasize the steps customers should take to configure networks for Office 365 services. At the time, I summarized Microsoft’s message as “keep it simple” by not forcing Office 365 traffic through proxies or intermediate steps.

Trusted Network Connections

The mistake often made by Information Security is to consider traffic going to trusted cloud services with the same suspicion as consumer internet sites. By trusted, I mean services that the company has contracted with from a well-known partner that invests heavily in security. Commercial services run by Microsoft and Amazon come into this category.

If you trust Microsoft to deliver secure Office 365 services via the cloud, then why force traffic to and from Office 365 along the same paths as casual Facebook browsing? It just doesn’t make sense to do the same kind of analysis and processing of data flowing along a connection to a well-known trusted partner as it does for ad-hoc connections to web sites that you don’t know.

Planning for the Cloud

It’s not as if Microsoft doesn’t publish lots of information about how plan and tune network connectivity with Office 365, including some reasonable principles to adopt. There’s also documentation covering Office 365 URLs and IP addresses and a web service to stay up-to-date with Microsoft network changes. A series of posts by Microsoft’s Paul Collinge are also interesting reading.

Perhaps network planners treat Microsoft’s recommendations for Office 365 connectivity with caution because they see no reason to move away from the approach used to protect corporate networks for years.

But if you use the principles of yesterday to protect the services of today, your network is likely to deliver degraded connectivity to users. That’s not a good thing in an era when more services that ever before are consumed via the cloud and those services become more network-hungry over the years.

Network-Hungry Apps

Office 365 developers assume reliable and fast connections when they design applications to satisfy users with graphically-rich features. Outlook desktop clients are capable of handling network slowdowns and glitches, the Teams desktop client caches a certain amount of data, and the OneDrive sync client is invaluable at synchronizing documents to a PC for offline access. Apart from that, the Office 365 apps don’t cope well with poor network performance.

The Goal for Connections

The goal for network engineers should be to build network paths to Office 365 capable of handling the demand created by multiple connections per user with the aim of getting data to an edge node for Microsoft’s network as quickly as possible. Once the data reaches Microsoft, it is transferred to the Office 365 datacenters over dark fibre connections.

Because Microsoft has distributed edge nodes around the world to bring client traffic into their network, it doesn’t really matter too much where you connect to Office 365. I get as good performance when I connect to Office 365 in the U.S. or Europe as I do when in my home office. And if I don’t, the problem isn’t with Office 365 – it’s the local network connection from client to the edge node that’s almost always at fault.

Simple Principles, Good Outcomes

Of course, exceptions do exist and there are times when organizations need to secure all traffic in the same way. But that’s no reason to avoid asking the question of what the right philosophy for handling network traffic to Office 365 should be. If network engineers focus on the two simple principles of simplicity and speed, Office 365 users will enjoy the kind of connection they need to be effective.

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register