volumes

Volumes of a Windows, by WinRM

Returns the size, the space used and the free space of each local volume of a Windows, those with a drive letter and those mounted in a folder. Four watches are proposed, each one set on the probe. The activity of the disks is the collector windows/winrm/diskio.

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 Win32_Volume:

[Console]::OutputEncoding = New-Object System.Text.UTF8Encoding; ConvertTo-Json -Compress -InputObject @(Get-CimInstance Win32_Volume -Filter 'DriveType=3' | Where-Object Capacity | Select-Object Name, Capacity, FreeSpace)

• WinRM hands the script to PowerShell itself: no shell stands in between, and the script is the one of windows/ssh/volumes, without the powershell -Command "…" that cmd.exe needs there. The default shell of an OpenSSH server does not matter here.
• Only volumes of the type "local disk" (DriveType 3) are read, and only those formatted (with a Capacity): network, removable and optical drives are not among them.
• A volume is named as Windows names it: C:`, or the folder where it is mounted (D:\Data`). A volume with neither, named `\?\Volume{…}` (a recovery or system partition), is left out.
• Sizes are in bytes, returned in GiB, rounded to a tenth.
• The output is written in UTF-8 without a byte order mark, so that a folder name outside ASCII reads right.
• Nothing is skipped at the first run.
• No local volume at all, or an answer that is not the expected JSON, stops the collector as misconfigured: a Windows always has its system volume.

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. No other group: Win32_Volume is open to any account.

Outputs

Watches

"Full within a week" needs the history of the volume: until the poller has learnt it, the watch says it is learning and raises nothing.

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.
• A USB disk that Windows announces as a local disk is counted.
• Not yet checked on a real Windows: that the output in UTF-8 reaches the poller as such through WinRM, and that setting the output encoding is accepted where WinRM runs PowerShell without a console (a refusal is an error beside the answer, which still arrives, with a folder name outside ASCII possibly misread); Win32_Volume read by an account without administrator rights.