How Do We Monitor Office 365 and Exchange Online For You

Summary

To completely lock down your resources that Office365Mon probes for you, create a single service account in your tenant.  Give it a mailbox, and give it Read rights only to the site that Office365Mon monitors.  Use the instructions below to configure Office365Mon to use this account for monitoring and that’s it – you’ve completely locked down the resources we monitor for you.

Since You Asked…

Since Office365Mon.Com launched I’ve gotten a couple of questions about how we do the monitoring and probing of your tenants. People just want to feel comfortable that their monitoring solution isn’t going to open up a data breach of some kind. That all makes perfect sense and why I wanted to explain a few of the basics around how we do it and how we try and limit how invasive our probes are. It’s really worth thinking about three different aspects of it – the security needed to check a resource, what we look for in an Office 365 tenant, and what we look for in an Exchange Online tenant.

Security to Check Resources

One of the fundamental goals of our service has been that if all possible, whenever possible, we never want to store usernames and passwords. Not only does that tend to be a much broader security exposure than is really needed just to check the resources we monitor, it would also paint a much bigger target on our back in terms of hack attacks. That’s why we built our solution around using Azure Active Directory for authentication, and the concepts they support such as access tokens and refresh tokens. When you configure your Office365Mon.Com monitoring and provide an Office 365 site or Exchange Online mailbox, you will go through the standard consent flow that Azure AD provides. That means that it will tell you exactly what rights we’re asking for, and you need to agree to grant us those rights. You never enter a username and password into our site; instead after you consent to letting us access your resources we just get the access token and refresh token that enable access to them. That’s it – there’s nothing else we can access on your behalf.

What We Look for in an Office 365 Tenant

Here’s a new UPDATE to this as of April 30, 2015!  We no longer monitor only the root site of your Office 365 tenant.  You can now enter the Url to any site collection you have, and we’ll watch it for you.  This will also open up some other developer opportunities we’ll be releasing the not too distant future. The probe we use to check an Office 365 tenant is very benign in terms of the data it tries to access. In short, when we do a probe, we ask the Office 365 site we are monitoring to give us the collection of lists that are in the site. That’s it – just the names of every list in the site. No data, nothing else. We don’t store the data we get back, we don’t do anything with it all in fact; we’re really just looking to make sure the service is responsive. It’s the type of data that we know we can count on always being in every single site collection, and the list names themselves don’t tend to be big secrets. Now what if you still want to “lock down” the content that Office365Mon has access to?  Well, you can do that using the instructions below for locking down an Exchange Online mailbox.  In a nutshell, you’re going to create a new account in Azure AD that we’ll use for monitoring – it can even be the same one that you use for Exchange Online monitoring.  Then grant it rights only to the site that we are going to monitor for you, and only Read rights.  Then just follow the steps below to use that account when configuring the SharePoint Online resource in Office365Mon.  That’s it – you’ve just locked down the monitoring to that single site.

What We Look for in an Exchange Online Mailbox

For Exchange Online we have a little more flexibility in terms of what we’re going to look at. In terms of the data itself, we ask for a list of the messages that are in the mailbox. Whether there are many messages or none at all is really irrelevant; we just check to make sure we’re getting a satisfactory response back so we know the service is up and running. Checking a mailbox is a scenario where you might want to use the Subscription Admin feature of Office365Mon.Com. In short, the scenario for consenting to grant us permission to check a mailbox is that whomever is logged on to Office365Mon.Com is redirected to Azure and asked for permission to access that mailbox. So you can lock things down even further by creating a mailbox that’s only going to be used for monitoring. Let’s walk through an example of how you would go through this process to lock things down. First, assume you create a new user called “contoso\steve” and create a mailbox for that account that will be used for monitoring. Here’s how we’ll set up monitoring on that mailbox:

  1. Go to the Office365Mon.Com configuration page at https://www.office365mon.com/Signup/Status.
  2. Log into the site using the credentials you used when you created your Office365Mon.Com subscription
  3. Go to the Subscription Admins section and add the UPN for the user you created for mailbox monitoring; in the example above that would be steve@contoso.com.
  4. Close the browser, and open a new in-private instance of your browser.
  5. Go to the Office365Mon.Com configuration page at https://www.office365mon.com/Signup/Status.
  6. Log in with user you just added as an admin; in the example above it would be steve@contoso.com.
  7. Scroll down to the Cloud Resources section and enter the email address for the mailbox you are going to use for monitoring in the Mailbox Owner UPN section.  In this case that would be steve@contoso.com.
  8. Click the Update button.  You will go through the process to consent to allow us to monitor the mailbox for steve@contoso.com and that’s it – you are now done.

You never need to use that mailbox again, but we’ll keep monitoring it for you. Don’t forget though that tokens that Azure AD gives us to access these resources are only good for a maximum of 90 days. That means every 90 days or so you’ll need to log into the Office365Mon.Com site again as described above and click that Update button next to the Mailbox Owner UPN so that we can get an updated token.

That’s How We Do It

Hopefully that explains exactly at a high level how we do what we do. If you have other questions or concerns though please feel free to shoot me an email anytime at support@office365mon.com.

4 thoughts on “How Do We Monitor Office 365 and Exchange Online For You

  1. Hi,

    just wanted to let you know that the Office365Mon comes back with an error.
    We couldn’t import data from Office365Mon
    There was an error when processing the data in the dataset.
    Please try again later or contact support. If you contact support, please provide these details.
    Message: The column ‘Column1’ of the table wasn’t found. Table: Distributed Agent Outages.
    Activity ID: 87bf7f50-fb53-4504-9d52-ac79dca1e88e
    Correlation ID: 4b24e521-07e1-41ca-0e27-2147e9960e21
    Request ID: 6c8d3cb1-4abd-f160-7d4f-b3a91aca3233
    Status code: 400
    Time: Wed Feb 13 2019 15:52:54 GMT+0100 (Central European Standard Time)
    Version: 13.0.8309.200
    Cluster URI: https://wabi-west-europe-redirect.analysis.windows.net

    Like

    • Hi Dave, a couple of things: first, you should always feel free to reach out to support@office365mon.com if you’re having an issue of any kind and we’ll do our best to help track it down. Secondly though, we’re not seeing this issue and not having it reported elsewhere, and our code for this hasn’t changed in over two years. That being said, they are doing a bunch of changes in Power BI itself and we have heard from a couple of customers that have seen weird flaky things as a result. But as I said, feel free to try our support alias and we’ll see if we dig out anything further. Thank you!

      Like

  2. I’m encountering the exact same error as Dave. What was the resolution?

    Message: The column ‘Column1’ of the table wasn’t found. Table: Distributed Agent Outages.
    Cluster URI: WABI-US-NORTH-CENTRAL-redirect.analysis.windows.net
    Activity ID: 34d52cd9-c7e9-5d7e-2553-c09e7ada33a8
    Request ID: f67416fa-3f06-0b60-0dc4-5feb0e5b2302
    Time: 2020-01-07 15:06:53Z

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s