Field Normalization for Lenovo Computers

[Carlos Chaluisa]

Looking for some advise.   Perhaps the approach we took to tackle this issue may not be the most appropriate and I definitively welcome all recommendations.  So here is the scenario:

We have a good number of Lenovo Computers in our organization.  When running Discovery or Importing from SCCM, we get the Model field populated with data like this:

LENOVO 20HES4UV00

LENOVO 20FN002SUS

LENOVO 7844P7U

To get around this we decided to enable the Field Normalization Plugin.  We created our normal values and the corresponding rules to run against the Display name field of the Asset table which is the field we would like to use to group the computers by model.  After running the data job, we do get meaningful information in the Display name field:

Lenovo ThinkPad T470

Lenovo ThinkPad T460

Lenovo A70

The challenge we are finding is how to run these rules on schedule. (or triggering the data job)  As Discovery runs and finds new devices these of course are recorded with the original model information.  

Thanks for your help in advance

[akash_mehta]

Carlos:  For SCCM the data is available, you will need to modify the SQL query in the Computer Identity Data Source. Then modify the transform map to pull in the correct model value.

For the SQL statement you can add the following:

v_GS_COMPUTER_SYSTEM_PRODUCT.Version0 as Version

That will get you the friendly name for Lenovo models.

For the Transform Map - there is a pre-script that handles mapping the model value, you can change it to look like this:

function setMakeAndModel() {

//updated for lenovo changes

var realModel = '';

if(source.u_manufacturer == 'LENOVO'){

realModel = source.u_version;

}else{

realModel = source.u_model;

}

var mm = MakeAndModelJS.fromNames(source.u_manufacturer, realModel, "hardware");

    target.model_id = mm.getModelNameSysID();

    target.manufacturer = mm.getManufacturerSysID();

}

I'm not 100% sure what needs to be done on the Discovery side, but this should at least help move you forward.

-Akash

[CMDB Whisperer]

While this will help you as an asset manager to avoid a large number of models which don't map to the friendly names, it does beg a question about whether this workaround is compatible with other products, in particular HAM Pro. 

What we've seen is the model used by most manufacturers is analogous to the model family for Lenovo, so the number of actual individual models reported for Lenovo is much higher than for other manufacturers.  For example, there are over 6400 different model numbers that all map to "Lenovo ThinkPad T470", as shown below:

So if you want to take advantage of HAM's model normalization features and lifecycle management information it would seem to me that your existing models will not map to HAM's normalization library.  So one of two things has to be true: either ServiceNow needs to rethink how it addresses Lenovo devices and provide some "grouping" of models into parent models/model families that can be used for normalization and lifecycle data, OR we will be living with Lenovo-specific exceptions that will continue to make the lives of asset model managers a nightmare for the foreseeable future.

So far this doesn't seem to have a solution but I will be watching it.  Also eager to know if there are others out there that have encountered this and what other solutions have been used.

[CMDB Whisperer]

As a follow-up, I spoke with the HAM product management team about this and they confirmed that if you are using or plan to use HAM Pro you should use the standard model names as captured by the system and should not customize this to use the model family.  As for what that means about the model management capabilities, I was advised that using the Substitutes table would be a recommended method of tying the individual "model configurations" up to a parent model that represents the "model family" so that it is easier to integrate into your asset management and catalog management processes.  However, it is worth noting that at least at the current time, there is likely quite a bit of additional development required in order to do this.