This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
BMC Discovery 11.3
Windows workstations / desktops are being discovered as Windows servers.
This can happen even when "Discover desktop hosts" is set to NO.
The device is correctly identified as a Windows workstation when the getDeviceInfo method is successful using WMI. However, in some cases, WMI fails, and the scan falls back to using RemQuery. In this case the OS may be incorrectly reported as a Windows Server and a host record is created.
The problem is not simply that RemQuery is being used, but that it partially fails also. RemQuery tries to execute two different commands that would produce a version number. The first command is 'SYSTEMINFO /fo csv /nh'. On a Windows 7 SP1 box, this command returns something like:
"MYHOST","Microsoft Windows 7 Enterprise ","6.1.7601 Service Pack 1 Build 7601","Microsoft Corporation",....
But if that command fails, the next command is simply "HOSTNAME && VER", which on a Windows 7 SP1 box returns:
Microsoft Windows [Version 6.1.7601]
Since Windows 7 SP1 and Windows Server 2008 R2 SP1 have the same version number, the system is classified as server by default. A similar problem happens with Windows 8, since Windows 8 and Windows Server 2012 have the same version number (6.2.9200). Other version numbers probably overlap as well.
Following are several possible causes and solutions. See also:
- KA 000090338: Troubleshooting Windows WMI discovery failures
- KA 000031966: A scan of a Windows server fails with an error in WMI. How to test the WMI connection from a Discovery Windows proxy to a target host?
Root cause 1: WMI / getHostInfo fails with timeout (and RemQuery fails for various reasons). This can be confirmed by the following message in the proxy worker logs:
discovery.slave.worker.wmi_method: INFO: WMI failure: xx.xx.xx.xx : <no username> : getInfo : Timed out
Solution 1: Resolve the WMI issue, so that RemQuery is not used.
Root cause 2: WMI / getHostInfo fails with 0x800706ba / firewall issue (and RemQuery fails for various reasons). The message is visible in both logs and UI:
Failed to establish WMI connection to namespace root\cimv2 : Connect failed : 0x800706ba : The RPC server is unavailable.
Solution 2: Resolve the WMI issue, so that RemQuery is not used.
Root cause 3: WMI / getHostInfo fails with 0x80041010 : Invalid class . This can be confirmed by the following message in the proxy worker logs (in DEBUG):
discovery.slave.worker.wmi.connection: DEBUG: Exception from 'SELECT * FROM Win32_OperatingSystem': WMIException('Failed to retrieve batch of results : 0x80041010 : Invalid class',)
To confirm, run " winmgmt /verifyrepository" on the target machine. If the result is 'WMI Repository is INCONSISTENT', the root cause is confirmed
Solution 3: Engage the Windows administrator / SME to fix the repository
Root cause 4: WMI fails and the RemQuery 'systeminfo' command times out. This could be caused by a performance issue on the target server.
Solution 4: Resolve the WMI issue, so that RemQuery is not used.
Root Cause 5: The target system is not in the English locale. The message "Failed to parse command output" appears. If this occurs, RemQuery may fail because it cannot parse the output. At this time, Discovery only supports the English locale for RemQuery. See "Non-English Windows discovery using RemQuery" in https://docs.bmc.com/docs/display/disco113/Limitations+and+restrictions+of+this+version:
- fix the WMI issue (so that RemQuery is not used (see the root causes 1-3)
- change the locale