Windows 10 since Feature level 1607 aka Windows Server 2016

This can be implemented as a more generic item that returns JSON with multiple version parameters (product name, build number, patch, etc). Because various users can be interested in various version components.

Something like this: system.sw.os.get[]:

{
    "product_name": "Windows 10",
    "version": "21H1",
    "build": "12345.1234",
    "version_full": "Windows 10 21H1 12345.1234"
}

Then, in Windows by Zabbix agent template, we can make version_full a dependent item that is monitored for a change by the trigger "OS version has changed". We should also check if older Windows versions can provide this info somehow.

The same system.sw.os.get[] can be also implemented for Linuxes (other Unixes - not sure, maybe) for the most popular distributions (RHEL, Debian, etc).

That sounds awesome! Just keep in mind, that it would be very important, to get the exact build number. I've seen countless products in the past, where only the major build number was monitored, which is nearly worthless, in regard to patchlevel monitoring. We currently solve that as following:

UserParameter=xenadmin.OSVersion,powershell.exe -NoProfile -NoLogo -ExecutionPolicy Bypass -Command "(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name CurrentBuild).CurrentBuild + \".\" + (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name UBR).UBR"

Regarding the older Windows builds, for Windows Server this started with 2016. Which is okay for us, as Windows Server 2012 dies October 2023.
For Clients, it was introduced sometime between Windows 10 1507 and 1607.

I would love to see the specifications, once they are ready, as we rely heavily on Windows OS monitoring.

Maybe it should also become a part of the official Zabbix Windows OS template!?

Mini spec (v1.2)

Currently system.sw.os item key is supported only for Linux OS. It is required that we add support for this key also on Windows OS, as well as, add a new item key system.sw.os.get for Linux and Windows that would yield json with system version information.

Use Cases

Case 1: User wants to get system version information for Windows OS.

1. User created new item of type Zabbix agent or Zabbix agent (active).
2. Set item key to system.sw.os.
3. Agent now reports OS version of the host.

What's affected:

• Agent
• Agent 2
• Frontend
• Templates
• Documentation

JSON format of system.sw.os.get[]

For Windows OS (depending on the system version) we can collect following information:

• "os_type" - type of operating system
• "product_name" - Windows OS name
• "architecture" - Targeted processor architecture
• "build_number" - Build number of the OS
• "build_revision" - Revision of the current build of the OS (win 7 and up)
• "build" - String representation of build and revision
• "edition" - Edition of the OS (win 7 and up)
• "composition" - Additional edition name of the OS (version ≥ 6.3)
• "display_version" - Display name of the version (version ≥ 6.3)
• "sp_version" - Service pack version (version < 6.3)
• "sp_build" - Service pack build number (version < 6.3)
• "version" - Version number (6.3 after win 8)
• "version_pretty" - Text representation of the data gathered
• "version_full" - OS name + BuildLab (BuildLabEx for win7and up) + Build

{
	"os_type": "windows",
	"product_name": "Windows 11 Pro",	
	"architecture":	"x86_64",									
	"build_number": "22621",												
	"build_revision": "674",
	"build": "22621.674",											
	"edition": "Professional",											
	"composition": "Enterprise",										
	"display_version": "22H2",											
	"sp_version": "Service Pack 1",								
	"sp_build": "1130",												
	"version": "6.1",										
	"version_pretty": "Windows 7 Ultimate Build 7601.21214 Service Pack 1",
	"version_full": "Windows 7 Ultimate 7601.24214.amd64fre.win7sp1_Idr_escrow.180801-1700 Build 7601.24214"
}

For Linux OS we can collect following information:

• "os_type" - type of operating system
• "product_name" - Name of the distribution
• "architecture" - Targeted processor architecture
• "kernel_major" - major version of the Linux kernel
• "kernel_minor" - minor version of the Linux kernel
• "kernel_patch" - patch version of the Linux kernel
• "kernel" - Kernel version
• "version_pretty" - Text representation of the data gathered
• "version_full" - Full system idedentifier from /proc/version

{
	"os_type": "linux",
	"product_name": "AlmaLinux release 8.6 (Sky Tiger)",
	"architecture": "x86_64",
	"kernel_major": "4",
	"kernel_minor": "18",
	"kernel_patch": "0",
	"kernel": "4.18.0-372.26.1.el8_6.x86_64",
	"version_pretty": "AlmaLinux release 8.6 (Sky Tiger) x86_64 4.18.0-372.26.1.el8_6.x86_64",
	"version_full": "Linux version 4.18.0-372.26.1.el8_6.x86_64 (mockbuild@c96addf3b7c745e3b437a36677d48bfa) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-10) (GCC)) #1 SMP Tue Sep 13 06:07:14 EDT 2022"
}

Notes:

• if any particular key in the registry of Windows OS is missing, corresponding field will be absent in the resulting JSON.
  • field os_type is guaranteed to be present and filled
  • field version_full is guaranteed to be present, but not guaranteed to be filled
• if reading of some information bit on Linux failed, then corresponding field will be absent in the resulting JSON.
  • field os_type is guaranteed to be present and filled
  • field version_full is guaranteed to be present, but not guaranteed to be filled
• "os_type" field can have following values (determined during compilation):
  • "windows" for all systems in Windows family
  • "linux" for all systems based on Linux kernel

Agent

Library zbxsysinfo gets expanded:

• new key of system.sw.os added for windows:
  • making use of function RtlGetVersion() it is possible to get windows major and minor versions as well as build number, for older versions this function also provides service pack numbers.
• new key of system.sw.os.get added for Linux and Windows:
  • using similar implementation to system.sw.os implement JSON item that will provide OS information.

Agent 2

• create new built-in package for windows with system.sw.os and system.sw.os.get keys
• create new built-in package for linux:
  • implement there new key system.sw.os.get[]
  • implement Go version of the system.sw.os (alleviate dependency on C code)

Frontend

Add new item key of system.sw.os.get to list of possible keys for item types:

• Zabbix agent
• Zabbix agent (active)

Documentation

• Now system.sw.os key is supported on Windows OS.
• New item system.sw.os.get that created JSON with OS information. Supported for Windows and Linux.

Templates

• "Windows by Zabbix agent" and "Windows by Zabbix agent active" templates:
  • new item with key system.sw.os
  • new trigger for system version change

Sign off:

akalimulin	1.1 , 1.2
MVekslers	1.1 , 1.2
sasha	1.1 , 1.2
vjaceslavs	1.1 , 1.2

Change log

v1.1. :

• Added JSON output examples for the system.sw.os.get[] key.

v1.2. :

• Changed field names of JSON for the system.sw.os.get[] key slightly, also added new field "build" for Windows JSON.

starko,

I would love to see the specifications, once they are ready, as we rely heavily on Windows OS monitoring.

Here you go: ZBXNEXT-6848-mini-spec.pdf

Thanks a lot! Do I see that correctly, that in the proposed specs won't be an item that contains the complete build number, like in my and your first example?
"build": "12345.1234"
In the specs those values are split up. Does that mean I would have to combine them myself?

starko,

"build": "12345.1234"
In the specs those values are split up. Does that mean I would have to combine them myself?

We made some minor changes in field names and also addressed your question: ZBXNEXT-6848-mini-spec_1_2.pdf

Fixed in development branch feature/ZBXNEXT-6848-6.3

Available in versions:

• pre-6.4.0rc1 561b569688b

Documentation updated:

• What's new in 6.4.0
• Zabbix agent items