5 Things that Can Go Wrong with Office 365 Networking

The move to cloud-based solutions like Office 365, Google Apps and others is one of the biggest fundamental changes IT professionals will undertake in the history of computing. Microsoft Office 365 has >70 million paid subscriptions with a goal to have annualized revenue reach $20 BILLION by 2018.

The cost savings and productivity enhancements available to organizations are huge. But these savings and benefits can’t be reaped without careful planning. Quality of experience, uptime and availability are shared responsibilities of both the provider and the customer. Read on for some of our experiences helping customers with their Office 365 journey and some of the networking pitfalls to avoid.

1) Keeping the network just the same as when everything was behind the firewall

This happens a lot; the network guys are separate from the Application owner guys and nary the two shall meet. They don’t often share data and tools, the application owners blame the network guys and vice-versa. Here at Exoprise we see this quite often when Exoprise CloudReady is put in place and our customers start to get real end-user visibility into how Office 365, Salesforce.com, Dynamics, Box, ServiceNow and others are performing.

Networks will change with the adoption of massive cloud-based services like Office 365. When all the traffic was on-premise internal routers and network paths were burdened. Now that the traffic is external, it will stress different parts of your network. We like to call this the “Service Delivery Chain”. You thought that when you adopted cloud-based services like Office 365 everything was going to be easy — just give the user a browser. But that’s not the case. The Service Delivery Chain including Single-Sign-In, proxies, firewalls, gateways, etc. — they complicate the situation.

2) Security officers demand that all firewalls and proxies be kept in place

This is a common initial desire for many of our mid-to-large enterprise customers — they want to proxy all of the traffic between services such as Office 365, Google for Work and their end-users — no matter where they are. We see this at the beginning of our customers migration to the cloud but it doesn’t usually last or not in its current form.

Proxying all of your traffic for services like Office 365 requires additional investment. Most assuredly, your proxies will not be able to handle the additional load that something like the shift to cloud services places on them. We do recommend running CloudReady sensors behind the firewall and on our Public Sites to get a baseline comparison between a proxied environment and one that isn’t. We have many customers that utilize CloudReady for load-testing and network design precisely so they can prove the impact of one approach versus another.

3) We route everything centrally — nothing can go wrong

We hear this sometimes with our trial customers. Enterprise’s have had their own MPLS-routed networks in place for years. They put it in place back in the good old days of Exchange 2003 😉 and then they believe that a decade-old network design will survive the shift to cloud/SaaS. Often, coincidental with this old network design, is their desire that they only monitor their central network because “everything just routes through to one place”.

Talk about head meeting sand. If you are only monitoring from one location on the network then you will have no idea what the experience is for end-users on the other side. Additionally, routing everything centrally can be slow, expensive and less fault tolerant then if you sent secure, SSL-traffic directly over the Internet for branch offices and remote workers. Office 365 and wide-scale SaaS adoption for an organization places different demands on a network end-to-end. You must assess and measure those demands carefully.

We’ve written in the past about using CloudReady before, during and after and have seen numerous customer abandond their goal of routing all traffic centrally from every branch AFTER carefully harnassing the power of CloudReady’s analysis.

4) ExpressRoute to Office 365 is going to take care of this — we’ll wait

ExpressRoute is a new data center connection type that Microsoft has begun offering for fast connectivity from your own routed and VPN’d LAN to your Office 365 and Azure tenants.

Still being rolled out, ExpressRoute should prove to be helpful for large organizations with MPLS networks in place already that also happen to be connected in the data-center locations where ExpressRoute is offered. Customers will still have to route their traffic from all of their branch offices and locations through their private WAN, into and out of the ExpressRoute connection. While it sounds like it should make things simpler and faster it does make the Service Delivery Chain longer where lots can go wrong that affect user experience on the other end of the pipe.

5) Our networks, Telcos and ISPs are perfect

This usually goes along with “the problem is never ours, its always Microsoft’s problem or the service providers”. Right…sure it is. And if you never monitor or track the SLAs for your deployment then you can always operate under those assumptions.

With CloudReady in place, even during an hour-long trial, our prospects and customers can immediately see how their network and SaaS experience compares to other organizations from the same region or globally. That is the power of “Crowd-powered” monitoring, bench-marking and the power of the Exoprise born-in-the-cloud Network Monitoring solution that is CloudReady.