After Discovering your Hyper-V Windows Server, you may find you have Two CIs for the same server hardware. In the case of a full Windows Server installation that has the Hyper-V role installed, this is normal, and this will explain why.

Release or Environment

Up to and Including the New York version, and probably later. Using Discovery with either Probes/Sensors or Patterns.


In order for all the Hyper-V CIs and relationships with the Virtual CIs to work together consistently, a "Hyper-V Server" [cmdb_ci_hyper_v_server] class CI must exist. Depending on whether the server is running the free server core based version of Hyper-V or if its a full Windows Server install, then the main server CIs are created slightly differently:

Windows Server with Hyper-V role


  • The "Windows OS - Servers" Pattern will be used for these devices.
  • A "Windows Server" [cmdb_ci_win_server] CI is created. This is the main CI and has all the related lists for Serial numbers, IPs, Network adapters, Disks, Running Processes etc.
  • An additional "Hyper-V Server" [cmdb_ci_hyper_v_server] is created, with a 'Runs on' relationship to the main Windows Server CI. This will not have all attributes and related lists populated.
  • The windows_host  field of the cmdb_ci_hyper_v_server  record will reference the cmdb_ci_win_server  record.
  • The Operating System field of both records will have the full Windows Server version e.g. "Windows 2012 R2 Datacenter"

Note: So long as the relationship between them is created properly, the Reconciliation engine's Health jobs should not mark these as Duplicate, even though they are in effect 2 CIs for the same Hardware because both classes extend Hardware in the CMDB.

Hyper-V Server (Server Core w/ Hyper-V role only)


  • The "Hyper-V Server" Pattern will be used for these devices.
  • Only a "Hyper-V Server" [cmdb_ci_hyper_v_server] is created. This is the main CI and has all the related lists for Serial numbers, IPs, Network adapters, Disks, Running Processes etc.
  • The Operating System field will contain the Hyper-V OS name.

The above is the current design of Hyper-V Discovery, even though it's a bit inconsistent compared to how CIs are created by Discovery for other applications and virtualization products. 

Additional Information


The Microsoft SMS/SCCM Integration Plugin does not do this the same way. That imports Hyper-V Server (Server Core w/ Hyper-V role only) hosts into the Windows Server class. This means existing Hyper-V class CIs get reclassified/moved to the Windows Server table, together with the related Hyper-V Instances. A rediscovery causes a new Hyper-V CI to be created, and the one moved by SCCM is now a duplicate.

Issues caused by this incompatibility are being tracked by PRB1362155:
KB0812251 SCCM integration puts Hyper-V Servers in Windows Server class [cmdb_ci_win_server], whereas Discovery has traditionally put them in Hyper-V Server class [cmdb_ci_hyper_v_server]

Article Information

Last Updated:2020-05-24 07:19:10