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.
“This solution was designed to be flexible but simple.”
– 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 on-prem 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.
Licenses
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
MailFlow
Teams
Help! I updated my WatcherNode credentials, but the changes aren’t discovered on my individual services.
If you update your credentials (default user/pass, ClientID/ClientSecret) on the WatcherNode you should eventually see those changes reflected (discovered) for your individual services in their respective state views. If the updates don’t trickle down to the services, then it’s possible that you may have accidentally configured credentials directly on the individual service objects at some point so that they never inherit from the top-level WatcherNode. This is easy to verify and easy to fix.
Verify if credential settings exist on the individual service objects:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\MP\M365SSM\MgmtGroups\*\WatcherNode\*\*" | Format-List PSPath, "M365_ClientID","M365_ClientSecret","M365_AccountName", "M365_AccountPassword"Notice in the screenshot below that credentials exist for both Services and SharePoint services? This would prevent both of these services from inheriting credential updates from changes made to the “top level” WatcherNode configuration.
Remember, just because the ability to configure credentials at the individual service level exists, doesn’t mean that it’s appropriate or necessary. In fact, it’s rarely appropriate/needed. In the example above, these entries are a mistake and should be removed to allow credential inheritance for Services and SharePoint objects.
This can be remedied easily with the following commands.
First, run a “WHAT IF” test to see what would be removed. This changes nothing, it’s just a harmless test:
"M365_ClientID","M365_ClientSecret","M365_AccountName", "M365_AccountPassword" | %{Remove-ItemProperty "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\MP\M365SSM\MgmtGroups*\WatcherNode**" -Name $_ -Verbose -WhatIf }
I can see in the output that this would affect only Services and SharePoint settings. Perfect.
Once you feel warm and fuzzy with the test results, proceed to clean out the problematic credentials:
Now you can run the verification command again:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\MP\M365SSM\MgmtGroups\*\WatcherNode\*\*" | Format-List PSPath, "M365_ClientID","M365_ClientSecret","M365_AccountName", "M365_AccountPassword"
In the output we can see there are no individual service credentials or client secrets. Inheritance should resume normally upon the next discovery workflow cycle.
