eventlog

System log of a Windows, by WinRM

Returns the number of errors and of critical events written to the System log of a Windows since the previous run. Two watches are proposed, both unchecked: on most servers a few errors a day are routine, and only the administrator knows which level is not.

How it works

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) and the critical events (level 1) above it. Its scripts run by WinRM.

• 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 events 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[(Level=1 or 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; critical = @($events | Where-Object Level -eq 1).Count; errors = @($events | Where-Object Level -eq 2).Count} ``

• WinRM hands each script to PowerShell itself: no shell stands in between, and the scripts are those of windows/ssh/eventlog, without the powershell -Command "…" that cmd.exe needs there. The default shell of an OpenSSH server, which would read the $ of these scripts too early, does not matter here.
• The number kept becomes the highest of the errors counted. An event written during the reading has a higher number and is counted at the next run: none is counted twice, none is lost.
• Get-WinEvent reports "no event found" as an error, silenced on the reading of the errors. Any other failure, an access to the log refused among them, stops the script on the reading of the latest event, with no answer: the collector then stops as misconfigured, rather than return zero errors.
• A log that was cleared numbers its events from 1 again: the collector sees it, skips the run, and counts again from the start of the log at the next run.
• The number kept lasts a week in the cache: a probe stopped longer starts again as at its first run.

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

Prerequisites

• The WinRM service of Windows listening in HTTPS. The service runs by default on every Windows Server from 2012 on (on a desktop Windows, winrm quickconfig starts it), with an HTTP listener only; the HTTPS listener needs a certificate: - a certificate for server authentication in the store of the computer (Cert:\LocalMachine\My), bearing the name the poller connects to: issued by the authority of the company, or made on the server by New-SelfSignedCertificate -DnsName <name> -CertStoreLocation Cert:\LocalMachine\My from Windows Server 2012 R2 on (Windows Server 2012 does not have this command); - then the listener: winrm quickconfig -transport:https finds a certificate of an authority by itself, but refuses a self-signed one; the command that takes either, on every Windows from Server 2012 on, is winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<name>";CertificateThumbprint="<thumbprint>"} in cmd.exe, the thumbprint being the one Windows shows for the certificate.
• The Windows firewall open to the poller on TCP 5986, which creating the listener does not do: New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound -Protocol TCP -LocalPort 5986 -Action Allow in PowerShell. A listener on another port is set in protocol:winrm:port.
• The certificate judged by the poller before the account is sent, by the TLS profile of the probe: issued by an authority the system of the poller knows, by an authority added in protocol:tls:authorities, or pinned in protocol:winrm:fingerprint, the way for a self-signed certificate; the pin is not needed when the Security settings trust the first WinRM fingerprint presented. The fingerprint is sha256: followed by the SHA-256 of the certificate in 64 lower-case hexadecimal characters; from a machine that reaches the port, openssl s_client -connect <name>:5986 </dev/null | openssl x509 -noout -fingerprint -sha256 prints it, in capitals, with colons to take off. A certificate whose name is not the address of the host is judged on the name set in protocol:tls:server-name.
• NTLM authentication, which the WinRM service accepts as installed (Negotiate = true in winrm get winrm/config/service/auth): the password never travels, only an answer computed with it. A domain that refuses NTLM is not served.
• Windows PowerShell 3.0 or later, as shipped with every Windows from Server 2012 and Windows 8 on (3.0 on Server 2012, 4.0 on 2012 R2, 5.1 from 2016 on).
• An account for monitoring, without administrator rights, local or of the domain, set in protocol:winrm:user (account, DOMAIN\account or account@domain) with its password in protocol:winrm:password, member of the local group "Remote Management Users", which opens WinRM to an account that is not an administrator. Also a member of "Event Log Readers": Windows refuses the System log outside this group to a WinRM session, a network logon.

Outputs

Watches

A watch raised by the errors of one run clears at the next run without errors: the count is that of one interval.

Limits

• A certificate of the listener that expires, or a pinned one that is renewed, stops every WinRM collector of the host: the network/tls/certificate collector of banshee/web-collection, deployed on port 5986, watches it.
• Only the System log is read; neither the Application log nor the others.
• The events are counted, not described: their source and their message are read in the Event Viewer.
• A run where thousands of errors arrive reads them all, to count them.
• Not yet checked on a real Windows: that the record numbers start again from 1 after the log is cleared; that "Event Log Readers" is the group a WinRM session needs for the System log.