Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Discovery creates 2 Server CIs for Hyper-V (Windows Server + Hyper-V Server) - Known issues with this design - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Discovery creates 2 Server CIs for Hyper-V (Windows Server + Hyper-V Server) - Known issues with this design
KB0719772

Discovery creates 2 Server CIs for Hyper-V (Windows Server + Hyper-V Server) - Known issues with this design


8222 Views Last updated : Dec 20, 2022 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Issue

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 given the current design, and this article will explain exactly how it is designed and the problems with this design.

Table of Contents

  • Where Discovery puts Hyper-V Servers in the CMDB
    • Hyper-V Server (Server Core w/ Hyper-V role only)
    • Windows Server with Hyper-V role
  • Notes on the design
  • CMDB IRE Identification and De-Duplication Tasks
  • Model Categories and Ci-Asset synchronisation
  • Selecting the correct CI
  • Discovery Console
  • Imports and Service Graph Connector
  • ITOM Visibility licensing Node Counts

Where Discovery puts Hyper-V Servers in the CMDB

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:

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

https://en.wikipedia.org/wiki/Hyper-V#Hyper-V_Server

  • Classifier: Hyper-V Server
    • Where OS Name/edition contains "Hyper-V", but does not contain "without Hyper-V" (not used for e.g. "Windows Server 2008 without Hyper-V")
    • This classifier is ordered first, so only if there is not a match would classification fall back to the normal server classifier below.
  • 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.

Windows Server with Hyper-V role

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions#Server_versions

  • Classifier: Windows n Server (e.g. Windows 2022 Server)
    • Where OS Name/edition contains "Server"
  • The "Windows OS - Servers" Pattern will be used for these devices, which includes the "Windows - Hyper-V" Library.
  • 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.
  • Discovered Application CIs that "Runs On" the server will have the relationships links to the cmdb_ci_win_server CI.
  • 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.
    • Since Sept. 2022, the Name has the "@Hyper-V Server" suffix, and Serial Number the "_hyper_v_server" suffix.
    • 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"

Notes on the design

This applies to both Discovery with either Probes+Sensors or Patterns. Pattern Migration continued the same design the Probes used.

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.

The cmdb_ci_hyper_v_server class is in the Hardware branch of the CMDB, when in fact it is Software. That doesn't compare well with more modern Discovery implementations, the CI Class Models and suggested relationships, and CSDM, which came long after. If this was designed today, the cmdb_ci_win_server class would probably be used for the main hardware CI for all editions of Windows Server, and then a Hyper-V Application class used for the Hyper-V software running on that server. 

The above is the current design of Hyper-V Server Discovery. To change this design now, would be problematic.

This design is not considered a Product Defect and is Working as Expected. Customers still have the option of creating an Enhancement Request. This has already been tried in the past with no result, but this time round it might get enough up-votes.

CMDB IRE Identification and De-Duplication Tasks

So long as the reference/relationship between them is created properly, the CMDB IRE Reconciliation engine's Health jobs should not mark these as Duplicate, even though they are in effect 2 CIs for the same Hardware. Both are in the Hardware branch so are covered by the "Hardware Rule" identifier.

This stopped working at some point and caused this problem:
PRB1564552 / KB1118026 Hyper-V Server pattern steps do not differentiate identification fields from Windows Server, causing conflicts with duplicate remediator

This was fixed in the September 2022 version of the "Visibility Content" app v6.1.0, and later.

The "Windows OS - Servers" Pattern now uses the true name/serial number in the Windows Server CI, and add a "@Hyper-V Server" suffix to the name, and "_hyper_v_server" suffix to the Serial Number of the Hyper-V Server record.

The "Hyper-V Server" Pattern, when creating just a single Hyper-V Server CI, does use the true Name/Serial.

Model Categories and Ci-Asset synchronisation

There is a Model Category [cmdb_model_category] for Windows Servers, that will cause a linked Hardware Asset to be created automatically, and keep fields synchronised between them.

There is no Model Category for Hyper-V Server, which means when there is just a Hyper-V Server CI, which is the only CI representing the server hardware, no linked Asset is created.

Selecting the correct CI

Where there is a normal server that happens to also be running Hyper-V, the pair of CIs are in different classes but will have the same name.

They are within the same Server/Computer/Hardware branch of the CMDB so lookup select boxes are likely to have both listed. Which do you use, and how do you tell them apart?

  • If a task is related to the Hardware, or configuration of the OS in general, then the cmdb_ci_win_server record would ideally be used.
    • This is the CI with all the related lists for Serial numbers, CPU/Memory, Network/IP, Running processes etc. 
    • The CI with name suffixed with "@Hyper-V Server" would not be used.
  • If a task is related to the Configuration of Hyper-V on the server, or related to the VM instances and Services running on those, then the cmdb_ci_hyper_v_server record would be more suitable.
    • This is the CI with all the Hyper-V specific relationships.

Customising list layouts, perhaps for the lookup select box popup on incident/problem/change forms, to include the Class column, will help your ITIL/Asset users.

It would also be possible to add a field to form layout of your tasks, dot-walking to the Class of the referenced Configuration Item. It is best to add a UI Policy to make that  field read-only, to avoid accidental CI reclassification.

Discovery Console

See:
KB1216009 Disabling Hyper-V Server in the Discovery Console does not prevent Hyper-V Server class CIs being created

Imports and Service Graph Connector

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]

ITOM Visibility licensing Node Counts

The overcounting of server CIs due to this design was fixed back in the Rome version (PRB1483452).

 


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.