banshee is under active development: collectors will keep changing, and a version you publish will likely need adjustments. For stable use, wait for version 1.0.0.

Windows

banshee/windows-collection/windows/winrm/

uptime

The time since a Windows started, and its recent restart, by WinRM and PowerShell

  • windows
  • winrm
  • powershell
  • uptime

by banshee1 installation2 versions

v2Latest

Published on October 28, 2026. One naming convention across collections; documentation completed.

Uptime of a Windows, by WinRM

Returns the time since a Windows started, in hours. One watch is proposed, set on the probe: the recent reboot.

Versions

Windows Server 2012 and later, Windows 8 and later: Windows PowerShell 3.0, which the collector needs, ships with each of them; the WinRM service runs by default on every Windows Server from 2012 on, and winrm quickconfig starts it on a desktop Windows. Generic: no folder of version. That every release answers alike is assumed, not yet checked on a real Windows.

How it works

The collector runs one PowerShell script, by WinRM, that reads the raw counter SystemUpTime of Win32_PerfRawData_PerfOS_System:

Get-CimInstance Win32_PerfRawData_PerfOS_System | Select-Object SystemUpTime, Timestamp_Object, Frequency_Object | ConvertTo-Json -Compress
  • WinRM hands the script to PowerShell itself: no shell stands in between, and the script is the one of windows/ssh/uptime, without the powershell -Command "…" that cmd.exe needs there. The default shell of an OpenSSH server does not matter here.
  • SystemUpTime is the instant the system started, Timestamp_Object the instant of the reading, both in ticks of Frequency_Object: the time since start is their difference over the frequency, returned in hours, rounded to a hundredth.
  • All three are integers: no date, no time zone and no change of summer time to read.
  • A restart shows as a time since boot shorter than the threshold of "Recent reboot".
  • Nothing is skipped at the first run.
  • An answer that is not the expected JSON stops the collector as misconfigured.

Nothing is written to the Windows: the script only reads.

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 "Performance Monitor Users": the collector reads a performance counter, which Windows refuses outside this group to a WinRM session, a network logon.

Outputs

NameLabelUnitPer instance
uptimeTime since boothno

Watches

NameTitleKindDefaultsChecked by default
rebootedRecent rebootbelow a threshold, on uptimewarning below 0.5 h; no criticalyes

A restart is seen only while the time since start is under the threshold: with the default, the watch stays raised for the first half hour after the start, then clears by itself. A probe that runs less often than the threshold can miss a restart.

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.
  • With the "Fast startup" of Windows 8 and later desktops, a shutdown followed by a start is not a restart of the system: the time since start then goes on. A restart, from the Start menu or by an update, is one.
  • Not yet checked on a real Windows: that "Performance Monitor Users" is the group a WinRM session needs for the counter.