The Problem with Duplicate CIs
Duplicate configuration items are a serious problem for any Configuration Management Database:
- Inaccurate inventory asset reports
- Could cost your company money on new licenses and maintenance
- Creates confusion when users are submitting ticket requests
- Makes it difficult to report on incident, change and problem trends
- Makes configuration management more difficult
- Can undermine the trust in configuration management
Getting rid of duplicate CIs is always a high priority for any configuration management team.
ServiceNow Discovery Preventing Duplicates
Each configuration item record is uniquely identified based on one or more field values specified in a CI Identifier Rule. A configuration item record is considered duplicate if the field values that uniquely identify it match the field values of another record of the same class. By default, configuration items of class Hardware and all subclasses (Computer, Server, Unix Server, Windows Server) use the OS Serial Number as a unique identifier. When SN Discovery or Service Mapping discovers a CI, the sensors and patterns use the internal function SNC.IdentificationEngineScriptableApi.createOrUpdateCI to send the CI to the CMDB. If a CI already exists with the identifier attributes for that particular class, it is overwritten, otherwise a new CI is inserted. Here is sample JavaScript code invoking this function:
_________________________________________________________________________
var payload = {
items: [{
className: ‘cmdb_ci_aix_server’,
values: {
name: ‘Aix Server 900’,
asset_tag: ‘Asset 900’,
ip_address: ‘10.20.30.11’,
mac_address: ‘ABCD1234’,
ram: ‘4096’,
cpu_name: ‘SNow’,
serial_number: ‘123456783’,
cpu_type: ‘SNow’
}
}]
};
var jsonUtil = new JSON();
var input = jsonUtil.encode(payload);
var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI ( ‘ServiceNow’, input);
- gs.print ( output)
