Install status (install_status) of windows servers(cmdb_ci_server) is being set to "retired"


Description

The install status (status) of windows servers is being set to retired by System User. Although the server is being actively discovered, the install_status does not turn back to "Installed". This in turn causes operational status of the CI to be retired.

Release or Environment

All

Cause

The cause of this is a Business Rule - Cascade deprovisioned status to server that was added during the Discovery and Service Mapping plugin upgrade to SR - ITOM - Discovery and Service Mapping - 202007.
https://<instance_name>.service-now.com/nav_to.do?uri=sys_script.do?sys_id=225555a1535d5010be52ddeeff7b127b

This business rule "Cascade deprovisioned status to server"  was added as a fix for a PRB1408405.
The issue addressed in the PRB1408405 is below:
When we receive notification (e.g. from vCenter, AWS, etc) that a VM has been deprovisioned, we mark the corresponding CI in such a way as to remove it from subsequent daily license counts. However, when that VM is linked to a Server CI (of type cmdb_ci_server or subordinate), that CI is not similarly marked. This causes the daily license count to not be reduced. The deprovisioned status needs to be carried through to the linked Server CI in order to properly reduce the subsequent daily counts. The VM CI will be marked "teminated/retired" but its linked Server CI will not, which will cause ITOM Visibility & Health license counting to be inaccurate.

The Server CIs are  getting marked as retired by the BR was an expected behavior according to the fix provided on the above mentioned PRB.
Navigate to the class cmdb_ci_vm_instance and verify if there is a vm instance present with the same name as the server. On the audit history of the vm_instance check if instance was terminated/retired at the time when Windows Server was set to "retired".

The VM_instance record could have set to terminated/retired due to a delete event coming in for the vm_instance.

Resolution

There could be two possible solutions:

1) If you would like to avoid this issue, you can set the below business rule to inactive although this may cause the license counting issues:
https://<instance_name>.service-now.com/sys_script.do?sys_id=225555a1535d5010be52ddeeff7b127b

OR 

2) Create a Business Rule so that if the VM instance goes back UP, change the install_status of the windows server record to "Installed"