CMDB CIs Related Items field (Application : Server relationship)

[Amit39]

Hello Team,

Need to understand regarding CMDB CIs Related Items field (Application : Server relationship) status change ("In Use" to "Retired".)

While changing the status of a Server CI items (Servers->Linix, Windows, AIX, Solaris etc..) , what are the most important steps we need to follow from CMDB sides.

Is Server CI relationship with any applications, if yes, do I need to first remove the "relationship" for example : removing the "Used By" and then change the status of the Server CI from "In Use" to "Retired" in CMDB_CI_Server class.

Or I need to remove all the necessary relationship between server and application and then changing the status of that application from "In Use" to "Retired".

Or Directly will change the status from "In Use" to "Retired" without changing any of the information in CMDB

Thank you in advance.

Regards,

Amit 

[Pedro Lopez · Accepted solution]

Hi Amit,

You can add/remove CMDB relationships by using this table "cmdb_rel_ci". Your idea about change the status and then remove the CI relationship is good. Just consider other impacted areas like Business Services and Service Mapping. You can use Business Rules to accomplish your solution.

I hope this helps.

Regards,

Pedro Lopez

[Jennifer Phelan]

Why isn't there a status field in the cmdb_rel_ci table? Unless I'm missing something, it seems very strange not to have an out of the box way to manage the relationship when either the parent or the child has a retired status. For example, if an application only runs on one server and that server is retired, then shouldn't the application be retired, too? If the application runs on multiple servers, and one of those servers is retired, then shouldn't that specific  relationship be retired as well?

If the relationship is deleted, then we don't have an historical record. Worse, we might not be able to recreate the relationship if we realize later that a mistake is made. (Yes, yes, you can test on the lower environments and promote up, etc., etc., but experience has shown that you can't always test all scenarios.)

Seems odd that everyone has to create their own approach for managing this integral element of the CMDB. 

If there IS a better way to manage this, then please let me know.

[Pedro Lopez]

Hi Jennifer,

Welcome to the CMDB World! 🙂

Each company has a different procedure for CMDB depending of the business. Everything that you said is correct. However, the most important for a tool like ServiceNow is data and maintenance. Based on my experience, this is the best practice:

. cmdb_rel_ci table is just to create parent/child relationships. For the status control, we need to validate that to each table itself: Server Table, Application Table, etc.

. It is not a good idea to delete a relationship based on status. If a Server is retired, we should set the value as "Retired" to the Server Table. And if it is related to an Application with only one Server, then the status of the Application should be "Retired" too. The status, relationship and all information will be there for audit or history.

. Discovery is the "OOB" process to create these relationships. However, depending of the business, this can be an automated process. Example, lets say you have a form for "New Server" and the user will submit this form by selecting an Application. In your workflow, you can create this parent/child relationship automatically. And everything will be managed by Discovery and CMDB.

Hope this helps,

Pedro Lopez

[Jennifer Phelan]

Hi, Pedro:

I appreciate your response, but it does not answer my question. I am by no means new to Configuration Management or CMDBs. I am new to having to use ServiceNow while holding the Config Manager role. 🙂 I am able to see active CIs associated with inactive CIs and the other way around. We can all make adjustments within ServiceNow to suit our own company needs, but it seems like this issue affects everyone since relationships are an integral part of the CMDB. 

I inferred from the statement you previously made, "You can add/remove CMDB relationships by using this table 'cmdb_rel_ci'. Your idea about change the status and then remove the CI relationship is good.", that you were suggesting the removal of relationships within the cmdb_rel_ci table. My response was that this probably wasn't a good idea because you won't have a history and you might not be able to restore the previous state.

My original question is why ServiceNow does not include some sort of indicator when there is a relationship between two CIs where one is active and the other is not. The way things are now, ServiceNow shows relationships between even when one of those CIs has been marked as Retired. I was suggesting the addition of a status field to the cmdb_rel_ci table. 

After some more thought, I am thinking the better approach would be for ServiceNow to visually show when an active CI is still related to an inactive one. Perhaps the connection could be shown in a different color and/or with a different type of connecting line. I looked at the health status jobs and did not see anything OOTB for flagging the RetiredCI - to - ActiveCI relationship.

The CMDB is currently set up with a direct connection from server to application. We have not yet moved to the Common Services Data Model (CSDM). I will provide more details in my examples this time.

Example #1: SERVER_1 is running more than one application, but one of those applications, APPLICATION_A, has been retired. The Status(install_status) field for APPLICATION_A is already set to "Retired". The status for SERVER_1 will remain as "Installed" since it is still active. In the SERVER_1 record, ServiceNow still shows the relationship between the server and all of the applications, even for the retired application, APPLICATION_A. This is misleading because it appears that the retired application is still running on the server.

Example #2: Five servers are running an application, APPLICATION_B. One of the servers, SERVER_2, is retired. The Status(install_status) field for SERVER_2 is set to "Retired". In the APPLICATION_B record within ServiceNow, it still appears that it is running on five servers, including SERVER_2, even though it is actually only running on four. This, too, is misleading.

I want to know what other people are doing for these types of situations.

Thanks!