Office 365 and proxy servers don’t mix very well. Well, to be more accurate, thousands of Outlook, Skype for Business and OneDrive for Business clients, each with multiple connections to online services can quickly build up to a lot of (persistent) connections. If you haven’t already, it’s well-worth reading Paul Collinge’s blog post on ensuring your proxy server can scale to handle Office 365 traffic.
Microsoft recommends that the network is configured to allow unauthenticated direct outbound access to a published list of URLs and IP ranges (there’s also an RSS feed) – although I’ve had customers who take issue with this and don’t think it’s a reasonable expectation in the enterprise. My view? You’re adopting cloud services; your network boundary has moved (disappeared?) and the approach you take to managing the connectivity between services needs to change.
Perhaps as more people take advantage of services like ExpressRoute for Office 365, things will change (although Microsoft is now advising that “ExpressRoute is not required or recommended for Office 365 except where mandated to use direct networking for regulatory purposes or where a network assessment for Skype for Business connectivity requires it”) but, for now, every Office 365 implementation I work on seems to involve a degree of proxy bypassing…
Some of the issues I experienced in a recent implementation included:
- OneDrive for business unable to perform an initial synchronisation, but fine on subsequent syncs. It seems that the OneDrive client downloads http://clientconfig.microsoftonline-p.net/fplist.xml when it first syncs. We could get it to work when going through a different proxy server, or direct to the Internet; but the main proxy server had to have a list of trusted sites added. The managed services provider had previously allowed access to some known IP addresses (a risky strategy as they change so frequently and the use of content delivery networks means they are not always under Microsoft’s control), but the proxy server had the capability to trust a list of target URLs too.
- Outlook unable to reliably redirect after Exchange mailboxes were migrated to Exchange Online. In this case, we found that, even with the trusted URLs in place on the proxy, as part of the Outlook Autodiscover process, Outlook was trying to contact autodiscover-s.outlook.com. The proxy wasn’t allowing unauthenticated access and Outlook didn’t know how to cope with the authentication request. Once autodiscover-s.outlook.com had been added to the proxy server’s unauthenticated access list, Outlook Autodiscover began to work as intended.
- Lync/Skype for Business Online calls working internally, but not with external parties. Users dropping off the call after a few seconds. Again, strongly suspect the network configuration…
- Exchange Hybrid free/busy information not available cross-premises. Again, this seems to be related to the Exchange servers’ ability to see the Internet (free/busy lookups are performed by the server, not the client).
- How to troubleshoot non-browser apps that can’t sign in to Office 365, Azure, or Intune (Microsoft knowledge base article 2637629)
- Tony Brown’s Microsoft Messaging User Group post on Office 365 and proxy servers.
- Jesper Ståhle’s “lost documentation” for Office 365 and web proxies.
[This is an edited version of a post that was originally published at markwilson.it]