How to deal with related CIs when retiring a CI?

jmoore
Mega Expert

Hi,

I have a few questions regarding retiring related CIs; regardless whether the process is manual or automated. As an example, I have an IP Switch that has been retired/decommissioned. We have set the Operational status to Non-operational and Status to Retired for the IP Switch.

The IP Switch has related CIs shown in the related lists. For related CIs that have Operational Status and Status fields, I can set the Operational status to Non-operational and Status to Retired. For related CIs that do not have those fields, what is normally done (e.g. Serial Numbers, Switch Bridge Port Tables, etc.)? I see there is an Absent field that I can set to True. Or are these CIs normally deleted?

  • Switch Partitions - has Operational Status, Status
  • Switchports - has Operational Status, Status
  • Network Adapters - has Operational Status, Status
  • Serial Numbers - has Absent
  • CI IPs - has Operational Status, Status
  • Switch Bridge Port Tables - has Absent 
  • Switch Forwarding Tables - has Absent
  • Switch Spanning Tree Tables - has Absent
  • Network ARP Tables - has Absent
  • Device Neighbors - has Absent

The process may be dependent on our business, but I am curious how others handle this type of situation to keep the CMDB clean/up to date.

find_real_file.png

Thanks!

8 REPLIES 8

PG2
Tera Expert

An interesting and insightful article!

Do you mind elaborating on the status of no longer discovered CIs? The article suggests using the Non-Operational Operational Status, and I'm assuming the above comment about Absent refers to the install status?

My question is, how does this relate to the new CSDM lifecycle stages? There's no obvious mapping between the old and new.

https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/csdm-implementation/concept/csdm-lifecycle-states.html

emir
ServiceNow Employee
ServiceNow Employee

Sorry I have not seen this message until now.

Follow the Migrate to CSDM life cycle standards guide to understand the mapping between old and new. 

Anshu10
Tera Contributor

We have integrations like SG-SCCM ,SG-INTUNE, Discovery in system. There is a requirement to retire a CI and to change the operational status of all its related classes, if it is deleted from source system like Intune.

 

But in case that CI is re-discovered , same CI should be moved back to operational status and its related child classes should come back

I am using data manager policies to retire CIs however not sure how to re-discover or bring back all related classes in operational status again. Is there any functionality or any custom piece that need to be developed?

 

Which attribute should be used to retire a CI - Most recent discovery or Updated or checked in? or a combination.

@emir @doug_schulze  any comment please?

thanks in advance.!

emir
ServiceNow Employee
ServiceNow Employee

This feels like a process problem and not a technology problem.

If something has been deleted/retired it should not be found again. Maybe the retirement should be managed through a proper decommissioning process, and that process then feeds SCCM and NOW.

OOB the behavior on the operational table is: if it is retired, it will be marked as installed when it is rediscovered. You will need to watch that status change and then apply it to its children.