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

[jimbanach]

Hi,

Thanks for the feedback. Strict Mode is not something we had tested against, but we will look into it for the next update.

Item 1 - We find that many times the policies are given custom or unique names. Although we encourage using those as guided, it's not something we've been able to guarantee.

Item 2 - Thank you. It may have been leftover form previous versions. We'll test and remove in future versions as not needed

Item 3 - This is a global variable that in our testing will return true on Mac and Linux systems running PS7 but is not defined in PS 5 on Windows.

Item 4. - We chose this route as the compliance search query only returns detailed information such as locations (SharePoint, exchange etc.) if you query them one at a time. We don't have an ETA on a fix to the cmdlet.

[jimbanach]

New Version cleaned up all of the versions except for doing a test for strict mode.

Underlying cmdlet still does not pull all the details of a compliance search unless queried individually (hoping that new ediscovery features will allow that). Shortened the time by only looking at searches made around the time of the engagement itself to prevent pulling queries that are months or years older.