Discovery is failing for HYPERV servers during output payload processing.Issue Discovery is failing for HYPERV servers during output payload processing and shows this error message: Warn : identification_engine : MISSING_DEPENDENCY In payload no relations defined for dependent class [cmdb_ci_hyper_v_instance] that matches any containment/hosting rules: [cmdb_ci_hyper_v_instance >> Has registered >> cmdb_ci_computer]. Add appropriate relations in payload for '{"className":"cmdb_ci_hyper_v_instance","values":{"memory":"8192","disks":"2","cpus":"4","object_id":"EA27C08A-C193-423C-84DA-EEDB3FDC9055","sys_class_name":"cmdb_ci_hyper_v_instance","baseboard_serial":"4984-2676-8586-1282-2195-3291-66","discovery_source":"ServiceNow","install_status":"1","bios_guid":"9297910F-27F1-42D9-99E7-3D8FDBCAE25C","nics":"2","name":"DKFRVWPSCM01","chassis_serial":"4984-2676-8586-1282-2195-3291-66","bios_serial":"4984-2676-8586-1282-2195-3291-66","state":"on","disks_size":"680"},"sys_object_source_info":{"source_name":"ServiceNow"},"settings":{},"sys_ire_info":{"ire_received_time":"2020-09-29 23:20:47"}}' The following errors can be observed by running the payload through IRE Simulator: Duplicate relationship type records exists with name [Defines resources for::Gets resources from] in table [cmdb_rel_type] having sys_ids Duplicate relationship type records exists with name [Registered on::Has registered] in table [cmdb_rel_type] having sys_ids Error message : "In payload no relations defined for dependent class [cmdb_ci_hyper_v_instance] that matches any containment/hosting rules: [cmdb_ci_vm_instance >> Runs on >> cmdb_ci_virtualization_server,cmdb_ci_vm_instance >> Hosts >> cmdb_ci_logical_datacenter,cmdb_ci_vm_instance >> Runs >> cmdb_ci_computer]. Add appropriate relations in payload for '{\"className\":\"cmdb_ci_hyper_v_instance\",\"values\":{\"memory\":\"8192\",\"disks\":\"2\",\"cpus\":\"4\",\"object_id\":\"EA27C08A-C193-423C-84DA-EEDB3FDC9055\",\"sys_class_name\":\"cmdb_ci_hyper_v_instance\",\"baseboard_serial\":\"4984-2676-8586-1282-2195-3291-66\",\"discovery_source\":\"ServiceNow\",\"install_status\":\"1\",\"bios_guid\":\"9297910F-27F1-42D9-99E7-3D8FDBCAE25C\",\"nics\":\"2\",\"name\":\"DKFRVWPSCM01\",\"chassis_serial\":\"4984-2676-8586-1282-2195-3291-66\",\"bios_serial\":\"4984-2676-8586-1282-2195-3291-66\",\"state\":\"on\",\"disks_size\":\"680\"},\"sys_object_source_info\":{\"source_name\":\"ServiceNow\"},\"settings\":{},\"sys_ire_info\":ResolutionMost probably the issue lies in the Hosting rule created by the customer and not OOB, which can be observed from the "cmdb_metadata_hosting" table. Also, there is a possibility that the Relationship Type does not match OOB sys_id. Export - OOB Rel type and import to test instance. /cmdb_rel_type.do?sys_id=aa9434870ab301544ce2943bf03fd7a8 Export for backup from the instance with issue, then update rel type via glide record to OOB 'aa9434870ab301544ce2943bf03fd7a8' /cmdb_rel_ci_list.do?sysparm_query=type.nameLIKEreg&sysparm_view= Use this background script to update the rel type via glide record (function () {var gr = new GlideRecord('cmdb_rel_ci');gr.addEncodedQuery('type.sys_id=<sys_id with issue>');gr.query();while (gr.next()) { gr.setValue("type","aa9434870ab301544ce2943bf03fd7a8"); gr.update();}} ()); Export Relations Type record for backup from the instance with the issue and then delete in the instance. https://<instance_name>.service-now.com/nav_to.do?uri=cmdb_rel_type.do?sys_id= Export hosting rule for backup from the instance with the issue, and then delete as this one does not match the OOB record https://<instance_name>.service-now.com/nav_to.do?uri=cmdb_metadata_hosting.do?sys_id= Import Hosting rule from OOB on to the instance with issue /nav_to.do?uri=cmdb_metadata_hosting.do?sys_id=cec6843d37fe220006b216a543990e5c Execute the discovery and it should run without any issues.