Changing OS name mapping for Windows Server 2019 hosts?

Support
1

Problem:
My Windows systems are reporting as “Windows” and then their build number, which makes it pretty hard to discern between Windows server and client machines.

Is there a way to change what facts are used for the reported operating system?
right now it looks like it’s using os > name , which = windows

I would like it to report on os > windows > product_name , which reports as Windows Server 2019 Standard, instead

How would I go about doing this?

Expected outcome:

OS friendly name is displayed in foreman.

Foreman and Proxy versions:
3.10 nightly
Foreman and Proxy plugin versions:
Latest
Distribution and version:

Other relevant data:

2

While not perfect, foreman actually uses name, major, minor of kernel.

For server and client that will show as different kernels unless you have an unpatched client OS ( 2019 stays at the same kernel, windows 10 does not)

You can rename/alias unique OS’es discovered in foreman. In our case we added “Windows Server 2019” for that specific kernel in foreman. Windows 10 for each 6month update we label like “Windows 10 20h2” or similar.

Then in foreman they show up separately.

It’s sucky for the few times the server and desktop kernels match, but that’s like a few months every 2-3 years. Typically the windows 10 version is out before all of our server side stuff supports the latest windows server version anyways…

3

So in your case you changed the Description (Friendly Name) to Windows Server 2019 ?

That seems to work as a quick bandaid for the moment, I do wonder if there’s a way to remap the fields… maybe tinkering with one of the puppet facter properties? I’m still pretty new to puppet though.

Do you happen to have any advice on how I can collect additional facts from windows hosts, mainly programs listed in add/remove applications?

4

You can go down the road of writing your own ruby code to report facts: Custom facts overview
But if you are not already a ruby developer and want to explore Puppet in its ugly depth, I would recommend a look at external facts. This would even allow using powershell on Windows: External facts

Simply put this into the correct location of a Puppet module and it will be synced to all systems and executed and reported before every run.

5

Here is where core parses the release number:

And here’s the name:

I don’t use Windows so I don’t know which facts would be better suited. A patch (or suggestion how to) would be very welcome.

6

As mentioned already by @Dirk - Custom facts or External Facts are the way to go.
YAML Files, TXT files, Shell Scripts, Ruby Scripts, Python Scripts - whatever really. Puppet can gather insane amounts of custom facts that you write. In our environment - we do “many” custom facts already.

PS1 script that returns the output of a WMI query for add/remove programs in the format facter wants would totally give you what you want.

One word of caution (particularly with windows) - your custom facts add to the “runtime” of fact gather portion of puppet. You really don’t want something that takes more than, say, 1 second. Too many of them and all of the sudden “fact gather” takes like 3 minutes which is annoying…
We’ve gotten to the point (again, particularly with windows) where we will setup a scheduled task for “long running” fact gather jobs - which executes maybe 1x per day, and dumps the “result” into a YAML file in the facts.d directory. That way facter/puppet can run and gather the info “quickly” without incurring the script penalty. I’d recommend that, or something similar, if your custom stuff is slow to query (LOOKING AT YOU, FREAKING WMI)
:slight_smile:

2 Likes
7

Thank you, I’ll likely look at writing a PowerShell one liner to grab what I need.

also Incase you weren’t already aware of it, WMI is depreciated.

Wmic is going away in future windows releases and get-wmiobject is absent from PowerShell 7+

It’s alternative is get-ciminstance