banshee/active-directory-collection/active-directory/winrm/gpo

Group Policy errors, by WinRM

Returns the number of Group Policy processing errors written to the System log of a Windows since the previous run, and their event identifiers. One watch is proposed, unchecked: some of these errors are transient, and only the administrator knows which rate is not.

How it works

Microsoft has Group Policy write its errors in the System log, and starts its troubleshooting there (Microsoft, "Applying Group Policy troubleshooting guidance"). Each event of the log has a record number, EventRecordID, which only grows. The collector keeps in the cache of the probe the highest number it has counted, and counts at the next run the errors (level 2) of the provider Microsoft-Windows-GroupPolicy above it, as the windows/winrm/eventlog collector of banshee/windows-collection counts all errors.

The first run only notes the number of the latest event, and is skipped:

`` (Get-WinEvent -LogName System -MaxEvents 1).RecordId ``

The following runs count the Group Policy errors above the number kept (here 12345), and read the number of the latest event of the log:

`` $ErrorActionPreference = 'Stop'; $events = @(Get-WinEvent -LogName System -ErrorAction SilentlyContinue -FilterXPath '*[System[Provider[@Name=''Microsoft-Windows-GroupPolicy''] and Level=2 and EventRecordID>12345]]'); ConvertTo-Json -Compress -InputObject @{newest = [long](Get-WinEvent -LogName System -MaxEvents 1).RecordId; last = [long]($events | Measure-Object RecordId -Maximum).Maximum; errors = $events.Count; ids = (@($events | Select-Object -ExpandProperty Id -Unique) -join ', ')} ``

WinRM hands the scripts to PowerShell itself: they are those of active-directory/ssh/gpo, without the powershell -Command "…" that cmd.exe needs there.
events lists the event identifiers of the errors counted, once each: 1058 (a gpt.ini not read from SYSVOL), 1030 (the list of policies not retrieved), 1129 (no domain controller reached)… Microsoft explains each one in the guidance above. A run without error returns an empty text.
An event written during the reading has a higher number and is counted at the next run: none is counted twice, none is lost. A log that was cleared is seen, and counting starts again from its start at the next run. The number kept lasts a week in the cache.
Any failure other than "no event found", an access to the log refused among them, stops the collector as misconfigured, rather than return zero errors.

Nothing is written to the Windows: the scripts only read.

Prerequisites

A Windows Server 2012 or later, a domain controller or a member of the domain, with Windows PowerShell 3.0 or later.
The WinRM service listening in HTTPS, on TCP 5986 or the port set in protocol:winrm:port, open in the Windows firewall to the poller, with a certificate the poller judges by the TLS profile of the probe or pins in protocol:winrm:fingerprint: the steps are those of the windows/winrm/services collector of banshee/windows-collection. NTLM authentication, which the WinRM service accepts as installed.
An account for monitoring, without administrator rights, set in protocol:winrm:user (DOMAIN\account or account@domain) with its password in protocol:winrm:password, member of the groups "Remote Management Users" and "Event Log Readers" (of the domain on a domain controller, local elsewhere), so that the System log is not refused to it.

Outputs

Name	Label	Unit	Per instance
`errors`	Group Policy errors since the previous run	—	no
`events`	Their event identifiers	—	no

Watches

Name	Title	Kind	Defaults	Checked by default
`errors`	Group Policy errors	high threshold, on `errors`	warning above 0; no critical	no

Limits

Microsoft calls event 1129 "a transient condition" when the domain controller cannot be reached, as at a startup before the network is up: one such error a day may be routine. Check the watch, with the thresholds the host deserves, once its usual rate is known.
The errors are counted on the computer that applies the policies: watch each domain controller, and the members whose policies matter.
Not yet checked on a real Windows: the execution; that the errors of Group Policy in the System log carry the provider Microsoft-Windows-GroupPolicy, the name of the publisher of its operational log Microsoft-Windows-GroupPolicy/Operational, which Microsoft names; Microsoft does not write the provider of the System log events in its guidance.