M365 Services Supplemental Monitoring Management Pack v3


2023.07.31: Update – Due to recent changes in Azure/Graph the Services management pack now requires the user account to be assigned the “Message Center Reader” role. We plan to update the MP guide in the near future.
(Ref: https://monitoringguys.com/2023/07/28/graph-api-healthoverviews-403-forbidden/ ).

We recently updated v3 of the M365 Services Supplemental MP to provide some performance improvements, feature enhancements and address a few general housekeeping items, we are excited to announce it is now available for download! We strive to deliver a streamlined and easy to implement monitoring solution for your organizational M365 monitoring needs! We have added and updated our real-time service test Console tasks to ease the pain of troubleshooting and verifying service disruptions. We have integrated the Microsoft Teams Network Assessment Tool in this release with performance metrics for Network Jitter, Packet Loss, and Round Trip Latency. Some of the v3 updates are listed below and are also explained in the video tutorial/walk-through. Make sure to follow us on Twitter @MonitoringGuys!

Detailed walkthrough of App registration, M365 user accounts, SPO/Teams requirements, and MP configurations.



Version History

v3.0.1.28 Updates:

  • Improved error handling and logging for throttling scenarios.
  • ExchangeOnline: Added logic to identify and parse optional JSON UPN/SMTPEmailAddress from Sender/Receiver email address values in Exchange watcher config. In rare circumstances the UPN may differ from the SMTPEmailAddress for an account. Email address fields now accept optional JSON object in the following format: {“UPN”:  “account@domain.name”,”EmailAddress”:  “email@domain.name”}
  • ExchangeOnline: Updated function M365Receive to retrieve from specific folder: Inbox. Improved reliability of test message receipt metrics.
  • Teams Network Assessment Tool: Upon installation/reinstallation of TNAT, added logic to preserve (rename) existing config file if it exists.
  • Watcher node configuration (new/modify): Improved on-demand discovery; Fixed ModifyWatcherConfig on-demand discovery target name; correctly triggers WatcherNode discovery now.
  • License: Updated license sku display names.
  • Teams Calendar: Updated the Delete logic (which really, strangely only cancelled the event) to a ‘Cancel’ which actually cancels the event AND “The action moves the event to the Deleted Items folder.”
    Cancel: https://learn.microsoft.com/en-us/graph/api/event-cancel?view=graph-rest-1.0&tabs=http
    Delete: https://learn.microsoft.com/en-us/graph/api/event-delete?view=graph-rest-1.0&tabs=http

v3.0.1.5 Updates:

  • Improved Get-AccessToken and Get-StandardToken logging. Fixed Services workflows auth token request.
  • M365ST.TeamsMon.ps1 – Moved the $RequestDelayMS before the stopwatch timer in Verification section.
  • M365ST.TeamsCalendarMon.ps1 **Added**


v3.0.1.0 Updates:

  • Improved cleanup routine; added SentItems, added delay between delete operations. Set interval to 86400. Increased MaxItemsToDelete default value.
  • Added OnDemand discovery for all m365 class types to the Watcher node “modify configuration” task.
  • Added throttling logic to address recent Graph throttling issues:
    Exception: System.Net.WebException: The server committed a protocol violation. Section=ResponseStatusLine
  • Hardcoded synctime vars for all workflows to help evenly disperse requests to Graph to avoid throttling.
  • Changed all configuration tasks IntervalSeconds from $TargetHost property to LEAVE_BLANK_TO_INHERIT_DEFAULT_VALUE
  • Corrected numerous monitor Category tags. Many performance monitors were set as default AvailabilityHealth; updated to PerformanceHealth.
  • Added additional rules and monitors for Licenses
    Added rules:
    M365 License – Licenses Consumed (Units) Performance Collection Rule
    M365 License – Licenses Available (%) Performance Collection Rule
    Added monitors:
    M365 License – Licenses Consumed (Units) Monitor
    M365 License – Licenses Available (Units) Monitor
  • Library, Services, License: Password/ClientSecret Decode and Get-StandardToken functions now log critical failures and exit immediately.
    Updated: M365 – Script Resource Library Failure Repeated Event Detection Monitor
    TimerResetSeconds, old:3600, new:$Target/Property…/IntervalSeconds$
    Updated: M365 – Script Failure Repeated Event Detection Monitor
    999[5-6]|999[8-9]
    TimerResetSeconds, old:3600, new:$Target/Property…/IntervalSeconds$
    Added: M365 – AuthToken Retrieval Failure Repeated Event Detection Monitor
  • SharePoint, OneDrive: Changed AlertOn from Error to Warning for performance unit monitors.
  • Teams: added TNAT discovery GUID to the “Modify Teams Config” agent task OnDemandDiscovery.
  • SharePoint: Fixed duplicate name issue. Graph has been known to return duplicate identical site entries.
  • Updated a few knowledge articles. Improved a couple class DisplayNames.

Thanks!
The Monitoring Guys

2 Replies to “M365 Services Supplemental Monitoring Management Pack v3”

  1. Hi. Thank you for m365 supplemental pack and we site. I was unable to run task on a dedicated watcher node (scom files were missing from that server). I was able assign my management server as a watcher node (it had the files needed) and it populates the registry, but the management server is not showing as a watcher node under M365 supplemental section. It does have a profile for the action account that ran the task. Any idea how I can get the MS to appear as a watcher node so I can see/run the associated exchange teams share point tasks? Thank you. Gary

    1. If you see an error about files not available when you run the task, it’s usually because the MP was recently imported and the resource files referenced in the workflow haven’t been delivered to the agent cache directory yet. If you wait a few minutes then try again, you should see success.

      A word about the security profile:
      It’s not super common to use the provided security profile with this management pack, but it exists nonetheless for those rare circumstances. The important thing is that whichever account context was used to run the Config task(s), this same account must be used for the workflows and therefore must be included in the profile and assigned to the instance (if other than the Default).
      Most of the time the profile is not needed or used and everything just works fine/easier; Run the Config tasks as the default context, the workflows run as the same default context. Easy, peasy.

      As for the initial watcher node discovery, this should be pretty straightforward because the discovery just identifies the values which get stored in the registry. Run the Watcher config task again and look closely to the output from the task. Make sure there are no errors in the output.

Leave a Reply

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