How to avoid creation of CI's when Discovery runs

[mechamberlain]

We're trying to get discovery at my company to NOT create Computer CI's, even if there is matchable data discovered and no CI matches in the CMDB.   The result would be that Discovery only updates existing matched CIs and does not create new CI's.

Is there a way to make this happen?   I'm thinking a change to one of the out-of-the-box Discovery Identification scripts might do it (see below), but I'm stuck.

Has anyone tackled this?   Thanks in advance for your time and attention.

[Michael Ritchie]

Tagging aleck.lin and doug.schulze for further assistance.

This all starts with the appropriate multisensor.   Out of the box those call the DiscoveryIDSensor script include and that has the code that detects and creates the CI if required.   Your solution will be to update that code, but I will defer to Aleck and Doug for the best way to accomplish this.

[mechamberlain]

Thanks, Michael.   I thought that was the right approach.   Aleck's out-of-the-box code is really nice...so I don't want to mess it up with no guidance!  

Hopefully he or Doug can give me some advice.

[aleck_lin]

Hi Martin,

Before I answer your question, just wanted to confirm that you're indeed using the classic CI identifier framework that I had written. The reason I ask is because depending on the version of your instance and how long you've had Discovery, it might be using the newer CI identification engine. I know the former much better than the latter. One suggestion I have is to not make modification to the OOB code anyway, but by adding a business rule in the cmdb_ci table (maybe cmdb_ci_hardware to be narrower depending on your use case) to not allow the MID server user to create a new CI. Have you tried that?

[mechamberlain]

Thanks, Aleck.   We're still running Fuji.   I think we are going to go with the business rule approach rather than tweak the OOB CI Identifier scripting.   Hopefully we don't run into any issues there.

Thank you, very much for your suggestion.

Marty