[FEATURE] Include Host OS in Server Inventory

[vpnicholls]

Which component(s) does this affect?

• Full Dashboard
• Lite
• SQL collection scripts
• Installer
• Documentation

Problem Statement

When presenting host/instance info to the business, I was recently asked for all our SQL Server instance versions AND the OS versions of the hosts. Some of the info was available in FinOps > Server. But I resorted to T-SQL to get the OS version. If both pieces of information were available in Server Inventory, then I would have "one port of call".

Proposed Solution

Add one more column to the Server Inventory tab/window, maybe called HOST OS Version or similar; maybe between the existing Version and CPUs columns?

Use Case

1. Navigate to Server Inventory.
2. Export to csv
3. Format file and present to business.

Alternatives Considered

Existing workaround is to get this via SSMS / T-SQL. This works, but is just a bit slower. And the Server Inventory page already has so much other useful information.

Additional Context

No response

[erikdarlingdata]

@vpnicholls sure, this would be a great addition. Did you want to contribute this as well?

[vpnicholls]

If this is just a T-SQL change/update, then this might be a good small one for me to cut my teeth on. If it spills over to C# changes, then I might will be a bit lost, though.

[erikdarlingdata]

Thanks for the feature request! This is doable but touches quite a few layers. Here's the full scope so you can see what's involved:

SQL Server compatibility challenge

The clean source for this is sys.dm_os_host_info (host_platform, host_distribution), but that DMV only exists in SQL Server 2017+. For 2016 and earlier, you'd have to parse the OS info out of @@VERSION (which is ugly but works). Azure SQL DB / Managed Instance would need their own handling since they don't have a traditional host OS.

Files that would need changes

Backend / data collection (9 files across both apps):

Layer	File	What changes
SQL schema	install/02_create_tables.sql	Add os_version column to collect.server_properties
SQL collector	install/53_collect_server_properties.sql	Query OS info and include in INSERT + hash
Dashboard model	Dashboard/Services/DatabaseService.FinOps.cs	Add OsVersion property to FinOpsServerInventory, update SQL query + mapping
Dashboard view	Dashboard/Controls/FinOpsContent.xaml	Add DataGrid column
DuckDB schema	Lite/Database/Schema.cs	Add os_version to CREATE TABLE
DuckDB migration	Lite/Database/DuckDbInitializer.cs	Add schema migration for existing installs
Lite collector	Lite/Services/RemoteCollectorService.ServerProperties.cs	Query OS info, add to DuckDB appender
Lite model	Lite/Services/LocalDataService.FinOps.cs	Add OsVersion property to ServerPropertyRow, update SQL query + mapping
Lite view	Lite/Controls/FinOpsTab.xaml	Add DataGrid column

Plus an upgrade script in upgrades/ for existing Dashboard installations (ALTER TABLE to add the column).

Summary

• ~9 files modified across Dashboard and Lite
• New schema migration for both SQL Server and DuckDB
• Version-conditional SQL to handle 2016 vs 2017+ vs Azure
• No breaking changes (nullable column addition)

Not a huge lift individually per file, but the surface area spans the full stack in both apps.

[erikdarlingdata]

Correction to the scope above — missed one file:

Layer	File	What changes
SQL schema enforcement	install/06_ensure_table_create.sql	Add os_version column to the server_properties table definition here as well

So it's ~10 files total, not 9.

[vpnicholls]

OK, if you're happy to leave this for me for a while, then I'll fire up my home lab laptop and get the Full Edition installed (as I can't install this at work). I'll have a look over the files you've highlighted. There will be a bit of upskilling for me. So, if I take a week or so on this (amongst other responsibilities), would that be OK? I won't be offended, though, if you find it starts taking too long and you want to reassign it.

[erikdarlingdata]

@vpnicholls I have no one to assign it to, unless someone else takes it over voluntarily. This is free software, but it's not free development. Requests for new features (not bugs, those are my fault) require adding and testing the feature, and then testing the installation path via the Installers when .sql files are changed.

Even with our robot overlords companions, it's a process that is quite imperfect and often time-consuming.

It's of course fine to request features, just understand that not all of them will be voluntarily worked on (at least not immediately), and some may be closed for various reasons (conflicting with the the scope or philosophy of the project, for example).

If a new feature is particularly important to you or your company, or you begin to rely on any of this tooling, you might consider sponsoring the project, or having your company opt into a paid support contract.

Those arrangements are also entirely voluntary, and not at all requirements to have features worked on, but do exist as ways to ensure continued work on and survival of the project generally.

[vpnicholls]

Yep, understood and very much appreciated.