How does operations agent work when a server is decommissioned?


Can anyone help me understand how operations agent works when a server itself is decommissioned and is not pingable. 

I have few linux and windows servers that are decommissioned but HP Operations agent on the specific server is still being discovered as a CI in RTSM. How can I avoid this situation so that Operations agent won't get discovered on the server which no more exists?

Thank you in advance,

  • you need to delete the node manually in the UI or with opr-node.

  • Hi  

    Thank you for the reply!

    Any idea, how this can be handled/managed when there is an integration between separate master UCMDB & RTSM?


  • How do you find out if a server has been decomissioned?


    I have used an OO call to the REST API of the ticketing tool in question that queries the REST API for the state of the server in question, and if that state is the equivalent of decomissioned, executed an automated flow via Operations Orchestration (OO) or Ansible, SCCM, puppet, chef, etc. to remove the Operations Agent automatically. 


    You can also use an RTSM/uCMDB Enrichment Rule that ages out Operations Agents that fail to respond to Health Checks within a certain period of time.


    I await your  reply.

  • Hello , 

    Thank you for the reply.

    Could you please provide some more details about the enrichment rule.

    How can I age Operations agent of server that fails to respond to Health Checks?

    Thanks in advance,

  • Within uCMDB/RTSM:


    The aging period is set per CI type as a static attribute in the CI Type Manager Deletion Candidate Period.

    Deletion candidates are reviewed and managed in the CI Lifecycle module.

    If the CI remains untouched for a longer period of time (by default, 40 days), the aging mechanism deletes the CI from the system. In other words, aging deletes CIs and relationships that are no longer relevant, that is, have not been accessed for a specified period of time (by default, 40 days).




    An Enrichment Rule could also be created in order to make this happen for you.

  • Hello  ,

    Inorder to have the CIs aged, last access time should not get updated everyday. In my case, like I mentioned in the post, last access time of operations agent is getting updated everyday though the server is not pingable. Therefore, Operations agent won't get aged even if enble aging attribute is set to true.

    Please let me know  if I understood your reply differently.



  • I get it. In this case, I would use ovconfchg on the management servers so that you can create policies to capture Internal/OpC events and use an automatic action to decommission the node, remove policies, whatever you can tell me in plain English you want to have happen if a node Health Check fails for X amount of time.

    To get internal messages of an agent, you can set OPC_INT_MSG_FLT in the eaagt name space (without OVRG server):

    # ovconfchg -ns eaagt -set OPC_INT_MSG_FLT TRUE


    BUT, to get all internal messages from all nodes and also from the server processes on the management server,

    you will need to set it in the opc namespace:

    # ovconfchg -ovrg server -ns opc -set OPC_INT_MSG_FLT TRUE

    I would filter for message group "OpC" and message group "OpenView" (messages from L-Core components, e.g. ovcd when re-starting an aborted process). I would not use Application, as that can have several values.


  • There is also this content pack from the ITOM Marketplace that I just remembered about, which might assist you: