CI Type value in cmdb_ci_server table

Sergei3
Kilo Contributor

Hello,

Does someone know the logic behind how CI Type value is generated in cmdb_ci_server table?

For some CIs I see "Server" only value with Windows OS discovered and not "Windows Server" as CI Type.

Is there some type of CMDB translation table to set CI Type value based on OS or something else?

Thank you for your help!

1 ACCEPTED SOLUTION

Anshu_Anand_
Kilo Sage
Kilo Sage

Answer can be found here https://community.servicenow.com/community?id=community_question&sys_id=e8812829db8cf0106064eeb5ca96...

Your class is becoming less specific, which is called demotion.  There can be lots of reasons for this happening but more information would be required to know the exact reason, but gere are some places to get started:

What are you using to populate your Computer tables?  Discovery? SCCM? Both? Are you also importing from other data sources? If so, are you using the Identification and Reconciliation Engine (IRE) to transform those data sources?  If you can find a data source that is populating the Computer table without using IRE, it is very likely the source of your problem.

Normally, any data source using IRE will not demote your CI class during an update.  If they are, then these are behaviors you can control.  For more on how to control this see: CI reclassification during IRE processing.  However, please note that--depending on your version--if you block class demotion, this can mean that the CI doesn't get updated at all in those cases.  So it won't be reclassified as a computer, but any other attributes won't get set either.  More recent versions of the IRE have been enhanced with features to gain greater control.

Other things that could be causing this:

  • Discovery itself can fail to recognize all versions of Windows OS, so in some cases you may need to modify the Classifiers for Windows based on the actual OS string obtained by the probe.
  • If you are setting the CI class directly in your transform maps/scripts, check your logic for conditions that might be causing this.
  • Make sure these aren't two different CIs.  Sometimes people can get confused and think they are seeing the same CI change but in reality there are two distinct CIs that are coming up in different circumstances, depending on which list you are looking at and how you are filtering the list.

Hope this helps.  If it does, please mark my answer as Helpful.

Regards,
Anshu

View solution in original post

1 REPLY 1

Anshu_Anand_
Kilo Sage
Kilo Sage

Answer can be found here https://community.servicenow.com/community?id=community_question&sys_id=e8812829db8cf0106064eeb5ca96...

Your class is becoming less specific, which is called demotion.  There can be lots of reasons for this happening but more information would be required to know the exact reason, but gere are some places to get started:

What are you using to populate your Computer tables?  Discovery? SCCM? Both? Are you also importing from other data sources? If so, are you using the Identification and Reconciliation Engine (IRE) to transform those data sources?  If you can find a data source that is populating the Computer table without using IRE, it is very likely the source of your problem.

Normally, any data source using IRE will not demote your CI class during an update.  If they are, then these are behaviors you can control.  For more on how to control this see: CI reclassification during IRE processing.  However, please note that--depending on your version--if you block class demotion, this can mean that the CI doesn't get updated at all in those cases.  So it won't be reclassified as a computer, but any other attributes won't get set either.  More recent versions of the IRE have been enhanced with features to gain greater control.

Other things that could be causing this:

  • Discovery itself can fail to recognize all versions of Windows OS, so in some cases you may need to modify the Classifiers for Windows based on the actual OS string obtained by the probe.
  • If you are setting the CI class directly in your transform maps/scripts, check your logic for conditions that might be causing this.
  • Make sure these aren't two different CIs.  Sometimes people can get confused and think they are seeing the same CI change but in reality there are two distinct CIs that are coming up in different circumstances, depending on which list you are looking at and how you are filtering the list.

Hope this helps.  If it does, please mark my answer as Helpful.

Regards,
Anshu