SCCM integration incorrectly puts a Hyper-V CI into the windows server class. This is Correct for a normal Windows Server edition, that happens to be running the Hyper-V role, but not correct for the "Hyper-V Server" edition of Windows (Server Core+Hyper-V Role only)
If you use discovery this correctly identifies the CI as a Hyper-V Server (Server Core+Hyper-V Role only) and puts it into the Hyper-V class [cmdb_ci_hyper_v_server]. Details of that expected behaviour are in KB0719772
If you run SCCM integration import, it will reclassify that CI incorrectly into the Windows Server class [cmdb_ci_win_server]. When the Hyper-V CI is moved to the Windows Server class, the existing Hyper-V Instance CIs, and their relationships, will remain pointing to it.
When Discovery runs again, it will see the Hyper-V CI is missing, so will create a new Hyper-V Server CI and a new set of duplicate Hyper-V Instance CIs and relate them to the Hyper-V Server CI it recreates. That will leave a Windows Server CI that is a duplicate of the Hyper-V CI and a duplicate set of Hyper-V Instance CIs and relationships linked with it, which Discovery won't update.
Steps to Reproduce
- Run Discovery against a Hyper-V server, and a correct Hyper-V CI will be created or updated, plus all the Hyper-V instances and other related resources.
- Run SCCM load and that Hyper-V server CI is reclassified as a Windows Server.
- Run Discovery again, and it replaces the 'missing' Hyper-V CI with a new one, plus all the new related CIs.
- Run SCCM load and Hyper-V servers are created in the Windows Server class.
- Run Discovery and it will not match with this, and instead create a Hyper-V CI one, plus all the new related VM instances/CIs.
This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this form to be notified when more information will become available.
Related Problem: PRB1362155