Several bugs / problems in EngagementPOEReports.ps1

[SaschaSeipp]

Given that this script is provided from Microsoft to partners to be run on customer's sites, I (representing a customer) am somewhat disappointed, as I had to fix the script before it was able to give the intended results. Some of it was certainly due to the fact that I generally use StrictMode enabled, but it would be good form to prepare for that, I think. (Or at least check for or explicitly disable StrictMode during the script run).

We have been using version 3.0 of the script.

1. The script is gathering ALL compliance searches (and DLP policies) in the tenant. Given that the MS engagement provides naming conventions for those objects created during the engagement, it should be easy to filter for them. The other existing searches etc. are of no concern to Microsoft and should not be part of the report.
2. Around line 246, a variable $coveredsits is used that is defined nowhere. With StrictMode enabled, the whole $itemtable and consequently the $POEChart cannot be created because of that, even though the rest of the data is there.
3. Around line 290, the variables $IsMacOS and $IsLinux also are nowhere defined (I assume they will not magically be set to true on a Mac or Linux system?), so again, with StrictMode enabled, the whole if / then fails, and one has to find and open the created HTML report manually.
4. "Section 2" of the script, around line 230, seems a little illogical: First you get all Compliance searches into $search, and in the next line, when going through these searches, you again get them one by one from the API, when the objects are already in the array. Especially given that Get-ComplianceSearch is not really fast, this is quite unnecessary.

I hope this helps in improving the script, so it can run more smoothly for future engagements.

Best regards Sascha Seipp