Scanned some windows servers, For some windows servers, CI created in ALM_Hardware table

[AjaiK]

Scanned some windows servers, For some windows servers, CI created in ALM_Hardware table instead of windows server table. Could you please help out to find the specific reason for that

[Vikram Reddy]

Hi @AjaiK,

First thing to check: pull the Discovery Status record for one of the affected servers and look at what happened in the Classification phase, before you worry about alm_hardware at all. That phase is where the class actually gets decided, and everything else is downstream of it.

Worth clearing up the table confusion too: alm_hardware is not a CI table. It doesn't extend cmdb_ci, it's a separate Hardware Asset Management record that carries a reference field back to the CI. If Hardware Asset Management is active on your instance, every CI that lands under the Hardware class hierarchy (cmdb_ci_hardware and its children, including cmdb_ci_win_server) automatically gets a paired alm_hardware record created for it. That pairing is by design, it's the financial/lifecycle side of the same asset. So the real question is: does a proper cmdb_ci_win_server record actually exist for these hosts, or did the CI itself get classified generically as base Hardware, with alm_hardware just being the asset record that tagged along for the ride?

Assuming it's the latter, generic classification almost always comes down to Discovery not getting a live, credentialed connection into the OS on those specific boxes. Horizontal Discovery needs a successful WMI or PowerShell shell session to pull OS-level detail and hand off to the Windows classifier. Without that, it falls back to whatever it got from port scanning and SNMP, which is only enough to say "this is hardware," not "this is a Windows Server." A few things to check on the hosts that landed wrong:

• Credential success vs. failure: in the Discovery log for those hosts, look for whether a shell was actually established (WMI/PowerShell) versus just port and ping probes succeeding. If only ports responded, that's your answer.
• Firewall/WinRM differences: since it's "some" servers and not all, compare firewall rules and WinRM/DCOM configuration on the failing hosts against the ones that classified correctly. A blocked 135/445 or disabled Remote Registry on just those boxes is a common culprit.
• Prior identity from another source: check if those same serial numbers or MAC addresses were already in the CMDB as a generic Computer or Hardware CI from another source, like SCCM or a manual import, before Discovery ever touched them. The Identification and Reconciliation Engine can lock a CI to whatever class it already has, and Discovery won't automatically promote it up to Windows Server even with good credentials on a later run.
• Classifier/pattern conflicts: less common, but worth a look if the above two are clean, check whether a custom or duplicate classifier is intercepting these hosts before the standard Windows classification pattern runs.

Thank you,
Vikram Karety
Octigo Solutions INC