Even though accounts, setup, and licensing requirements are demonstrated very well in a video here, I occasionally get questions asking for more clarity. That’s OK, I completely understand that M365 services, Microsoft Graph, and related licensing can be a bit overwhelming at first. I took me a little while to wrap my head around all of it. I figured it would make sense to document some common answers to some common questions. If I’m being totally honest, I had to rewatch my video (linked above) and inspect my lab environment while writing this article to refresh my memory on exactly how it all works.

– Author and fellow SCOM nerd

How many accounts and licenses do I need?

Each service (OneDrive, SharePoint, Exchange, Team, License, Services, Library) needs to use both a client ID/secret and a user/pass to authenticate and interact with Graph. Each service, when configured (with each individual config task) provides you with the opportunity to provide client ID/secret and user/pass. Theoretically, you could use a different client ID and user account for each service but that would be incredibly rare and IMO over complicated, but it is possible for those sticklers out there. This solution was designed to be flexible but also as simple as possible.

Typically, you would use a single account for pretty much everything except for an onprem mail account and a Teams chat partner account, explained below.

What this would look like is upon initial configuration of the watcher node you provide the auth info: client ID/secret, user/pass.  In my lab my primary M365 account is:

Every other service can inherit these values automatically in their respective configuration tasks.

Here’s an example of the OneDrive configuration task. You can see how the client and account values indicate that they will be inherited from the Watcher and need no further input.

The only exception is MailFlow which can inherit the client ID/secret but you must explicitly provide:

  • M365 Sender – This can be the same account as Receiver, in my case: scom2
  • M365 Receiver – This can be the same account as Sender, in my case: scom1
  • Exchange Sender – Must be an onprem account. Can be the same as Exchange Receiver. (Hybrid scenario only. Otherwise, leave blank.)
  • Exchange Receiver – (hybrid scenario only) Must be an onprem account. Can be the same as Exchange Sender. (Hybrid scenario only. Otherwise, leave blank.)

With the Teams config you can optionally provide a chat partner account name. This chat partner account must be different than your primary Teams account. If you provide a chat parent account name this will cause the chat partner object to become discovered for which the chat partner monitoring workflows will run. If you don’t provide a chat partner account, no chat monitoring will exist.

In my case, my primary Teams account as mentioned above is scom1. I simply let it be inherited from the Watcher, just like all the other services*.  My chat partner account is scom2, which I provided during Teams configuration in the config task.


Any M365 account that uses Exchange Online, SharePoint Online (OneDrive), or Teams will require a license for that service.
In my case:

  • scom1 – M365 Exchange, SharePoint, Teams
  • scom2 – M365 Exchange, Teams
  • onprem If I had an onprem exchange account, it would require zero M365 licenses.

UPN/Email Disparity

Note: MailFlow Sender/Recipient address fields now support UPN/email disparity. In the rare occasion where the email address is different than the UPN you can provide a JSON structure to represent the UPN and email address.

Example format:

{“UPN”:  “account@domain.com”,”EmailAddress”:  “email@domain.com”}

You can test your Sender/Receiver value with the following PowerShell command:

  Convertfrom-Json '{"UPN":  "account@domain.com","EmailAddress":  "email@domain.com"}'

Examples from my lab



Leave a Reply

Your email address will not be published. Required fields are marked *