Faster Delivery = Happy Users
Automated Process = Fewer Errors
Standards = Cost Reduction
Order Visibility = Confidence
Linking Systems = Efficiency
Companies are moving their email to the cloud in droves.
Let’s face it, administering Microsoft Exchange is one of those jobs that when everything goes right, no one knows you exist. And when things go wrong, everyone knows you exist. The good news is that many companies are offloading their Exchange to Microsoft through the use of Microsoft Office 365. If you doubt that Office 365 is big, consider that in July of this year Office 365 online workplace tools brought in more revenue than the traditional version of Office that’s installed on people’s computers.
When you think about it, e-mail server replacement is the perfect SaaS application. It’s well defined without huge deviation from one organization to the next, scales well across multiple servers, needs to be accessible from anywhere and often needs permanent retention of records. All things that the cloud is good at.
It’s important to remember that while moving to the cloud alleviates your responsibility for the servers that run e-mail, you still are responsible for monitoring the e-mail itself and your company’s connectivity to the cloud. Monitoring cloud-based applications is different than monitoring on-premises applications. Where you may have been concerned with memory and disk capacity on your servers, or server-to-server communication in the past. Those are not concerns with SaaS. But some potential issues still exist. Here are just a few of the metrics you may need to be concerned with in an Office 365 environment:
Earlier this year, in collaboration with Loop1 Systems, we developed a set of templates for Microsoft Office 365 to monitor these and much more. The templates have been very popular with customers, but there are a few things you can do to improve their implementation and function. Since these templates monitor Software as a Service, they aren’t exactly like other templates that we typically provide.
Since these templates are PowerShell scripts that run against a Microsoft URL, the best solution is to create an external node and apply the templates to it. You can use “outlook.office365.com” as the node. This is the URL for the mail API requests. Technically for the Portal, Subscription, Security Statistics and License Statistics templates the scripts use “api.admin.microsoftonline.com”, but splitting the Office 365 templates between two nodes can be confusing and forces the SAM user to understand which components of the service reside on each node.
External nodes don’t report status. By using an ICMP node, you will get a rudimentary status indication on the node icon based on a ping of the URL. External nodes give no status and always display a purple “arrow” icon without status. However the URL “api.admin.microsoftonline.com” doesn’t seem to respond to ping requests so it will always appear to be down if you point an ICMP node there. Here is the external icon vs. the ICMP node icon.
Another way to determine the responsiveness of the Office 365 application is to set up a NetPath service for “outlook.office365.com”. If you have NetPath, you can use it to get a detailed view of the bottlenecks between your site and the application portal.
Depending on the number of mailboxes in your environment and the number of templates implemented, you can experience throttling of your API requests from the Office 365 API. If you are throttled, the choices are to either run less component monitors or reduce your polling frequency on some templates. Most users can actually reduce the polling frequency substantially on most or all Office 365 templates since the majority of the metrics don’t change frequently. One thing to keep in mind is that if you want to ensure enough data points to avoid gaps in history, you might want to use less than an hour for your polling frequency, so try setting the frequency to 1200 (20 minutes) rather than the default of 300 (5 minutes). If you want to know more about Microsoft API throttling, see Avoid getting throttled or blocked in SharePoint Online | Microsoft Docs for a description. The article is about Sharepoint but the concept is the same for Office 365.
The data comes back from the API in a comma-delimited format which is great for programming but not so readable. To make the data more readable, you can modify your own copies of the scripts as follows:
[string]::Join( ", ", $users)
[string]::Join( "< br/>", $users)
NOTE: You should be aware that this modification is injecting HTML directly into the output from the PowerShell script. When viewed on the SAM console it will display correctly. However, this change could create unexpected results in other areas of SAM that are not displayed on a web server, such as reports.
Since Office 365 is SaaS, many of the metrics in our previous Exchange templates is either not available or not meaningful. Metrics like disk I/O and disk latency aren’t available for a cloud service where the hardware is abstracted away from the user. Similarly attempting to monitor processes and services on the hosts is not possible. Primarily with Office 365 we monitor application data, which is available through the Office 365 API.
The MAPI round trip template was intended to check connectivity between multiple Exchange servers. Since Office 365 is SaaS, you don’t control the physical servers that are used for your accounts. With cloud-based applications, you should check connectivity between your network and the Office 365 website. You can get a sense of this connectivity by using the portal templates and the ICMP option discussed above. Also as mentioned above, you can use NetPath to show the actual path your connections take to Microsoft. Another option is to use Web Performance Monitor to record a typical mail transaction and get perspective on each part of the session.
Hopefully, this post has given you some ideas about why and how to monitor Office 365. SolarWinds offers many tools to help you from SAM templates to network tools to user simulation.