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

Anders Pr_stega · ‎04-26-2018

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

Community Alums · ‎05-22-2018

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

View solution in original post

Anders Pr_stega · ‎05-24-2018

Hi Ben

This is great. We're in the process of helping this customers processes surrounding the asset creation part and this will work!

Before closing down, I need to share these thoughts:
Due to the lack of I&R in the SCCM 2012 v2 plugin we created our own I&R Version. Since the 2012 v2 version identified existing CI's via 1) a dedicated table that it shares with Discover and 2) querying on the correlation ID field I decided to mimic that by configurering an identification rule with the highest order on the correlation ID. It does seem that it would not be damaging to just clear that identification field lookup, allowing for the serial_number to be the identification field, but it is very interesting to observe that enabling the new updated ServiceNow plugin for SCCM 2016 coming with Kingston in a developer instance auto-creates an Correlation ID identification rule on top. I don't know if this is cause for concern?

All is good - thank you for taking your time Ben, and also thank you to jonGriff for assisting!

-Anders