Severity: Warning

Files:

• setup/taskschd/ServyFailureEmail.ps1
• setup/taskschd/Get-ServyLastErrors.ps1

Lines: ServyFailureEmail.ps1:25 (claim), ServyFailureEmail.ps1:204 (dot-source), Get-ServyLastErrors.ps1:1 (incompatible directive).

Code:

# ServyFailureEmail.ps1 lines 24-26
Requirements:
  - PowerShell 2.0 or later (Compatible with legacy Windows Server environments).

# ServyFailureEmail.ps1 line 204
. $helperScript    # dot-sources Get-ServyLastErrors.ps1

# Get-ServyLastErrors.ps1 line 1
#Requires -Version 3.0

Explanation:
The script's own NOTES block advertises PowerShell 2.0+ compatibility and the body even contains explicit $PSVersionTable.PSVersion.Major -ge 3 branches (line 47, 132 of the notification script) to support PS 2.0. But the very next thing it does is dot-source Get-ServyLastErrors.ps1, which carries #Requires -Version 3.0 at the top.

On a real PowerShell 2.0 host, the dot-source will fail at parse time with:

The script 'Get-ServyLastErrors.ps1' cannot be run because it contained a "#requires" statement at line 1 for PowerShell 3.0...

So the email script is, in practice, PS 3.0+ only. Either the documented PS 2.0 promise is wrong, or the helper's #Requires is overly strict.

Suggested fix:
Pick one and align everything to it:

1. If PS 2.0 is the target: Remove #Requires -Version 3.0 from Get-ServyLastErrors.ps1. Replace Get-WinEvent -FilterHashtable with a PS 2.0-safe equivalent (e.g. Get-WinEvent -FilterXPath or Get-EventLog -Source Servy -EntryType Error) and remove -FilterHashtable usage.
2. If PS 3.0+ is the real target (more realistic given Get-WinEvent usage): Update the NOTES blocks of both ServyFailureEmail.ps1 and the dead PSVersionTable.PSVersion.Major -ge 3 branches to drop the PS 2.0 claim, and add #Requires -Version 3.0 to ServyFailureEmail.ps1 itself so the failure is loud and immediate instead of a confusing dot-source error.