banshee/windows-collection/windows/winrm/
sessions
The sessions open on a Windows, in use and disconnected, by WinRM and PowerShell
by banshee1 installation2 versions
v2Latest
Published on October 28, 2026. One naming convention across collections; documentation completed.
Sessions of a Windows, by WinRM
Returns the number of sessions open on a Windows: those in use, at the console as by Remote Desktop, and those left disconnected, which keep their programs and their memory. Two watches are proposed, both unchecked: what is normal depends on the server, a jump host or a server without sessions.
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, and serves the class read under the same name, is assumed, not yet checked on a real Windows.
How it works
The collector runs one PowerShell script, by WinRM, that reads the counters of the Terminal Services object:
Get-CimInstance Win32_PerfRawData_LocalSessionManager_TerminalServices | Select-Object ActiveSessions, InactiveSessions | ConvertTo-Json -Compress - WinRM hands the script to PowerShell itself: no shell stands in between, and the script is the one of
windows/ssh/sessions, without thepowershell -Command "…"thatcmd.exeneeds there. The default shell of an OpenSSH server does not matter here. ActiveSessionscounts the sessions in use,InactiveSessionsthe disconnected ones; the open sessions are both together.- The names of the class and its counters are English whatever the language of Windows, where the output of
quseris translated. - Nothing is skipped at the first run: they are counts, not counters.
- An answer that is not the expected JSON stops the collector as misconfigured: a count of zero is never returned for a class that did not answer.
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 quickconfigstarts 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 byNew-SelfSignedCertificate -DnsName <name> -CertStoreLocation Cert:\LocalMachine\Myfrom Windows Server 2012 R2 on (Windows Server 2012 does not have this command); - then the listener:winrm quickconfig -transport:httpsfinds 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, iswinrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="<name>";CertificateThumbprint="<thumbprint>"}incmd.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 Allowin PowerShell. A listener on another port is set inprotocol: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 inprotocol: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 issha256: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 -sha256prints 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 inprotocol:tls:server-name. - NTLM authentication, which the WinRM service accepts as installed (
Negotiate = trueinwinrm 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\accountoraccount@domain) with its password inprotocol: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 performance counters, which Windows refuses outside this group to a WinRM session, a network logon.
Outputs
| Name | Label | Unit | Per instance |
|---|---|---|---|
sessions | Open sessions | — | no |
active | Sessions in use | — | no |
disconnected | Disconnected sessions | — | no |
Watches
| Name | Title | Kind | Defaults | Checked by default |
|---|---|---|---|---|
too-many | Too many open sessions | above a threshold, on sessions | no threshold: to set on the probe | no |
disconnected | Disconnected sessions left open | above a threshold, on disconnected | no threshold: to set on the probe | no |
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/certificatecollector ofbanshee/web-collection, deployed on port 5986, watches it. - Only the numbers are served: neither the names of the users nor the age of their sessions.
- Not yet checked on a real Windows: the name of the class on each version of Windows, and which sessions it counts, the session of the services (session 0), the console without anyone logged on and the WinRM sessions, the collector's own among them; that "Performance Monitor Users" is the group a WinRM session needs for the counters.