The New Azure Converged Auth Model and Office 365 APIs

Microsoft is currently working on a new authentication and authorization model that is simply referred to as “v2” in the docs that they have available right now (UPDATE:  they prefer the “v2 auth endpoint”). I decided to spend some time taking a look around this model and in the process have been writing up some tips and other useful information and code samples to help you out as you start making your way through it. Just like I did with other reviews of the new Azure B2B and B2C features, I’m not going to try and explain to you exactly what they are because Microsoft already has a team of humans doing that for you. Instead I’ll work on highlighting other things you might want to know when you actually go about implementing this.

One other point worth noting – this stuff is still pre-release and will change, so I’m going to “version” my blog post here and I will update as I can. Here we go.

Version History

1.0 – Feb. 3, 2016

What it Does and Doesn’t Do

One of the things you should know first and foremost before you jump in is exactly what it does today, and more importantly, what it does not. I’ll boil it down for you like this – it does basic Office 365: email, calendar and contacts. That’s pretty much it today; you can’t even query Azure AD as it stands today. So if you’re building an Office app, you’re good to go.

In addition to giving you access to these Microsoft services, you can secure your own site using this new model. One of the other terms you will see used to describe the model (besides “v2”) is the “converged model”. It’s called the converged model really for two reasons:

  • You no longer need to distinguish between “Work and School Accounts” (i.e. and “Microsoft Accounts” (i.e. This is probably the biggest achievement in the new model. Either type of account can authenticate and access your applications.
  • You have a single URL starting point to use for accessing Microsoft cloud services like email, calendar and contacts. That’s nice, but not exactly enough to make you run out and change your code up.

Support for different account types may be enough to get you looking at this. You will find a great article on how to configure your web application using the new model here: There is a corresponding article on securing Web API here:

Once you have that set up, you can see here what it looks like to have both types of accounts available for sign in:


The accounts with the faux blue badges are “Work or School Accounts” and the Microsoft logo account is the “Microsoft Account”. Equally interesting is the fact that you can remain signed in with multiple accounts at the same time. Yes! Bravo, Microsoft – well done.  🙂


Knowing now what it does and doesn’t do, it’s a good time to talk about some tips that will come in handy as you start building applications with it. A lot of what I have below is based on the fact that I found different sites and pages with different information as I was working through building my app. Some pages are in direct contradiction with each other, some are typos, and some are just already out of date. This is why I added the “version” info to my post, so you’ll have an idea about whether / when this post has been obsoleted.


Tip #1 – Use the Correct Permission Scope Prefix

You will see information about using permission scopes, which is something new to the v2 auth endpoint. In short, instead of defining the permissions your application requires in the application definition itself as you do with the current model, you tell Azure what permissions you require when you go through the process of acquiring an access token. A permission scope looks something like this: This is the essence of the first tip – make sure you are using the correct prefix for your permission scope. In this case the permission prefix is “” and is used to connect to the Outlook API resource endpoint.  Alternatively your app can also call the Microsoft Graph endpoint under, in which case you should use the prefix for your permission scope.  The net of this tip is fairly simple – make sure you are using the same host name for your permission scopes as you do for your API endpoints.  So if you want to read email messages using the API endpoint of, make sure you use a permission scope of  If you mix and match – use a permission scope with a prefix of but try to access an API at… – you will get an access token; however when you try and use it you will get a 401 unauthorized response.

Also…I found in one or more places where it used a prefix of “”; note that it is missing the “s” after “http”. This is another example of a typo, so just double check if you are copying and pasting code from somewhere.


Tip #2 – Not All Permission Scopes Require a Prefix

After all the talk in the previous tip about scope prefixes, it’s important to note that not all permission scopes require a prefix. There are a handful that work today without a prefix: “openid”, “email”, “profile”, and “offline_access”. To learn what each of these permission scopes grants you can see this page:  One of the more annoying things in reviewing the documentation is that I didn’t see a simple example that demonstrated exactly what these scopes should look like. So…here’s an example of the scopes and how they’re used to request a code, which you can use to get an access token (and refresh token if you include the “offline_access” permission – see, I snuck that explanation in there). Note that they are “delimited” with a space between each one:

string mailScopePrefix = “”;

string scopes =
“openid email profile offline_access ” +
mailScopePrefix + “Mail.Read ” + mailScopePrefix + “Contacts.Read ” +
mailScopePrefix + “Calendars.Read “;

string authorizationRequest = String.Format(             “{0}&scope={1}&redirect_uri={2}&state={3}&response_mode=form_post&nonce={4}”,
Uri.EscapeDataString(“Index;” + scopes + “;” + redirUri),

//return a redirect response
return new RedirectResult(authorizationRequest);

Also worth noting is that the response_type in the example above is “code+id_token”; if you don’t include the “openid” permission then Azure will return an error when it redirects back to your application after authentication.

When you log in you see the standard sort of Azure consent screen that models the permission scopes you asked for:


Again, worth noting, the consent screen actually will look different based on what kind of account you’ve authenticated with. The image above is from a “Work or School Account”. Here’s what it looks like when you use a “Microsoft Account” (NOTE: it includes a few more permission scopes than the image above):


For completeness, since I’m sure most folks today use ADAL to get an access token from a code, here’s an example of how you can take the code that was returned and do a POST yourself to get back a JWT token that includes the access token:

public ActionResult ProcessCode(string code, string error, string error_description, string resource, string state)

string viewName = “Index”;

if (!string.IsNullOrEmpty(code))

string[] stateVals = state.Split(“;”.ToCharArray(),


viewName = stateVals[0];
string scopes = stateVals[1];
string redirUri = stateVals[2];

//create the collection of values to send to the POST
List<KeyValuePair<string, string>> vals =
new List<KeyValuePair<string, string>>();

vals.Add(new KeyValuePair<string, string>(“grant_type”, “authorization_code”));
vals.Add(new KeyValuePair<string, string>(“code”, code));
vals.Add(new KeyValuePair<string, string>(“client_id”, APP_CLIENT_ID));
vals.Add(new KeyValuePair<string, string>(“client_secret”, APP_CLIENT_SECRET));
vals.Add(new KeyValuePair<string, string>(“scope”, scopes));
vals.Add(new KeyValuePair<string, string>(“redirect_uri”, redirUri));

string loginUrl = “;;

//make the request
HttpClient hc = new HttpClient();

//form encode the data we’re going to POST
HttpContent content = new FormUrlEncodedContent(vals)

//plug in the post body
HttpResponseMessage hrm = hc.PostAsync(loginUrl, content).Result;

if (hrm.IsSuccessStatusCode)
//get the raw token
string rawToken = hrm.Content.ReadAsStringAsync().Result;

//deserialize it into this custom class I created
//for working with the token contents
AzureJsonToken ajt =
//some error handling here
//some error handling here

return View(viewName);


One note – I’ll explain more about the custom AzureJsonToken class below.  To reiterate Tips #1 and 3, since my permission scope is based on the host name, I can only use the access token from this code with the Outlook API endpoint, such as or  Yes, that is not a typo, you should be able to use the access token against either version of the API.


Tip #3 – Use the Correct Service Endpoint

Similar to the first tip, I saw examples of articles that talked about using the v2 auth endpoint but used a Graph API permission scope with a Outlook API endpoint. So again, to be clear, make sure your host names are consistent between the permission scopes and API endpoints, as explained in Tip #1.


Tip #4 – Be Aware that Microsoft Has Pulled Out Basic User Info from Claims

One of the changes that Microsoft made in v2 of the auth endpoint is that they have arbitrarily decided to pull out most meaningful information about the user from the token that is returned to you. They describe this here –

In the original Azure Active Directory service, the most basic OpenID Connect sign-in flow would provide a wealth of information about the user in the resulting id_token. The claims in an id_token can include the user’s name, preferred username, email address, object ID, and more.

We are now restricting the information that the openid scope affords your app access to. The openid scope will only allow your app to sign the user in, and receive an app-specific identifier for the user. If you want to obtain personally identifiable information (PII) about the user in your app, your app will need to request additional permissions from the user.

This is sadly classic Microsoft behavior – we know what’s good for you better then you know what’s good for you – and this horse has already left the barn; you can get this info today using the v1 auth endpoint. Never one to be deterred by logic however, they are pressing forward with this plan. That means more work on you, the developer. What you’ll want to do in order to get basic user info is a couple of things:

  1. Include the “email” and “profile” scopes when you are obtaining your code / token.
  2. Ask for both a code and id_token when you redirect to Azure asking for a code (as shown in the C# example above).
  3. Extract out the id_token results into a useable set of claims after you exchange your code for a token.

On the last point, the Microsoft documents say that they provide a library for doing this, but did not include any further detail about what it is or how you use it, so that was only marginally helpful. But hey, this is a tip, so here’s a little more. Here’s how you can extract out the contents of the id_token:

  1. Add the Security.IdentityModel.Tokens.Jwt NuGet package to your application.
  2. Create a new JwtSecurityToken instance from the id_token. Here’s a sample from my code:

JwtSecurityToken token = new JwtSecurityToken(ajt.IdToken);

  1. Use the Payload property of the token to find the individual user attributes that were included. Here’s a quick look at the most useful ones:

token.Payload[“name”] //display name
token.Payload[“oid”] //object ID
token.Payload[“preferred_username”] //upn usually
token.Payload[“tid”] //tenant ID

As noted above though in my description of the converged model, remember that not every account type will have every value. You need to account for circumstances when the Payload contents are different based on the type of account.


Tip #5 – Feel Free to Use the Classes I Created for Deserialization

I created some classes for deserializing the JSON returned from various service calls into objects that can be used for referring to things like the access token, refresh token, id_token, messages, events, contacts, etc. Feel free to take the examples attached to this posting and use them as needed.

Microsoft is updating its helper libraries to use Office 365 objects with v2 of the app model so you can use them as well; there is also a pre-release version of ADAL that you can use to work with access tokens, etc. For those of you rolling your own however (or who aren’t ready to fully jump onto the pre-release bandwagon) here are some code snippets from how I used them:

//to get the access token, refresh token, and id_token
AzureJsonToken ajt =

This next set is from some REST endpoints I created to test everything out:

//to get emails
Emails theMail = JsonConvert.DeserializeObject<Emails>(data);

//to get events
Events theEvent = JsonConvert.DeserializeObject<Events>(data);

//to get contacts
Contacts theContact = JsonConvert.DeserializeObject<Contacts>(data);

You end up with a nice little dataset on the client this way. Here’s an example of the basic email details that comes down to my client side script:


Finally, here’s it all pulled together, in a UI that only a Steve could love – using the v2 app model, some custom REST endpoints and a combination of jQuery and Angular to show the results (yes, I really did combine jQuery and Angular, which I know Angular people hate):








The new auth endpoint is out and available for testing now, but it’s not production ready. There’s actually a good amount of documentation out there – hats off to dstrockis at Microsoft, the writer who’s been pushing all the very good content out. There’s also a lot of mixed and conflicting documents though so try and follow some of the tips included here. The attachment to this posting includes sample classes and code so you can give it a spin yourself, but make sure you start out by at least reading about how to set up your new v2 applications here: You can also see all the Getting Started tutorials here: Finally, one last article that I recommend reading (short but useful):
You can download the attachment here:

Know When Your Azure Identity Won’t Work with Office 365 APIs

As those of you who are familiar with Office365Mon know, we heavily leverage the Office 365 APIs in our solution.  It’s been a key player in being able to issue now over 100 million health probes against Office 365.  I know and have talked to lots of you as well that are starting to build apps that leverage this same infrastructure for your own solutions.  As you develop these solutions based on the Office 365 APIs, it’s pretty important that you understand the scenarios where the Azure access token you get will and will not work to access Office 365 resources.

First, a couple of basics.  When you get an access token, for purposes of our conversation here today, the token represents your identity that is going to be used to access a resource in some way.  There are exceptions to this, i.e. app only tokens, but this post is about user identities and Office 365.  When you try and access a resource, you say here is my access token, I want do this with the content – for example, I am Steve, I want to read the email in my inbox.

The problem is this – what I just described is a common scenario, and it works well today with the Office 365 APIs.  But there are actually at least four scenarios, and you may be surprised to learn that the Office 365 APIs only work with one of them.  Part of the reason in writing this blog post is to make sure you all are aware of that, but also to hopefully drive a discussion with the folks that own the service so that they can give some consideration to expanding their support of these other scenarios in the future.  Here’s a quick run down on the scenarios that I’ve looked at so far; there may be others.

  1. I own or otherwise have direct rights to a resource – WORKS!  This is the first scenario I described above – for example, when I want to access the email in my inbox, or if I’m part of a SharePoint group in my Office 365 tenant and I want to access content in that site.
  2. I have been granted delegate rights to a mailbox – DOESN’T WORK!  In this scenario, I’ve been granted rights to another mailbox.  Now if open up Outlook for example I can read the mail in that mailbox no problem.  If I’m using the Exchange Web Services (EWS), I can access the mail in that mailbox.  But if I’m using the Office 365 APIs, it doesn’t work.
  3. I have been invited to a SharePoint Online site – DOESN’T WORK!  In this scenario I’ve been invited as an external user to a SharePoint Online site.  I use my Azure AD credentials to accept the invitation and I can connect to the site in the browser.  However if I try and use an Azure access token against that resource it fails with an access denied error.
  4. I have been added to an Azure tenant using the Azure B2B feature – DOESN’T WORK!  This is similar to #3 – after being added to the Azure tenant with the B2B feature I can be added to a SharePoint Online site and access it just fine in the browser.  However my Azure access token will only get me an access denied error if I try and use it on that site with the Office 365 APIs.

The key and common thread in all of these scenarios is that I am using my Azure AD identity.  It is a durable, immutable identity containing an immutable identifier known to Azure AD.  Even though I’m using that immutable identity, there is still a disconnect between it and all of the ways in which it has been granted access to resources in Office 365.  That is to say, there is a disconnect in the Office 365 APIs; in the browser applications they have this figured out.  Make sure you know these limitations, and let your favorite Microsoft human if you would like to these disconnects eliminated for a comprehensive and integrated identity and resource solution.


Thanks All for the Awesome 2015 Blog Stats

The stats helper monkeys prepared a 2015 annual report for this blog.  It was a GREAT year for the blog, with 440,000 views from people in 193 countries.  Glad you folks are using it!

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 440,000 times in 2015. If it were an exhibit at the Louvre Museum, it would take about 19 days for that many people to see it.

Click here to see the complete report.

Invalid Client Secret when Publishing Azure AD Secured Apps

Back to my old nemesis…the long very long blog post title.  🙂   I ran across this problem myself recently, and had seen someone else experience but not had the time to dig into it.  In short the problem goes something like this – you create a new ASP.NET web application in Visual Studio 2015.  You configure it to be secured with Azure AD (i.e. Work and School accounts).  You do your thing, you build your web site, you test it locally, you can authenticate and everything works fine – great!

Now you want to deploy the app to your Azure web site.  You go through the publishing wizard, which pushes the content up to your web site.  It launches the browser for you to log in and check out your site but – boom – your app blows up.  After you authenticate it redirects you back to your site and you get the dreaded yellow page of death (i.e. an unhandled exception).  When you turn customErrors to Off in web.config you can see the error is “invalid client secret”.  You know it works fine when you run it on your local machine, so how can it be invalid?

This is the question that plagued me for a couple of days before I finally had the time to completely unwind it.  This post is partially “here’s how you fix it” and partially “this is why I think it happens”.  In the two cases where I’ve seen this happen so far, the project started out targeting .NET 4.52, then was subsequently changed to 4.61.  I noticed that the publishing wizard changes the UI slightly when you do that.

When targeting 4.52 the wizard includes a checkbox that says “Enable Organizational Accounts”.  The default behavior is to have that box checked.  I always uncheck it because my “organizational account” configuration is completed when I’m building and testing the application.  When targeting 4.61 I no longer see this option in the UI.

So here’s the fix and here’s the guess at what’s wrong.  If you look in the Properties folder in your project you will find one or more .pubxml files, which represent your publishing profiles.  In this case, the .pubxml file contained a completely different ClientId and ClientSecret value than my web.config did.  It was that client ID and secret that was getting pushed up to the Azure web site, and that’s why my application blew up once it was published to Azure.  To fix it, I just manually copied the ID and secret from my web.config into my .pubxml file.

Now…my guess as to why I think it happens (I deleted some stuff before I could actually verify this), I think when you have that box checked in the wizard when targeting 4.5.2, Visual Studio creates a new application definition in Azure AD, and then pulls in the client ID and secret from it into the publishing wizard.  That would explain how the wrong client ID and secret gets published and “stuff breaks”.

Anyways, if you run across this problem hopefully you’ll find this post.  Good luck!

Newly Released – Analyze your Office 365 Outage Data in Power BI

We’re very happy today to announce the release of new integration between the Office365Mon reporting data and Power BI in Office 365. Office365Mon is used to monitor your SharePoint Online and Exchange Online tenants. Along the way it captures quite a bit of data related to outages in your tenants as well as performance data. There are several basic and advanced reports supplied with your Office365Mon subscription, but we wanted to dial things up a notch and give you even more flexibility to create the reports you want for your business.

To support that vision we partnered with Microsoft recently to build a Power BI content pack for your Office365Mon report data. The content pack has just been published and now is available for all Power BI users in Office 365. Here’s a screenshot of the dashboard:

This of course just serves as the starting point. You can customize the dashboard and reports as much as you like. You can also drill into these dashboard reports for greater detail, like you see here with the performance data:

The Power BI team published a great blog on the integration with Office365Mon so check it out for additional details and instructions for getting it set up for yourself: To generate the data for the content pack you just need to create an Office365Mon subscription. When you do, you’ll be an admin for the subscription, and then when you sign into Power BI using that same account you used to create your Office365Mon subscription you can create your dashboard.

We hope you find this new level of reporting and integration provides you a great view and insight into the quality of your Office 365 services.

From sunny Phoenix,


End of the Launch Pricing Model and Start of the Basic Monitoring Tier

November marks a couple of important milestones at Office365mon. The biggest news is that we have finally reached the size and strength in our customer base to make the transition out of our launch pricing model. That model allowed anyone to get an Office365Mon subscription and use all of the basic features free for life – monitor up to 10 sites and mailboxes, get email and text notifications, and use our basic reports. Getting the service running, customers engaged, and improving our features based on their feedback has been instrumental in establishing the Office365Mon service.

For customers that were willing to be an early adopter of our service, they will continue to benefit from their loyalty. Their subscriptions and basic monitoring services for those subscriptions will always be free for life. If we add more features to the basic monitoring feature over time, they will continue to reap the benefit of those changes as well.

Going forward, our launch pricing is going to conclude on November 30th. After that day, all Office365Mon subscriptions will be created as 90-day trials, the same as you get on all the features at Office365Mon. Getting signed up will be exactly as quick and easy as it is today. There won’t be any credit card info required up front – just go to the site, set up your subscription, and start monitoring. At the end of 90 days if you want to continue then you can sign up for whatever service level you prefer – Basic Monitoring, Enterprise features, or Enterprise Premium features. A complete list of what’s included in each of these packages can be found on our web site here. Monitoring services for subscriptions created after November 30th will start at $19 / month.

Meanwhile we are continuing to work on new features. In October we released one of the most innovative outage monitoring solutions yet – our Office 365 Help Desk feature. It’s described in more detail in this post: In short, it allows you to use your end users to learn about outages in a way that’s both very simple and nicely interactive for them. We set you up with phone numbers that users can send text messages to when they are having an outage. You can get multiple phone numbers for them to use, and you can get them in multiple geographies. Users don’t need to remember any special commands or anything at all – just add the phone numbers to their contact list, and send a text message to it when they are down. They don’t need to call a help desk number and work their way through the typical menu-heavy system, they don’t need to go to an internal portal, find the right page to report a problem, and fill out a form. Just a simple text message.

Meanwhile, you can configure your Office365Mon subscription to say how many messages you need to receive and in what time period before notifying you about the outage. For example, don’t notify me until I get at least 5 text messages in 3 minutes. You can also configure text messages that are returned to users that text in these outage notifications – that’s the interactive part. So they can get a message back that says “thanks, we’re looking into it”. Or after you reach that notification threshold you can send a different message back that says “thanks, we’re aware of the problem and we’re working on it”. Finally – it’s something that’s super quick, super easy, and both parties are getting some real time feedback. There’s a lot more to it – I recommend reading the post I linked to above and then giving it a try in your own Office365Mon subscription.

Speaking of subscriptions, we’ve also made it MUCH easier to create new subscriptions. This again comes from feedback from our users who were looking for an easier way to get monitoring set up for multiple sites and mailboxes. There are reasons why we do this though, but if you still want to set them up in the browser now it’s much easier to accomplish. The reasons around why we do this and how you can set them up more easily are covered in this blog post: Of course, you can also continue to do this lickety-split quick using our Subscription Management API. For more details on that please visit our site and look at our SDK and sample C# and PowerShell code:

Overall it’s been a great month and there are a lot more exciting things ahead. As always if you have feedback feel free to send it my way at

From sunny Phoenix,


How To Monitor Multiple Mailboxes and Sites with Office365Mon

As we’ve had more and more interest from customers wanting to monitor multiple mailboxes and sites with Office365Mon, I decided it was time to both make it easier to do and to explain some of the facts you need to keep in mind when monitoring multiple resources.

If you look at our pricing page you’ll see that with the Basic monitoring package you can monitor up to 10 sites and mailboxes. When you go into Configure your Office365Mon subscription though, you only see a place to add one mailbox and one site. That’s because we purposefully created Office365Mon to support one mailbox and one site per subscription. The reason for that is simple – based on our many years of working with Office 365, we found that in most cases, when you have a problem with one resource, you have a problem with them all. For example, it’s very rare that you have one SharePoint site down and the rest of the sites in the tenant up and working. Generally then, if you monitor a single mailbox or site in your tenant you’ll have a pretty good idea that if it’s down, so are your other resources and vice versa.

There are exceptions to that of course, and other reasons why you may want to monitor multiple resources – that’s why we give you up to 10 with Basic monitoring. In order to do that then, you just need to create multiple subscriptions. Each subscription monitors a different site and mailbox, so if you create 10 subscriptions that’s how you can monitor 10 mailboxes and sites. We’ve made the process of creating new subscriptions much easier so I wanted to cover that first.


Creating a New Subscription

If you go to the Configure Office365Mon page, you will see a button in the General Subscription Info section called Copy Subscription.

If you click that button, it creates a new subscription for you. When it does so it creates it with this configuration:

  • The Company Name is the same as the current subscription but has the date and time appended to it
  • The Contact Email is the same
  • All of the subscription admins are the same
  • All of the notification addresses (email addresses and text phone numbers) are the same
  • The outage duration to wait before sending notifications is the same (as shown in the picture below)

Here’s an example of a what the General Subscription Info looks like for a subscription that was copied:

After you copy your subscription, you will see a dropdown list of subscriptions near the top of the page:

It contains a list of all of your subscriptions so you can easily switch between the different subscriptions, whether you are configuring them, looking at reports, features, the My Info page, etc.


Adding More Mailboxes and Sites

From what I described at the beginning of this post, you know that you can now just navigate to each subscription and configure a mailbox and site for each one, and that’s how you’ll set up monitoring for multiple resources. You may notice then from the previous section, the only thing we don’t copy for you when duplicating a subscription are the resources being monitored. There’s also a simple reason for that – when you configure a resource for Office365Mon to monitor, you have to do so by logging in to the Office365Mon site with an account that has rights to that resource. For example, if you are adding a mailbox to monitor, you need to log in as an account that has rights to read the contents of the mailbox. If you are adding a site to monitor, you have to log in as an account that has at least Read rights to the site. So, if you want monitor 10 mailboxes and 10 sites for example, that means you have a few options:

  1. You can create one account and grant it rights to read every mailbox and every site you want to monitor.
  2. You can create a different account (or use existing ones) for each mailbox you want to monitor.  You can grant each account rights to a site that each one can monitor.
  3. Some combination of 1 and 2 – for example, use different accounts for each mailbox, but just use one account and grant it Read rights to different sites for monitoring SharePoint.

Account management is another reason that we start out with one subscription, site and mailbox. Most organizations do not want to create one account that has rights to multiple mailboxes. At Office365Mon we provide you the flexibility to go forward with whatever security model works best for you.

Once you’ve settled on your security model you need to add the account(s) as an Office365Mon admin to each subscription that they are configuring. For example, assume you create an account for monitoring called “mon1”, you create a mailbox for it and you grant it rights to a SharePoint site. Please note that “mon1” will also need an Office 365 license in order to get the mailbox and have rights to the site! After you’ve completed that configuration in Office 365, you need to log into Office365Mon using an account that is already a subscription admin. Then go to the Subscription Admins section for the subscription and add the “mon1” account, like this:

After you’ve done that you need to close the browser, then open a new browser window and log into the Configure Office365Mon page using the account you just added as an admin. Once you do that you can scroll down to the Cloud Resources section and add the mailbox UPN and SharePoint site Url to monitor as you would normally. Just repeat that process for each mailbox and site you want to monitor.

Hopefully the process makes sense now. As always though, if you have questions or just feedback or feature request for the product, please email us at

From sunny Phoenix,