Discovery importing company data that doesnt link to CI Configuration Items

[Les1]

Discovery is populating core_company with data that i dont see linked to CI's (expected to see them on the CI record for Company).  When i go to our CI list and display Company column, there are no Companies listed.   

Why are companies being imported via discovery to the company table if not linked to a CI?

ver: Kingston patch 7

thanks for your help in advance!

[robertgeen · Accepted solution]

Les,

I haven't dealt with the core_company table much but if I had to guess I would say that it's happening when Manufacturer or some field like that is being set on the CI. This would also cause it to create an asset which more then likely is putting entries into that table as well. 

If you look at the schema map for the core_company table you can see that it's being referenced by many of the cmdb tables as a few of their attributes actually reference that table and that table I believe has auto-create on so that if you set a value that doesn't exist it will auto create it. I hope that helps.

[Les1]

Here is what I think I have found out. 

HI told me that discovery scans do not pull in company data. However, this doesnt seem accurate from what i'm seeing, and it may be a difference in semantics. 

OOTB there is a company_core table, and this data displays via the Organization/Companies output.

The Default view of that output (or looking at the table schema) reveals a Manufacturer flag.

So what has actually happened is that Discovery scans have pulled in Manufacturer for the CI's coming in, and created a record on the company_core with the Manufacturer flag set to True.  This may well be normal OOTB behavior.

The impact to us, new to Discovery, is that along with CI data, comes an influx of 'company' data that we weren't expecting ( i suppose i would have expected a Manufacturer table or something).  So all these odd looking companies were showing up for users when picking from a Company dropdown on catalog requests.

I have since put a condition on those dropdowns though to not include records created by our midserver. may not be the best approach in the long run, but works for now. I'd welcome a better practice suggestion if anyone would offer.

Thank you 

[DaveHertel]

Hi -- Take a look at normalization, which is intended help with this situation.  Its been quite a while since I've worked with this much, but it might help?  Please let me know -- reply/etc., I'd like to hear if helps.

From Normalization docs :

The Normalization Data Services plugin helps maintain consistency for table fields that refer to a company name.

Tables related to configuration items and assets usually contain columns referring to a company name, such as a vendor or manufacturer. Often, these tables refer to the same company by several different names. This situation can happen for many reasons. For example, vendors sometimes use different company names depending on the device. This inconsistency creates problems, especially for reports that rely on these company names.

The Normalization Data Services plugin helps alleviate this problem.

When you enable and configure the Normalization Data Services plugin, the system downloads a list of standard company names that ServiceNow has compiled. It also downloads a list of common variants of that name. Any time the plugin finds a company-name field with one of those variants, it substitutes the standard name in its place.

Note: The Normalization Data Services plugin refers to a standard name as a normalized name and to a variant name as a discovered name.

[Rook2]

The core_* tables are just that, very core to most of the platform.  In the case of Discovery, CMDB and the Companies table, this reference leverages the Manufacturer flag on the Company records, usually from SNMP queries of devices.  So while Discovery "doesn't pull in Company data" (like one would think about a third-party data integration would), it absolutely creates Company records from discovered devices.

@Les - Are you saying that there are zero CIs in your CMDB with a non-null Company column?  If you find a router or switch and examine the XML of the record, what does the <company> entry hold?

If it is truly null everywhere, we have an interesting issue (clearly). 

Troubleshooting steps:

1.  Does your Company table have a record that we can test with in DEV, such as "Cisco" or "Netgear"?

2.  Find a switch or router in your CMDB and enter a Manufacturer manually, save the record.  

3.  Examine the XML, does the <company> field retain the reference?

4.  Are there Reconciliation Rules in place that are telling Discovery that it cannot update the reference?

5.  Have you disabled any Discovery Patterns or Probe/Sensors?

6.  Have you tried doing a Quick Discovery on a specific device and parsing through the Discovery Log?  We need to ensure that there are no Discovery issues that might be causing this. 

Now on to a widely asked related request:

The single largest piece of advice surrounding this reference is Field Normalization.  I highly recommend that you take a few hours to read through the Docs on Normalization and experiment with your Company data in your DEV environment, as you can put into place rules to clean up your data and keep it clean.  Most organizations set up Field Normalization rules on the core_company.name field, coalescing all of the various manufacturing company name variations into one record. You get to pick what Company record you want all of them to become.

Thus, all "Hewlett-Packard", "HP Co.", "HP-US", "Hewlett-Packard Co." variations are transformed to "Hewlett-Packard", for instance, through-out the platform.  When another Discovery run tries to re-populate a CI record with "HP", Field Normalization intervenes (sort of like a Business Rule) and transforms that data to be "Hewlett-Packard" (to continue with the example).

There tends to be a "top 20 hit list" of Company names, such as Microsoft, HP, Dell, Adobe.  I am sure that you can think of a few more companies that have a litany of varied name entries in your table right now.  All in all, you can clean up your Company table quite a bit with just an afternoon of work.