Outlook Anywhere has been around for a very long time now. Back when it was young nobody was really thinking seriously about the future routes from which a desktop client might access Exchange, such as from a cellular phone network or while flying across the Atlantic.
So, Microsoft have done some thinking, resulting in a revamped version of Outlook Anywhere for Exchange 2013 SP1 and Outlook 2013 SP1.
Here’s the good news:
- That annoying ‘Connecting to…’ message from when you first open Outlook should be significantly reduced. In Microsoft’s tests, a 70% improvement was achieved for monitored clients. That could translate to a 30 second wait on your slow mobile-data connection instead of the 90 seconds it might take now.
- When resuming from hibernation, or reconnecting, you can expect to shave ten seconds off the usual forty or so.
- There is better (and simpler) server-side monitoring, via less complex network encapsulation and more useful data in HTTP header information.
- You can expect an improved Autodiscover response. MAPI/HTTP has no need for us to advertise authentication settings – all you need from the server is the protocol version and the endpoint URLs, which can be used without modification. The authentication settings are requested via a standard anonymous HTTP request, just like other web protocols, so no special configuration (or reconfiguration) is needed when they’re updated.
- There are fewer concurrent TCP connections required between client and server (and there’s faster renegotiation in the event of a connectivity blip, with sessions kept open for 15 minutes rather than needing to be re-established).
- The simplification allows multifactor authentication to be more easily added in the future (it’s on the roadmap for later this year).
At the moment Nexus’ system runs Exchange 2010 SP3 so we can only gaze admiringly at these new features until we too get the green light to upgrade to Exchange 2013. When we do, we’ll go straight to SP1 and turn all of this on…
In the meantime, though, let’s deal with some of the inevitable questions.
How have they done this?
Outlook Anywhere has historically relied on a heavily-disguised MAPI request, encapsulated in an RPC packet, which is in turn wrapped up in an HTTP request. It’s this double-wrapping that Microsoft have been striving to remove.
Nexus’ current Outlook Anywhere set-up requires two long-lived TCP connections to be held open for each session between Outlook and Exchange. This is done via an RPC_DATA_IN and an RPC_DATA_OUT connection, with both required for each client’s RPC/HTTP session. If these are dropped, or lost, they need to be completely re-established from scratch, with all the associated overhead you’d expect. In terms of network overhead, traffic, cost and logic, this represents an overly complex way to do things, with knock-on impacts to perhaps thousands of users simultaneously. Switching from Outlook Anywhere to MAPI/HTTP means that your sessions are retained for 15 minutes; in the event of a blip the client can simply reconnect and continue where it left off, without needing to re-establish the session first.
This new MAPI/HTTP connection supplements Outlook Anywhere with a completely different way of doing things: the TCP connection established between the client and server only needs one long-lived connection and a secondary ad hoc connection. By also removing the additional RPC encapsulation overhead from within the HTTP packets (it’s now just MAPI and HTTP) the entire process is simplified, made faster, and as a further bonus it means that the HTTP headers will contain more meaningful data.
If you’re on a very slow, or low quality, network this is undeniably a good thing. It’s also good for us as administrators: we won’t see a surge of quite so many RPC/HTTP connections all being re-established at once. Less server overhead at times like that equals a faster recovery for Nexus users after, say, a short-lived network issue.
What do we need to do at Oxford IT Services to get this?
- All of Nexus’ Client Access Servers will need to be upgraded to Exchange 2013 (and have SP1 deployed to them, since that’s what adds this functionality). Incidentally this new function is disabled by default so that it doesn’t introduce unexpected behaviour for anyone just doing a Service Pack upgrade.
- End users will need a client that is MAPI/HTTP aware. Today this means you need Office 2013, also updated to run Service Pack 1, as nothing else is yet MAPI/HTTP aware.
Any pitfalls?
- The increase in short-lived HTTP connections will require additional CPU resources on Client Access Servers. This is an issue for anyone who designed their server environment around Exchange 2013’s original RTM requirements, potentially needing 50% more CPU resource. This isn’t an issue for us, however. Exchange 2010 – our current version – has yet-higher CPU requirements so, for us, an upgrade to Exchange 2013 arguably leaves us with over-specified hardware.
- .Net 4.5.1 will be required on Exchange servers since it fixes issues which would otherwise cause longer wait times for end-users.
- On a perfect network, with no dropped connections, there is a slight increase in network overhead, of an average 1.2% for 50KB average packets. For larger transers over 10MB this increase could be up to 10%. However on slow low-quality networks the simplification of the overall packets, and the ability to resume a dropped connection, will more than offset this increase.
- MAPI/HTTP is a new CAS endpoint, so needs to be factored into namespace design (including certificate handling).
- MAPI/HTTP is an organisation-wide option and not intended to be a server-specific one (although a registry key can be used to disable it on individual servers, where required).
- Unified Access Gateway doesn’t yet support MAPI/HTTP (although support is planned via an update)