New Office365 monitoring checks, caveats I've noticed

I am trying to get it working currently and not have to much success.

I got the non report ones working, minus sharepoint.

The Report ones, I configured everything I was told to, but the invoke-webrequest inside of get-graphapi returns nothing for some reason. So it errors out.

Did you have any issues similiar?

I got them all work but had to fix several bugs. Here is the list of bugs/fixes I reported (ticket 192561), but LM has not fully validated them. You might want to wait until LM releases newer versions. I also didn't verify all the data it provides (especially SP and ConfigSources).

• O365 Passwords with "$" and perhaps other symbols might have problems due to using double quotes instead of single quotes, change "##OFFICE365.PASS##" to '##OFFICE365.PASS##'
• Office365_SharepointOnline_SiteStatus appears to have the wrong AppliesTo, should be hasCategory("Office365") && office365.spoadminsite
• Office365_SharepointOnline_SiteStatus might show "More results were found but were not returned..." error, add “-Limit All” to the Get-SPOSite statements.
• Office365_Reports_OutlookEmailActivity always reports 0 received emails (I wish!). The code has “$count.Receive" instead of “$activity.Receive".
• Office365_Reports_OutlookEmailActivity and Office365_Reports_MicrosoftTeamsUserActivity gets 7 days’ worth of data and seems to pick only the oldest counts instead of the latest, other DataSources do a sort and picks the latest but these does not. You can copy the line from other DataSources.
• Office365_Reports_MicrosoftTeamsUserActivity might error with “The response content cannot be parsed because the Internet Explorer engine is not available..."Adding "-UseBasicParsing" to the "$query = Invoke-WebRequest" line.
• Office365_Reports_OneDriveFileCounts is likely using the wrong API. It's using getOneDriveUsageAccountCounts but I think it should be getOneDriveUsageFileCounts API instead. Changing that seems to fix it.
• The instance-based DataSource have problems with large environments where it times out a lot, sometimes with "0" instead of "No Data".

See if any of these help, else you might want to try temporarily remove the "| Out-Null" stuff to see if there are errors that are being suppressed, or try adding -Verbose to commands. Or you might want to make sure the AzureAD App stuff is setup correctly. I had LM registered as an App a while back but the directions LM provided looks to match my setup.

You might also want to try add the following line near the top of the scripts. This causes PowerShell to use TLS 1.2 for connections.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Our SharePoint team pointed out that they keep losing their SP instances for the Office365_SharepointOnline_SiteStatus DataSource causing dashboards to go blank. I found that many of the times when it makes an API call it gets a "ERROR: The remote server returned an error: (503) Server Unavailable" error and the AD script just assumes there is no sites so it removes all the instances because it has no error checking. I stuck the sometimes-failing codes inside a Try/Catch loop and some warning/error actions so the whole script can return non-zero exitCode letting AD knows it was a failed attempt and to ignore it. That will hopefully fix that issue.

try {
    Connect-SPOService -Url $spo_url -Credential $credential -WarningAction "SilentlyContinue" -ErrorAction "Stop" | Out-Null
    $sites = @(Get-SPOSite -Limit ALL -WarningAction "SilentlyContinue" -ErrorAction "Stop")
} catch {
    Write-Host "ERROR: $_"
    Exit 1
}

I think the other DataSource may also have a similar problem from lack of error checking.

Hm, that's not expected. The AD script should exit with a non-zero if there are errors.  Meaning to say, the developer should make the script exit with a non-zero if it encounters errors. Only if the script exists with a 0 will the results even be parsed. Looks like that's exactly the correction you made.

Hey @Mike Moniz thanks for the list here, I will get this to the ME team for fixing.