Prevent Discovery from creating CI's with no serial number

[tlurvey]

Hi all,

We have run into an issue where we create duplicate CI's, I was wondering if anyone has come up with a solution that if the Serial number is empty, do not create the CI?

[phsdm]

We had an issue with duplicate Computer serial numbers with the SCCM Integration.

1. We create a Hardware Asset with purchase information and initial stockroom.
2. This causes a CI stub to be created.
3. When the computer shows up in SCCM, the SCCM Integration creates a duplicate.

This happens because the CI Identifier "SCCM ID & Class Name" does not recognize the CI stub as a match (there is no entry in sys_object_source matching the new SCCM Resource ID.)

To fix it without stepping on application files that ServiceNow might upgrade, I created a new CI Identifier, "SCCM Serial Number."   Its order number is 960, so it runs after "SCCM ID & Class Name" fails to match.   By placing it after, we get normal behavior for CIs with matching Resource IDs.

function scope(ciData, log, identifier) {

     // This Identifier only applies to Computers.
       if (ciData.getData().sys_class_name != 'cmdb_ci_computer') {
               return new CIIdentifierResult([], false);
       }

       var sccmID = ciData.getData().correlation_id;
       var serialNumber = ciData.getData().serial_number;

       info('sccmID={0}, serialNumber={1}', sccmID, serialNumber);

       var matchable = JSUtil.notNil(serialNumber);
       var matches = [];

       if (matchable) {
               try {
                       findBySerialNumber(serialNumber, matches);
               } catch(e) {
                       error('Exception: ' + e);
               }
       }

       return new CIIdentifierResult(matches, matchable);

       function findBySerialNumber(sn, matches) {

               var tableName = identifier.applies_to;
               var className = ciData.getData().sys_class_name;

               info('table={0}, sys_class_name={1}, serial_number={2}', tableName, className, sn);

               var gr = new GlideRecord(tableName);
               gr.addQuery('sys_class_name', className);
               gr.addQuery('serial_number', sn);
               gr.addQuery('hardware_status', '!=', 'retired');
               gr.query();

               while (gr.next()) {
                       info('found [{0} {1} {2}]', gr.sys_class_name, gr.serial_number, gr.getUniqueValue());
                       matches.push('' + gr.getUniqueValue());
               }

               return matches;
       }

       function info(msg, args) {
               log.info(gs.getMessage(msg, Array.prototype.slice.call(arguments, 1)), 'Identifier: SCCM Serial Number');
       }

       function error(msg, args) {
               log.error(gs.getMessage(msg, Array.prototype.slice.call(arguments, 1)), 'Identifier: SCCM Serial Number');
       }
}

[glennpinto]

If you are working with Geneva or Helsinki, there is a new Reconciliation Engine that discovery uses automatically or it has to be enabled through the Discovery Definition > Properties (last property turn on) if upgrading from a previous version. If using this, the reconciliaton looks to Serial Number first. You can just put it lower in the hardware rule identifier entry order if you like. I have a video on this that you can view if you are using Geneva/Helsinki, then this functionality is available.

View Part 1

Datasource Precedence Recording - Box

[Amit Sharma4]

Hi Glenn

I found this link interested and applied the changes in my instance. I add 2 records in Reconciliation Definitions. One was manual entry and other was ServiceNow.

And set higher precedence of Manual entry.

In hardware rules I set higher priority for Serial number match on hardware table. But whenever i change the serial number manually on a CI and run discovery, Discovery always write back the serial number from it's side. Manual serial number is always wiped off.

Please guide me, what i am missing.

Thanks

Amitk

[phsdm]

There is a serial number cache that maps a serial number to a sys_id.   If there is an entry in that cache, discovery will still find the record.   Once it finds the record, it updates the record's serial number.