Which Windows is this? Agent 0.3.96 asks the kernel, not PowerShell
A Windows 11 PC spent six weeks listed as windows-Unknown-Unknown because the agent asked PowerShell for its identity and PowerShell would not answer. Agent 0.3.96 reads the edition, build, model, manufacturer and locale straight from the kernel and the registry, and the server no longer lets an unknown answer overwrite a known one.
One machine in the device list read windows-Unknown-Unknown. Its health
checks were running, its score was 79, osquery knew who was logged on, and
the capability probe had read Microsoft Windows [Version 10.0.26200] off it
without difficulty. The agent simply could not say which Windows it was, and
it had been saying so, quietly, since the day it was enrolled in July.
Agent 0.3.96 fixes the cause rather than the symptom.
Why a machine forgets its own name
Until now every identity fact the agent reported about a Windows machine came out of a PowerShell child process: the OS caption and version, the edition, the model and manufacturer, the locale, the user at the console. PowerShell is a fine tool for reading WMI. It is also a separate program that has to be found on the PATH, started, allowed by policy and finished inside a budget, and on this particular machine one of those steps failed every time. The agent's answer to that failure was a placeholder string, written over the device's record on every report, with the reason for the failure discarded.
The placeholder made things worse than a blank would have. It spelt the family in lower case, which meant the server's own "is this Windows?" checks said no, and it stamped the device with OSVersion: Unknown and OSSubVersion: Unknown tags, replacing nothing useful with something useless.
What 0.3.96 does instead
Nothing that forks a process. The kernel is asked directly for the family and build, which is the same answer Windows gives itself and cannot be shimmed. The edition comes from the registry key Windows Setup writes, so Home, Pro, Enterprise, Education, Standard and Datacenter read exactly as before, and the editions that WMI's caption used to flatten now name themselves: an evaluation server reads StandardEvaluation or DatacenterEvaluation rather than just Evaluation, Pro for Workstations reads ProWorkstation, and LTSC reads EnterpriseLTSC.
Model and manufacturer come from the firmware table the kernel publishes, with the same two fallbacks Windows itself uses for a virtual machine whose firmware carries no names, so a QEMU guest still reads BOCHS_ and BXPC____ the way it does in msinfo32. The locale and the console user come from the Windows API. All of it is in-process, instant, and works as the service account, which is where the agent lives.
The server stopped accepting downgrades
This part is live now, for every agent version. When an agent reports that it could not determine its platform, the server keeps whatever it already knew about that device rather than replacing it, and it leaves the OS tags alone. A machine that identified itself correctly on Monday no longer loses that on Tuesday because PowerShell had a bad day.
If you have a very old agent
The machine that surfaced this was running agent 0.3.63, from before the update channel existed, so it cannot update itself and the tenant's target version does not reach it. Any agent older than 0.3.68 is in the same position. Installing the current MSI over the top is a normal upgrade: the enrollment and settings under ProgramData are kept, the service restarts as the new version, and from then on it follows the channel like everything else.