How to deal with related CIs when retiring a CI?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-31-2022 12:52 PM
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.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-08-2022 09:49 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-20-2023 09:06 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-20-2023 08:49 AM - edited 09-20-2023 08:50 AM
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.!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-20-2023 09:04 PM
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.