How to clean up an unmanaged CMDB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-22-2020 08:00 AM
I've been asked to clean up CIs in an existing CMDB where Discovery has been running unmanaged for three years. There are ~200,000 CIs. When I review the Configuration Console, everything type/option is turned on. I am seeking input/guidance on how to best approach cleaning up the existing CIs and managing the CMDB moving forward. Is there a way to reset and start over? If yes, is this advisable? If not, should I delete some CIs for certain classes? Should I take immediate action to change the Configuration Console settings? Thanks in advance for any words of wisdom.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-27-2020 03:09 PM
Indeed, try not to get overwhelmed with cmdb_ci for those very reasons. Start at cmdb_ci_hardware. Discovery populates all base classes (computer, netgear, printer ect) through that class. The supporting CIs will follow suit with whatever you decide is best for those not discovered in ages.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-27-2020 02:40 PM
good suggestions so far. My suggestion will be to explore a kind of Blue Green deployment where you can stand up a new instance of SN and have discovery populate the CMDB. The benefits:
- It allows you to compare easily new CMDB vs Old; identify the gaps and then target those gaps. An example if you find that the largest number of change request you do are for CI Class = Server then you know that any deviations there need to be addressed first.
- SN discovery does not delete the devices that it no longer can discover, that is if it discovered a server on Nov 1 and then not on Nov 10, then the entry discovered on Nov 1 will not be deleted it would just not updated with the latest scan date of Nov 10. So a new CMDB will save you this hassle because now you would see what is really active on your environment
- For your question related to unknown source, I would encourage you to review identification and reconciliation rules once. Please look at my following article
Please like or comment or accept solution so that the answer or article helps others with a similar question. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-27-2020 02:40 PM
good suggestions so far. My suggestion will be to explore a kind of Blue Green deployment where you can stand up a new instance of SN and have discovery populate the CMDB. The benefits:
- It allows you to compare easily new CMDB vs Old; identify the gaps and then target those gaps. An example if you find that the largest number of change request you do are for CI Class = Server then you know that any deviations there need to be addressed first.
- SN discovery does not delete the devices that it no longer can discover, that is if it discovered a server on Nov 1 and then not on Nov 10, then the entry discovered on Nov 1 will not be deleted it would just not updated with the latest scan date of Nov 10. So a new CMDB will save you this hassle because now you would see what is really active on your environment
- For your question related to unknown source, I would encourage you to review identification and reconciliation rules once. Please look at my following article
Please like or comment or accept solution so that the answer or article helps others with a similar question. Thanks
