Cloud stories: Groupwise to Office 365 (part 1)
June 24, 2014 3 Comments
I’ve been meaning to start this series of posts for a while, documenting our journey as we move various legacy on-premise systems to Office 365 and all the fun and games we’ve had along the way. Like many email was the first item on the migration hit-list and indeed was a key driver for investigating moving services into the cloud.
Unlike many organisations we weren’t moving from Exchange, our on-premise system was actually Novell Groupwise. The large increase in storage space was the biggest draw for us to go cloud but mobile access also played a part. Novell were very short sighted in not providing a (free) mobile app for Groupwise as the majority of users weren’t willing to mess around with manual IMAP settings nor were they particularly enamoured with having to pay for a 3rd party app to read email on their phones, which these days is a bread-and-butter feature requirement for any enterprise-grade product (imo).
Although moving to a cloud-based service is often marketed as a click-and-forget experience it’s not entirely accurate unless you’re setting up from scratch. This post covers a few lessons we learnt and some tips to help you avoid them…
We use a combination of standard firewall and proxy web filter to direct traffic in and out to the Internet at large, a pretty common setup for an organisation of our size with ~2500 workstations.
However we soon found out that this wasn’t as simple as first thought. Although our firewall can identify traffic based on application some of the login processes for the Outlook client were only identified as vanilla SSL, I guess some of the Autodiscover processes may be the reason for this.
At first we thought the solution might be fairly simple, at my last place I used Microsoft’s Forefront Online Protection for Exchange (FOPE) which gave a defined list of IP ranges to allow mail from so was hoping Office 365 would be similar… we were wrong!
It started well enough, Microsoft gives what looks like a helpful list of addresses to allow here…
We dutifully added all of them to the firewall then watched as Outlook played it’s own game of Russian Roulette with logins, some would work and others would fail miserably with messages like the example below about an encrypted connection being unavailable. Trying to continue with the unencrypted version also failed.
The next logical step was to check the firewall logs and see what was going on, lo and behold there was a bunch of blocked traffic from the affected machine, type listed as SSL (in addition to the Office 365 traffic that was allowed by our rule). At first glance the listed IPs looked pretty similar to some of the ones on the Microsoft link so I punched them into the very helpful CentralOps domain dossier to do a bit of detective work into what they really were.
Surprise! The IPs were owned by Microsoft, One Redmond way. Over the course of a couple of days I’d collected (and kept adding) these new address ranges but new ones kept coming. After a while another surprise was that some were listed as being owned by Akamai, which is the CDN Microsoft use to deliver content for the Office 365 web interface. We expected that for OWA but not for the desktop client but there it was clear as day in the logs.
In the end we decided that there was no way we were going to be able to keep up with how rapidly the addresses were changing and give our users a decent experience (our pilot users didn’t have a fun time getting set up with Outlook) so we were forced to push all Office 365 traffic trough our proxy server instead. We didn’t want to do this if we could help it as our firewall is much faster at processing large amounts of traffic than the proxy – no choice for now but thus far it’s stood up to the load pretty well.
A well-written TechNet article explains how Microsoft have built the CDN network for Office 365 and why they’re only supporting wildcard URL rules for filtering…
…which is great but until the firewall vendors catch up and put it in their core feature sets many network admins won’t be happy. The issue crops up more when using the desktop Outlook client but that’s a fundamental reason for choosing Microsoft over Google so a workaround had to be found to give a reliable first-run experience.
Proxy issues with Outlook
Now that we had the basic traffic issues on the way we thought Outlook would kick into life quite easily but there was one more sting in the tail. Autodiscover still wasn’t working reliably despite having proxy authentication disabled for all Office 365 domains (seems a common recommendation from various proxy suppliers) so we needed to dig a bit deeper.
We ran the Outlook first-run wizard with TCPView running alongside and noticed something odd…
Our proxy settings were pushed out via a GPO setting, along with a manual exceptions list for various IP ranges and internal sites. Because our internal domain is the same as our external one we added autodiscover.havering-college.ac.uk to the list of proxy exceptions (and created an internal DNS record) so we expected to see connections going out via the proxy server address… except we didn’t.
Bizarrely it seemed Outlook was ignoring the proxy server completely and trying to connect directly – which on a standard user’s machine won’t work. Cue some furious Googling which showed that it wasn’t just us experiencing the same problem…
The only solution was to create a proxy auto-configuration file that explicitly says to use the proxy for the Office 365 URLs. As soon as we did this and switched the GPO over to Auto-Detect Settings Outlook kicked into life. I’m not sure if this issue has been sorted in Office 2013 SP1 but it’s not a listed fix and recent posts in the thread above suggest it’s still an unresolved issue.
Next post in this mini-series will cover some decisions you’ll need to make about what version of Office you use on your machines and how it can affect your 365 experience.