How to effectively decommission UIM Robots
search cancel

How to effectively decommission UIM Robots

book

Article ID: 136703

calendar_today

Updated On:

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM) Unified Infrastructure Management for Mainframe

Issue/Introduction

UIM Administrators need to know how to effectively decommission UIM robots in bulk and ensure that alarms, e.g., Robot Inactive alarms for those same robots do not persist. In some cases when the customer uses the pu command to remove a robot, within 2-3 days the Robot Inactive alarm returns and the robot can be seen under the hub in the Navigation window in IM as well as under the hub->Robots Tab.

Environment

  • Release: 9.1.0 or higher
  • Component: UIM - ROBOT

Cause

  • leftover references to the robot
  • niscache entries
  • robot stays cached in its hub's robot.sds file

Resolution

Aside from this recommended process outlined in the KB Article below:

How to delete robots in UIM when a VM with a robot has been powered off/decommissioned

https://knowledge.broadcom.com/external/article/117796/

And considering the fact that you could already be currently running a probe utility command to remove master devices by the cs keys,

You should also remove the robot from the hub, and you can do this via command(s). Unfortunately you cannot list more than one robot at a time to be removed from a hub but you can duplicate the command for each machine, or script it and read in a file with a list of decommissioned robots and use variable replacement of some kind for the robot hostnames to be decommissioned.

Here is an example command:

C:\Program Files (x86)\Nimsoft\bin>pu.exe -u administrator -p <password> /<domain>/<hub>/<robot>/hub removerobot <robot_hostname>

Sep 6 10:43:58:447 pu: SSL - init: mode=0, cipher=DEFAULT, context=OK

Sep 6 10:43:58:448 pu: nimCharsetSet() - charset=

======================================================

Address: /<domain>/<hub>/<robot>/hub Request: removerobot

======================================================

In the hub GUI you can then Refresh the view to confirm the robot disappears. It should also be gone from the IM Navigation window in IM on the left-side.

If for some reason the above process doesn't stop the robot inactive alarms from showing up, despite the robot being decommissioned, and the robot has already been removed from the hub, and the callback executed, also make sure the niscache and robot.sds file has been deleted from the robot.

1. For the given hub that the robot(s) reports to, navigate via rdp to that hub and in the hub dir., delete the robot.sds file.

2. Then in the IM, open the hub probe GUI, then choose the Robots Tab and delete those robots via Rt-Click ->Remove.

3. Then acknowledge any related robot inactive alarms in the alarm subconsole in IM.

4. Then restart the hub-robot service via services.msc.

Additional Information

Here are some notes on robot 'behavior' depending on their 'state':

There are 2 aspects to the UIM inventory.  What you see in Operator Console/UMP and what you see in IM/Admin Console (AC).

Remove the robot.sds, and any robot that 'checks in' will be managed again by those hubs.  Note that any robots that are 'down' but might come up later, will be managed once again.

Robots that are 'up' will check back in with the hub. Robots that are legitimately down AND being worked on will show back up when they are brought back online.


If the hub/robot reappears within a few minutes or so, you can also try deleting the niscache again, e.g., on the Primary Hub using the niscache clean probe utility callback.


If the hub or robot persists (comes back into the IM window), check for the following as well:

1. hub Name services (not just the Primary)

2. Any leftover queues that involve that hub

3. hubs.sds file is caching the old data

Related KB Articles:

How to delete robots in UIM when a VM with a robot has been powered off/decommissioned