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.
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]