CMDB IRE Engine - Ignore retired CIs

[Chaz_]

Hi,

I would like to know whether it is possible to have the CMDB IRE engine ignore CIs which are retired in the CMDB.

Currently, we face an issue where CIs get retired in the CMDB. Then a datafeed will come in and using the reconciliation rules in IRE it will revert the status of the CI to Operational or update some of its attributes.

Is there anything which can be done on the IRE end to prevent CIs being set to Operational if they are actually retired?

The datafeeds could be cleansed of retired CI information, but I am looking for a solution on the IRE end.

Thanks.

[Fabian Kunzke]

UPDATE:

What @CMDB Whisperer pointed out is indeed working. Learned something new today. To be fully honest, i wasn't aware of it. I would still not do this as it will impact all datasources, not just the datafeed running the risk of creating duplicates for every retired CI (e.g. if the discovery finds it in the network again.

Hi,

The IRE uses two main things to work:

1) Identification Rules (matching any third party record to a CI based on rules/filters)

2) Reconciliation Rules (managing which datasources are allowed to update parts of the CMDB)

Technically speaking both could aid you. Changing the Identification rules to ignore any "retired" CIs would require an update to all of the rules though. This in it self is probably not worth the effort.

Secondly, if your datafeed is an external datasource, you could set up a reconcilliation rule preventing the datasource from updating any CIs in the retired state. That however would require the feed to be external and bound to a datasource.

Your best option is probably to revisit the datafeed and change the interaction there. I would not recommend either of the two abovementioned ways, as they are general rule. They apply to more than just one action in your datafeed (identification rules even work across all data sources).

I'd change the datafeed to ignore retired CIs instead.

Regards

Fabian

[CMDB Whisperer]

@Fabian Kunzke - Whether to use inclusion rules or not is certainly a preference to be considered.  There are pros and cons.  But I do find it is ultimately preferable, as long as you have solid rules and processes for what Retired actually means.  If something is truly Retired then in theory you should not see it get discovered again.  The gray area is where an asset may enter the Retired phase because the CI is marked as retired but then get repurposed and redeployed.  The plus is that you will have two separate CIs, which is in my opinion a good thing.  The negative is that you will have two separate assets, which is not good.  While you can make the argument they are two separate CIs, but they are most definitely not separate assets.  Asset redeployment is an area where ServiceNow doesn't do a good job out of box, although there are ways to enhance it.

[Fabian Kunzke]

Hello,

I don't know if i agree. But at this point i have to. There is a little information missing, but based on what i understood using an inclusion rule would be very dangerous in this scenario.

In my opinion the scenario here is not well managed either way. There should not be any undocumented way of how something is set to retired, nor should there be one where a device is set to operational again. That said, creating a duplicate for a device - no matter it's operational state - is always worse.

And that i think is where preference comes in. I rather have a device switch back to be operational on accident than have a device which should be operational be stuck in retired (for monitoring reasons). Further, i much rather have a device switch from operational to retired (asset and CI) back and forth than a duplicate.

I don't think there is a good answer to this. To quote my paragliding teacher when asked what to do when flying into a thunderstorm:

"Why would you ask that? 'What should i do after i touched an outlet?' Just don't do it."

I don't know why there is a datastream that sets the status. I'd much rather not have that in place or whatever causes the reason for it to be needed. Both seem better options than chaning the fundamental way how CIs are matched in the CMDB...

Other than that: I think your answer is probably the correct one.

Regards

Fabian

[CMDB Whisperer]

It's a question of identity.  The philosophical question worth asking is: if I have a computer, say, a Dell Server, and I install Windows Server on it, it's a Windows Server.  I deploy it, use it in Production for a while, for a specific customer, Customer A, and then when I'm done with it, I shut it down and decommission it, and then mark it as Retired (install_status, that is).  The asset state is synchronized to Retired, but it still has some useful life as it is in working order and the model lifecycle is still supported by Dell.  But the asset doesn't have a substatus yet, and someone needs to figure out whether to sell it, dispose it, etc.  They decide to put it back In Stock for someone else to use.  At this point it's the same asset.  Now someone else needs a Linux Server for a completely different purpose, only for Development, and they get this repurposed server deployed to them.  Is it the same Asset?  Yes.  Is it the same CI?  Well out-of-box you would get the same CI, and you would need to switch the class of that CI from Windows Server to Linux Server.  The problem, I pose here, is that this Development team has a CI with links to Changes and Incidents that have nothing to do with their development purposes and have relationships to CIs that are for a customer they have no business looking at. 

Both the CI classification and the historical continuity here are good illustrations, from my perspective, that they should not be the same CI, but they should be the same Asset.  In other words, there should be a way to unlink a CI from its asset, and create a new CI on that asset when it is redeployed.  Again, that's not how ServiceNow works today.  But I would argue this would be a preferable scenario.