Cleaning CMDB Tables

[jesusemelendezm]

I am interested to know if It is recommended to clean the CMDB up to start from scratch, following this plan:

1) TURN OFF discovery schedules.

2) Clean up CMDB except business services (because these are already in use).

3) Upload inventory manually from excel through transform maps.

2) TURN ON discovery schedules to refresh and update inventory with configuration information.

Any thoughts?

Thanks,

Jesus E. Melendez M.

[brendanaye]

The matching on Discovery is actually quite a bit more complex and configurable than CI_name == CI_name.

In CI Identifiers you can set ordered lists of how CIs are identified for matching.   The generic name matcher is disabled by default, so more information is needed for identification than just name.

Make sure you also consider CI Relationships and have a plan to address recreation of those if you dump you data.

[johnnyjava]

I'm also learning that CI Identifiers are only active PER TABLE, so there were several very active tables in our implementation that did not have out of the box identifiers. I have worked to create Classifiers that name things in a logical way for our needs, and pair those with Identifiers that check for duplicate names in the same table.

Once those are working, I can watch for records that aren't updating and consider dropping them.

Luckily I got a hold of our CMDB before we had been online with SN for too long.

[Jason Stephens]

I think between the answers from Mark, Ben, and I, you see that you need to think about this process before jumping right into it.   The idea is pretty simple, but there are a lot of moving parts (as our comments show).   Just make sure you have a good plan whatever you decide to do.

Jason

[JBark]

I've discussed doing this with several folks from our implementation team and SNow. I was getting a lot of push back from management about the sheer volume of CIs being discovered and they felt it needed to be "cleaned up"

Beyond the fact that I couldn't teach them to just start typing and let SNow filter for them, we set the lookups to filter out most of the "junk" and only let the lookups show what we wanted them to show. It took awhile for us to get it just right, but it works.

As I dig into CI relationships (more coming on that issue) I'm discovering that the "junk" is not really junk and will be most needed down the road.

[poyntzj]

We are looking at our CMDB data too.

I have written a couple of background scripts that will disable any business rules, clear a cmdb_ci or dscy table and then enable the business rules again.

You need to establish which tables(s) have data and which you want to keep.

While I have done this on our DEV instance a couple of times to make testing the revised discovery scans / settings, we have not progressed this onto TEST or PROD.

Management want to keep the existing data, but it is poor, from various sources and masses of duplications.

I am torn as I can see the benefit in keeping some, but realise a lot of it is so poor it really needs removing and starting again.

We are on Calgary and I know that some of the CI information does not show "last updated" even if it was scanned a few minutes ago - this makes it hard to simply add a field so we can mark the device has "obsolete" and then hide it from view.

We have a consultant in next week to chat with us about the best way to progress forwards on this