Asset mgmt best practice at PC motherboard replacement using SCCM plugin-based CI-import

[Anders Pr_stega]

Hi

If a motherboard is replaced in a laptop (example), it will have a new mac address and a new serial number, and eventually a get a new resource ID in System Center Configuration Manager (SCCM).

It will then be imported into ServiceNow as a new Configuration Item (CI) due to the new ressourceId in SCCM, which (out-of-the-box courtesy of a business rules) will cause the creation of a new asset and pairing with the SCCM created CI.

What this means is, that we now have two seperate representations of the asset and CI undermining that will cause a seperation of task history tracking tied to those, which is not how ITIL suggests it done. 

What is the best practice handling of this challenge in ServiceNow?

Cc. @bsweetser

[jonGriff]

If you go into Model Categories and select "Computer" (CI Class: Computer [cmdb_ci_computer]), then UNCHECK "Enforce CI verification", new assets will not be created when a CI is detected/created.

As for the motherboard replacement, generally you can set the replacement board to match the correct serial once installed in the BIOS, but the NIC MAC can't be set manually.

There's also ways of cleaning up the CMDB to remove old/duplicate/orphan data if that's required.

I hope this helps!

[Anders Pr_stega]

Thank you jonGriff - your answer is correct, relevant and helpfull.

In my effort to be concise I failed to mention, that this organization doesn't have the resources to verify every CI. Several thousand CI's come in batches and when created by SCCM those CI's needs to be manually "merged" with existing CI's resulting in an overwhelming manual process.

I should also have mentioned that I am aware that you can reprogram the bios to have the old device serial_number, and that - since the CI Identification rule order favor serial number over MAC - that would end up good. The more precise challenge I see is that the correlation ID (that maps to the Resource ID in SCCM) have an even higher order in the CI Identification list. The resource ID - being the unique identifier among SCCM-agent installations and each agent installation - is bound to the OS, and if the OS is whiped during motherboard replacement the new agent-installation will recieve a new Resource ID which eventually result in a new CI being created and if you do now have "Enforce CI verification" enabled you have that broken lifecycle I am trying to avoid.

I suppose that you (or ServiceNow) would argue that this is exactly what "Enforce CI Verification" is there for, and that organizations need to accept the implication of such a process (?).

[Community Alums · Accepted solution]

First off, Jon, your first statement is incorrect. Enforce CI verification, when checked, prevents new assets from being created. Deselecting it means that you will get new assets for every CI of the class associated with the Model category. I'm not sure this was your intended phrasing or if you meant the 'not' to be 'now.' 

Anders, if your customer is experiencing that high a number of CIs that require verification, it sounds like a process issue. WHY are so many CIs coming in as new rather than matching up and updating an existing CI? This would be the first thing to fix before any work is done around motherboard replacement. It is simply a bigger issue here. I would figure this out so that Enforce CI verification provides value rather than becoming a headache. That being said, also consider this: If you do not have Enforce CI verification on, then you are ending up with a lot of duplicate CIs in this situation, which may be missed without that verification flag. With good asset process in place, CIs that require verification should be an exception, not a rule. Determine why these are not coalescing properly and you will see a big improvement here.

Now, to your original question: as you stated in your follow up post, you can apply the old serial number to the new board. Many companies incorporate this into their motherboard replacement process for this purpose. And, as you also state, this takes precedence over MAC address, so this (kind of) gets you past. The issue is really is around that Resource ID. There are ways to configure the import so that Serial number takes precedence over Resource ID. This could be one approach so you would then be in the same situation as the MAC address (if you are burning the old serial number into the new motherboard). To do this, update the order of the Identifiers so that SCCM ID & Class Name is used after Serial number & Class Name.

Ben

[Ashish Kumar12]

Hey,

Great explanation, Ben. Really in simple word, you have provided a good idea on this.

Thanks