ACC Host data collection fails, when it succeeds, but IRE matches to an existing Hardware class CI - Known Error

ACC Host data collection fails, when it succeeds, but IRE matches to an existing Hardware class CI Description ACC reports Host data collection has failed, and no CI is linked from the Agent record, when it has actually worked, but IRE has matched the data to an existing CI in the Hardware class. As it is the IRE's Hardware Rule identifier, at the Hardware level, that's used, we match against anything in that Hardware branch, not only CIs in the Computer branch.

This situation is quite common if existing CIs were created by Asset to CI synchronization when a Hardware asset is inserted either manually as part of the procurement/asset management progress, or an import.

Steps to Reproduce

Have a host, where you know the name, and serial number. Create a CI in the Hardware class with that name and serial. Temporarily turn on full IRE debug property glide.cmdb.logger.source.identification_engine=info,warn,error,debug,debugVerbose Install an Agent on that host, and wait for the initial host data collection to happen, or force it by clicking the button once the Agent CI appears. Status = "Collection Failed"

Errors logged are: SEVERE *** ERROR *** sn_acc_visibility (EnhancedDiscoveryHandler): Agent Client Collector for Visibility [be2d75e719ace9bd]: In EnhancedDiscoveryHandler.postIreEnrichDiscovery() CI sys_id is 'undefined' hence abort inserting other CIs SEVERE *** ERROR *** sn_agent (MainDiscoveryHandler): Agent Client Collector Framework [be2d75e719ace9bd]: In MainDiscoveryHandler.addDataIntoCMDB() IRE failed. e=Cannot read property "sysId" from undefined

Inspect the ecc_queue input, and it looks fine. no errors, and all the computer info is there.

Inspect IRE debug, and it will have MATCHED based on serial number, or fallen back to name. There are no IRE errors, but the sys_id it matches on will be cmdb_ci_hardware class, not the expected cmdb_ci_computer or one of the various server classes.

... 6 : 2023-01-03 05:23:00 : Debug : identification_engine : logId:[82cf10e31b8c] addAttempt [{" className":"cmdb_ci_linux_server ","values":{"default_gateway":"10.100.8.1","short_description":"Linux XXX 4.15.0-175-generic #184-Ubuntu SMP Thu Mar 24 17:48:36 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux","virtual":"true","os_domain":"XXX.com","cpu_manufacturer":"0daa3797db7663404140389239961929","cpu_core_thread":"1","manufacturer":"ecd93f93db76634041403892399619ab","cpu_count":"2","cpu_type":"GenuineIntel","model_number":"None","install_date":"2020-06-10 05:00:00","ram":"7977","start_date":"2022-12-17 10:11:52","cpu_name":"Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz","os":"Ubuntu","fqdn":"XXX.XXX.com","os_version":"18.4","isSystemd":"true","cpu_speed":"2992"," serial_number":"VMware-XXX" ,"model_id":"a8d93f93db76634041403892399619ad","ip_address":"10.100.8.118","kernel_release":"4.15.0-175-generic","disk_space":"97.95312881469727","operating_system_architecture":"x86_64", "name":"XXX" ,"dns_domain":"silabs.com","host_name":"XXX","cpu_core_count":"1"},"internal_id":"6acf14e3308ca190b97fff16dec6a670","sys_object_source_info":{},"settings":{},"sys_ire_info":{},"display_values":{}}] - [Rule id:556eb250c3400200d8d4bea192d3ae92|cmdb_ci_hardware| [name]] MATCHED ... 55 : 2023-01-03 05:23:00 : Debug : identification_engine : logId:[82cf10e31b8c] Output = {"items":[{"className":"cmdb_ci_hardware","operation":" UPDATE_WITH_UPGRADE"," sysId":"007a3f8787939d10f4810dc7cebb355e ","identifierEntrySysId":"556eb250c3400200d8d4bea192d3ae92","identificationAttempts":[{"info":"sys_object_source SKIPPED","attemptResult":"SKIPPED","identifierName":"","attributes":["source_name","source_native_key"],"searchOnTable":"sys_object_source","hybridEntryCiAttributes":[]},{"attemptResult":"SKIPPED","identifierName":"Hardware Rule","attributes":["correlation_id"],"searchOnTable":"cmdb_ci_hardware","hybridEntryCiAttributes":[]},{"attemptResult":"SKIPPED","identifierName":"Hardware Rule","attributes":["serial_number","serial_number_type"],"searchOnTable":"cmdb_serial_number","hybridEntryCiAttributes":[]},{"attemptResult":"NO_MATCH","identifierName":"Hardware Rule","attributes":["serial_number"],"searchOnTable":"cmdb_ci_hardware","hybridEntryCiAttributes":[]},{"attemptResult":" MATCHED","identifierName":"Hardware Rule","attributes":["name"] ,"searchOnTable":"cmdb_ci_hardware","hybridEntryCiAttributes":[]}],"info":[],"errorCount":0,"inputIndices":[0],"mergedPayloadIds":[],"markers":[],"warningCount":0},...

where "sysId":"007a3f8787939d10f4810dc7cebb355e" is the existing CI it did match.

Workaround This problem is currently under review and targeted to be fixed in a future release. Subscribe to this Known Error article to receive notifications when more information will be available.

The workaround is to re-classify the CI to be either Computer [cmdb_ci_computer], or whatever class it should be based on the server OS.

If that can't be done from a form or list view, then this background script, run in global scope, as admin, from /sys.scripts.do should work:

var ciGr = new GlideRecord('cmdb_ci_hardware'); if (ciGr.get('007a3f8787939d10f4810dc7cebb355e')) { // *** Enter your CI sys_id here instead *** ciGr.sys_class_name='cmdb_ci_computer'; // *** This might be changed to e.g. 'cmdb_ci_win_server' *** ciGr.update(); }

Warning: Changing the class of CIs can be problematic. It actually deletes and then replaces it with one with the same sys_id, so there is no way to prevent business rules running for new insert, which might have side effects. Read these before doing that: KB0689637 Issues when changing the Class Name [sys_class_name] of CIs KB0727652 What happens when you update an Extended Table record to change the Class? KB0953783 Data Policy allows creating mandatory rules for fields that only exist in sub-classes of extended tables - Causing record deletion when the record's class is changed