MarkWalther asked a question.
I know this topic has been asked and answered multiple times, but I would go take it a step further. We know SNOW creates duplicates based on certain changes to an Asset, (name, OS, etc). The older asset entry eventually goes away in SNOW through Quarantine and removal of older Quarantine devices.
In my case, those duplicates make it into our ServiceNow CMDB and are "not" removed. Question, is there a reason to keep those old CI's or records? Some Lifecycle rules say yes. Our main piece of data is the Service Tag or Serial Number for the Asset. That doesn't change and is the one consistent ID that follows that asset. Name could change, OS could change, but serial number doesn't.
In our ServiceNow CMDB duplicates show up as "duplicate of" the Active asset. We can filter those out but any concerns I am not thinking of for keeping the dup CI and just hiding it?
Any thoughts on this is appreciated.
Hi Mark!
My thoughts is that there is no silver bullet with regards to automation - you will always end up with a few duplicates for different reasons. Just to set the expectations right...
Any proper CMDB - regardless of system (ServiceNow or other vendors) requires a CMDB manager. Snow in itself will do a pretty good job but not perfect (for example instead of quarantine after a set number of days, I would prefer that Snow immediately removes AD Enabled=no for Windows machines, or if you could have a much shorter quarantine time (for example 3 days) for servers).
But I haven't answered your question haven't I? I think working systematically is the key here - whether it is done through automation in Snow/ServiceNow/xyz or by hand. And auditability - when you do something (delete a device, de-duplicate, ...) you must document it.
Since you specifically mention ServiceNow CMDB there is specifically Remediate a de-duplication task (servicenow.com). You have to identify duplicates, decide what to do (sometimes they are true duplicates and then one have to be assigned as the valid one, or sometimes they are not duplicates, and so forth).
I don't know whether this helps you in your thought process?
Thank you, all good points. I do want to keep a history of some machines. But the fact that SNOW creates a lot of the duplicates, renamed, OS upgrade, etc. do I really need that history? Or find some way to hide older dups?
I will look through the document you linked and see where that takes me.
Thank again.
Suggestion: replace Snow with ServiceNows own discovery. The downside is that this would increase the cost as ServiceNow Discovery is licensed, but the upside is that you keep the CMDB within its own ecosystem. Using Snow to populate the ServiceNow CMDB seems to be more problematic than beneficial? But following this train of thought might land in the SAM pro module, and this is a much larger change than can be covered here :)
I'd rather keep SNOW at this point. We'll just need to work through the problems.