Discovery and unexpected Lenovo computer model information

[jas101]

Hi everyone.

We have noticed that Discovery is not pulling in Lenovo computer model names/numbers as expected which is causing problems when it comes to reporting etc. Dell machines populate Model ID as follows e.g. Dell Inc. OptiPlex 760 which is logical/great. Lenovo CIs on the other hand populate model IDs as e.g. Lenovo 4291YYH

I.e. with all seemingly unique model IDs (not the serial tags) whereas here we would expect e.g. Lenovo ThinkPad X1 Carbon, Lenovo ThinkCentre M93p Tiny or Lenovo ThinkPad X220 (we have only 3 different models in use currently).

Our EUC team have identified that this happens because Lenovo stores their "ModelName" in a different WMI class than other vendors (Win32_ComputerSystemProduct as opposed to Win32_ComputerSystem).

I'm presuming plenty of other organisations must have experienced this issue and if so how have you guys remedied it? Is it possible to customise the probe to bring back Win32_ComputerSystemProduct for Lenovos only!?

We have observed that the start of model IDs are consistent with the actual model e.g.

ServiceNow Display Name	Actual Model Name
Lenovo 10AAxxxxxx	Lenovo ThinkCentre M93p Tiny
Lenovo 10ABxxxxxx	Lenovo ThinkCentre M93p Tiny
Lenovo 20BSxxxxxx	Lenovo ThinkPad X1 Carbon 3rd Gen
Lenovo 20BTxxxxxx	Lenovo ThinkPad X1 Carbon 3rd Gen
Lenovo 429xxxx	Lenovo ThinkPad X220

So I'm presuming we could create a business rule - although Discovery would overwrite this info each time it scans right? I.e. far better to fix at source presumably.

Any help much appreciated, I still await Hi's feedback on this.

Many thanks!

Daniel

[jas101]

Hi Ben, so Lenovo have confirmed that the values are consistent globally which is good news I suppose!

For now we are going to add a new field to the CI Computer form to record the Lenovo model info we want to see, which will only show if the manufacturer is Lenovo.

We can obviously do a bulk update for the various models using the table in my first post but I figure a scheduled job executing a script will be best for this going forward? If so are you (or anyone) please able to assist on the necessary script please. I have amended an existing one which we currently use to set values on our user table. So currently the test script looks like this:

// Lenovo ThinkCentre M93p Tiny

var gr = new GlideRecord('cmdb_ci_computer');

gr.addQuery('model_id', '3286601237d01200db718d2754990e00');

gr.query();

gs.print(gr.getRowCount());

while(gr.next()) {

gr.setWorkflow(false);

gs.print(gr.name);

gr.u_lenovo_model = 'Lenovo ThinkCentre M93p Tiny';

gr.update();

}

I did this as a test and it works as expected so what I need to know now is, on the gr.addQuery line how can I bring back results where model_id display name STARTS WITH Lenovo 10AA ?

I can then copy and amend this for the other models. If need be I will post this query as a separate post.

Many thanks in advance!

Daniel

[jake_mckenna]

I would say if you are looking to tackle the use of Lenovo models updating the sensor and probes might still be an option with the understanding that this is a change to the OOB functions. You would need to do two things:

1. Add the wmi probe to the "Windows - OS Information". I believe you would be looking to add Win32_ComputerSystemProduct.Version.

2. Update the sensor(Windows - OS Information) to check to see if the manufacturer is Lenovo and if it is change model being passed in to be the above sensor. Something like this:

       parseResult: function(result) {
               current.os_version = result.Win32_OperatingSystem.Version;
               current.os_service_pack = result.Win32_OperatingSystem.CSDVersion;


               var man = result.Win32_ComputerSystem.Manufacturer;
               var mod = result.Win32_ComputerSystem.Model;
   //Code to add
   if(man.match(/lenovo/i) != null){
   mod = result.Win32_ComputerSystemProduct.Version; //where Lenovo keeps their model names
   }
   //end of code to add
               var mm = MakeAndModelJS.fromNames(man, mod, "hardware");

Just a suggestion as another option to try to avoid errors. The biggest problem here is that you will have to make sure not to lose any functionality with upgrades to in this sensor and if found that another manufacturer was needing the same fix they would have to be added to this change.

[Community Alums]

Hi Daniel,

Is there a reason you do not want to look into using Field Normalization for this? I looked back through and didn't see a reason, so I'm not sure if I missed something there. It should get you what you need without scripting.

Ben

[Steve McCarty]

The only down side I see to normalization is that you will need to keep this list up to date.   Every time Lenovo uses a new model number (and there are a lot of them) you will need to add a new normalization record.   By changing the probe you can automatically get the information you want from the computer without having to maintain a list.

Either way you do it, I would definitely recommend keeping the Lenovo model numbers.   Those are required for doing warranty calls on Lenovo machines and can be used for downloading drivers or manuals and things.   Having that information associated with the CIs in ServiceNow has been very helpful for us.

-Steve

[CMDB Whisperer]

I concur that you should keep the Lenovo model numbers, as they will be necessary if you use HAM Pro, which (at least at the time of this post) has separate entries for each individual model number. 

That said, I think this will continue to be a very complex issue for sometime, as long as there continues to by ambiguity in the HAM normalization approach as it applies to Lenovo, and as long as the current approach utilizes MakeAndModelJS without even passing the model number.  Until we can reconcile the Discovery SCCM model creation approach with the HAM Pro model normalization and ASN import approaches, model management is going to continue to be a challenge, especially for Lenovo.