Discovery Best Practices

[alan_lowrance]

When our Discovery was first set up, it was changing the asset and ci status to "Installed", but now I have noticed a lot of things still "In Stock" when they are being discovered... so trying to find where that code/setting would be running from.   I'd like to restore that functionality but also tweak it so it won't set it to Installed on the very first time it's discovered but maybe the 2nd (by checking the old "last_discovered" date within a week of the current date or something).   Maybe Steve Bell (Cloud Sherpas) or Doug Schulze can chime in?   Also, what are the most common problems you see with Discovery configuration that everyone should check their instance for and avoid?

Thanks!

[doug_schulze]

Alan,

That value is set by default by the mere fact that installed is the first available choice..   We have built a CI Lifecycle program that we premiered at K15 that address this very situation and more ..

Discovery 301: Optimizing Discovery for your Infrastructure

Hoping I am on track with what you are looking for in an answer...

[alan_lowrance]

So on very first discovery (ever) AKA: CI insert, it's set to Installed.   But if the machine is later taken back off the domain, reimaged, set to In Stock by a technician, etc.: there's no logic to set that state back to Installed when it pops back up on the network?   Okay, so where would I make that logic... as a Discovery Business rule?   Do those run at the end of the entire discovery job or after each item?

[doug_schulze · Accepted solution]

You are correct.. out of box, that field is maintained manually....

To change it first think about the phases, particularly our identification phase.. IF we sync up on that record that yes a BR would need to fire that changes hardware state back to installed and that would be per CI on the hardware (cmdb_ci_hardware) table....

But now think of it as part of a full lifecycle program.. if something is 'in stock' and discovery syncs on the record should it have been discovered? Meaning a more robust change process should have had the request for the server in flight and the state of that CI should have been marked as pending install.. then discovery finds it and says 'yup, it was waiting for me'.. if its still in stock did someone execute the shenanigan plan and didn't tell anyone that this in-stock item is now 'installed' for that I would trigger an exception so someone can figure out who is using this system without a proper change request to put it back online...

But were talking pure process here...