Anyone who has worked with Exchange for any length of time will be aware that Microsoft doesn’t boast an impressive record when it comes to delivering APIs that are both powerful and easy to use. MAPI, the godfather of Exchange APIs, is powerful but only those forced to work with it for a number of years might be coerced into calling it easy to use. Exchange Web Services (EWS), which is used for the Outlook for Mac client, is easier to use, but only if you’re Glen Scales and enjoy figuring out its mysteries. We’ll draw a veil over other Exchange APIs, like CDO Routing Objects, as none succeeded.
Having esoteric APIs is not a recipe for success in today’s fast-paced, high-cadence world. Programmers simply don’t have the time or energy to master archaic rituals, which is why Microsoft has introduced a set of REST-based APIs to access Office 365 services, including a “Unified” APIs for dealing with the contents of Exchange mailboxes and other data such as Office 365 Groups and the Graph database. Other REST APIs are available to access the Office 365 reporting service, Office 365 management activity, and Office 365 service communications data.
“REST” means representational state transfer, a method well suited for client-server interactions conducted over HTTPS. The advantage of choosing REST as the basis for the Office 365 APIs is that the format and use is familiar to many programmers who have built web services. Clients connect to well-known endpoints, provide authorization (using OAuth), and conduct transactions. The results are handed back in JSON format. In short, no black magic required.
The reason why providing a rich set of APIs for Office 365 is important is that it encourages the rapid growth of an ecosystem around the service. No product, even a cloud-based service that flexes and evolves at a frenetic pace, is capable of handling all the demands of every customer. The on-premises versions of Exchange and SharePoint became billion-dollar businesses for Microsoft because of the strength of the ecosystem that surrounded and supported the base technology. Microsoft is now attempting to enable the same degree of success for Office 365.
Signs are that ISVs are taking to the new APIs. The Office 365 reporting service was the first to be released and some nice functionality is now available from ISVs to supplement the basic reporting bundled into Office 365.
Monitoring Office 365 has always been important. The relative stability of the service since a few initial glitches in 2011 might have made tenants believe that everything would always function smoothly, but a number of recent outages have brought monitoring back into sharp focus and also reduced Microsoft’s SLA performance from 99.99% in Q1 CY15 to 99.95% in Q2.
Of course, translating the SLA performance into the experience of an individual tenant is difficult and a 0.04% decrease in SLA performance over a quarter doesn’t seem important, especially when measured against the huge scale of Office 365. However, any outage is important if your operations are affected, and that’s where companies like Office365Mon come in. Led by 18-year Microsoft veteran Steve Peschka, the mission of Office365Mon is to make administrators aware of outages in their tenants as quickly as possible. To accomplish the goal, Office365Mon uses synthetic probes to ensure that Exchange mailboxes and SharePoint sites are online and flags problems via email and/or SMS messages if a potential problem is discovered.
Using synthetic transactions to find problems is not a new technique. The Managed Availability system in Exchange 2013 and Exchange 2016 uses similar transactions to detect problems with on-premises servers and to take action to restore service if necessary, up to and including forcing a server to reboot.
Office365Mon hasn’t quite got that power, but it is pretty good at discovering when things aren’t going well. In fact, it is sometimes too good, as I discovered when I configured my tenant to use Office365Mon and received several notifications of potential outages over the following day, none of which caused any problems for my tenant and all of which seemed to be caused by transient conditions somewhere in the chain from the physical server hosting the monitored mailbox or site and the Azure server that queried the target resource in a synthetic transaction. As you can see from the screenshot, the majority of the outages reported for my tenant have been pretty short and users who run Outlook configured in cached Exchange mode were probably unaware of any issue.
Fortunately, Office365Mon now allows tenants to configure the “worry interval” for notifications so that you can set it to only notify you if a potential outage develops into a problem lasting 2 or 3 minutes (or longer). Providing a facility to configure the worry interval is an example of how applications change fast in the cloud to react to customer feedback. At least, it is for good applications! You can also configure Office365Mon so that it only reports specific events, such as the restoration of a service following an outage.
There’s a lot of value in hearing about a problem early. Microsoft attempts to flag problems in the Office 365 service dashboard but don’t inform tenants about problems as quickly as a monitoring product can. And best of all, the basic version of Office365Mon is free. You only pay for advanced features, such as advanced reports and analytics, including the ability to accurately report just how good an SLA Microsoft delivers to your tenant. If you're a cloud-only tenant, this service is definitely worth testing.
Of course, a synthetic probe is limited to what it can tell you and Office 365 is a complex beast, especially if you operate in a hybrid environment and have components spread across on-premises and cloud services, including everyone’s fun issues like single sign-on and directory synchronization. Office365Mon has an on-premises companion probe to be able to monitor what’s happening in those services, but it remains to see how effective the probe will be in dealing with the complexities of on-premises systems, which have their own particular peculiarities, such as Active Directory Federation Services and directory synchronization.
If you need monitoring and reporting for a hybrid deployment, you need to look elsewhere, such as ENow Software's Mailscape 365 or Exoprise CloudReady. Because Exchange hybrid environments can vary enormously in scope and complexity, the best idea is to run a trial to ensure that the products you think will work actually do when exposed to the white heat of operations.
It’s good that Microsoft is dedicating time and energy to making Office 365 a friendly place for developers. Everyone will benefit if ISVs deliver products that fill in the bits that Microsoft doesn’t (for one reason or another). It will be interesting to see how the use of these APIs develops!
Follow Tony @12Knocksinna
