Protocols Matter: Monitor Office 365 MAPI over HTTP

Protocols matter. When it comes to monitoring cloud services, protocols, access methods and locations matter very much. At Exoprise we’re always investing in the best coverage, real-world access methods for the most critical and required protocols like Office 365 MAPI over HTTP (MAPI/HTTP).

We know other monitoring companies often don’t invest and try to sell a couple of pings against a port and call it end-to-end monitoring. It just doesn’t work that way – pinging a port isn’t going to cut it. Or, some companies will query APIs and URLs that have nothing to do with what a user accesses as part of using a service. That’s not really monitoring and its not going to tell you when the service is having problems. That’s the critical time when you don’t want to be let down by a monitoring tool.

a set of rules governing the exchange or transmission of data between devices.
plural noun: protocols

The entire Internet and web services are built atop protocols and when you want to monitor cloud services, you want to make sure you are monitoring the right protocols for each application. That’s what Exoprise CloudReady does.

New MAPI over HTTP CloudReady Sensor

We recently launched a new MAPI-over-HTTP cloud ready sensor which comes as close to possible to exercising the same protocols and stack that a user using Outlook against Office 365 would.  While the protocol and its support within Office 365 is not relatively new, the ability to automate it and synthetically transact against it IS new for Exoprise CloudReady.

This sensor posed its own unique challenges to develop – anything MAPI related is always challenging – but we’ve launched the beta and are encouraging customers and prospects to try it. The MAPI/HTTP sensor runs and operates just like any of other CloudReady email sensors. It tests mail queues, sign-on, autodiscover, proxys and end-to-end network coverage against MAPI. We’ll be enhancing the sensor over time with lower-level details and options over time.

The MAPI/HTTP sensor requires an Outlook MAPI stack to be installed which, unfortunately, requires a client installation of Outlook (and license). We’ve also implemented 64-bit support but its currently behind a feature flag so you should let support know if you are interested in testing. We’ll be expanding the number of MAPI-over-HTTP derived sensors in the near future as well.

Read more of the gory details about the MAPI/HTTP protocol here:

Outlook Connectivity with MAPI over HTTP

Improved Kerberos and SPNEGO (Negotiate) Support

We know we’re not the only company that uses browsers (headless or other) to synthetically test services. Now we’d make a bet we’re the only company that fully support Kerberos and SPNEGO from a headless browser that runs as a service. Here’s a few reasons why this is new extra support is critical:

• CloudReady Private Sites and their sensors run as a service. You want this, so they’re on and testing cloud services all the time
• Impersonation and correct identity establishment is important for monitoring cloud services. When stuff runs as a service it often has to properly impersonate a user to fully exercise different identity services.
• CloudReady excels at testing interactions between multiple services and servers during sign-in and SAML / SSO authentication. Often times this requires negotiate and Kerberos support.

By including support for mission-critical authentication protocols like Kerberos and Negotiate in our sensor stack, Exoprise continues to deliver the most comprehensive platform for the end-to-end monitoring of cloud services from a real end-user perspective.

Here’s where other monitoring falls apart

There are companies that attempt to monitor cloud services using protocols that don’t even come close to what an actual end-user does. Here’s some of the things that other companies do, for example, to monitor Office 365. These methods are not going to tell you much about how Office 365, Exchange Online, SharePoint or Skype for Business are performing . Or even about their uptime and availability.

• Ping. If you’re just pinging Office 365 or Skype servers, its not really going to tell you anything at all about about the performance of these services such as Skype. We’ve seen companies that just ping a (wrong) port or two and then tell you that its the greatest Skype or Email monitor in the world. 
• VoIP Packets. VoIP packets alone are not going to be good enough to monitor Skype for Business. CloudReady does support this with our VoIP sensors but we often recommend that customers ALSO run CloudReady Skype sensors for full end-to-end coverage. Skype for Business is a unique system with its own (odd) protocol handling.
• Graph APIs. While the new Graph APIs from Microsoft are great for programming against…you’re end-users aren’t utilizing the Graph APIs as part of Skype, SharePoint or Onedrive. In fact, they’re quit new so its unlikely you have any users utilizing the APIs at all. If you’re testing the Graph APIs and they have a problem – that’s not indicative that Outlook, OWA or MAPI is having a problem. Additionally, Graph APIs don’t touch a Client Access Server (CAS) server when it comes to E-Mail uptime and deliver-ability. Testing these APIs doesn’t reflect anyone’s experience.
• PowerShell API for testing Office 365 connectivity. PowerShell APIs for testing Skype/Lync servers is fine for establishing some backend server availability but they don’t tell you anything about the end-to-end connectivity for Skype for Business or how the network is capable of handling VoIP. We’ve all been on those calls…where not everyone can get into Skype for Business or there are Audio and Video cutouts. The only way to determine if this is happening for your end-users is run real tests against the real Skype for Business clients.

These are just a few of the things to watch out for when it comes to making sure that your monitoring the right protocols and getting the kind of coverage that you need out of a monitoring tool.