(V2) Allow users to pass custom function in Functions event definition

[Indigo744]

Hello,

First, let me say that your Powershell scripts are really good and super helpful 🐱

I am actually deploying PSWinReportingV2 in our AD in order to get AD changes report each morning. It is working great and I am able to get an email containing the summary with a dynamic HTML attached.

I noticed that the Group Policy changes was always empty. After some digging, I found out that I need to enable the audit for GPO changes (5136).

Now I can get the list of GPO changed in the report!

However, in the report, the changed GPOs are listed by their GUID only.
This is hard to get a quick understanding of which GPO was impacted, and also to find the real GPO.
I would love to be able to also get their name along with the GUID.

I noticed that the event definition has a Functions parameter that can apply a function to a specific field (here is an example).

My though was to provide a new function on the ObjectGuid field that hook up GPOZaurr to find the GPO with the GUID and return the real name.

Sadly, looking at the code behind it, I found out that the functions are hard-coded so I can't do this.

So to get to the proposal: I think it would be great if the user could provide a custom function that is automatically called.

The user could simply pass a script block or a function (using $FUNCTION:myCustomFn), and internally the script would do

$EventProperty.Value = Invoke-Command -ScriptBlock $EventsDefinition.Functions[$EventProperty.Name] -ArgumentList @($EventProperty.Value, $Event)

Notice the args list that pass the field value, and also the whole event (if needed).

Thank you and have a nice day!

[PrzemyslawKlys]

Good, that you figured it out. Having said that:

• I'm probably going to release new V1 and freeze it with static links to specific versions of modules
• I'm probably going to release new V2 and freeze it with static links to specific versions of modules

Having said that:

• There is new PSEventViewer (https://github.com/EvotecIT/PSEventViewer) which rebuilds the whole named events and brings them to whole new level, it will also "decrypt" guids and so on. It's already on version 2.4.3

$findWinEventSplat1 = @{
    Type        = 'ADGroupPolicyLinks'
    MachineName = 'AD1', 'AD2', 'AD0'
    Verbose     = $true
}

$findWinEventSplat2 = @{
    Type        = 'ADGroupPolicyEdits'
    MachineName = 'AD1', 'AD2', 'AD0'
    Verbose     = $true
}

$findWinEventSplat3 = @{
    Type        = 'ADGroupPolicyChanges'
    MachineName = 'AD1', 'AD2', 'AD0'
    Verbose     = $true
}

#$Test1 = Find-WinEvent @findWinEventSplat1 -TimePeriod Last7Days
#$Test1 | Format-Table *

$Test2 = Find-WinEvent @findWinEventSplat2 -TimePeriod CurrentDay
$Test2 | Format-Table

But version 3+ will be even more capable. I also rewrtote it completly in C#. Then i'm building HtmlForgeX which creates c# based emails and reports (https://github.com/EvotecIT/HtmlForgeX) which in turn will allow me to connect new version of PSEventViewer, new version of HtmlForgeX, and new version of Mailozaurr to deliver new PSWinReportingV3. It will be completly C# based project with powershell modules in place, but probably will allow different stuff like being a service as well.

[Indigo744]

Ah, another package and another version coming... 😅
You have so many repository! It's incredible the work you put into it. You can be proud.

If I understand correctly, you made another package to split this repo into the reporting part and the event reading part.
The reporting part will stays in this repo as "PSWinReportingV3", and the event reading part will be in PSEventViewer.

I guess I can understand... It will be easier to reuse and evolve 😺

As a side note, I noticed that you favour more C# with Powershell bindings these days than pure Powershell package. Is there a specific / technical reason (performance, easier workflow, strong-typing, ...) or is it just your personal preference that has evolved? Personal I do both if my $DAY job, and both have their strength but I'm interested to know your opinion.

Anyway, it seems you have quite a lot of work ahead! 😉

But in the meantime, can I suggest about adding my proposal to the current V2?
I can try to help and submit a PR if you don't want to spend too much time on it.

[PrzemyslawKlys]

C# is just easier to maintain in the long run. Strong typing, performance, parallel processing, easier access to existing packages, reuse of code. I still use a lot of PowerShell, just that now I prefer C# as starting point.

I'll take a look at your PR when i'll get some time while trying to release "closing" releases for V1 and V2, as I don't intend to work on them anymore.