Is it necessary to stop the Nimsoft Robot Watcher service prior to installing Windows Updates with Automatic Reboot?
Article ID: 114878
Updated On:
Products
DX Unified Infrastructure Management (Nimsoft / UIM)
Issue/Introduction
Need clarification ats to whether it is absolutely necessary to stop robot first before applying OS updates.
The desire is to implement automatic updates/reboot on some Windows servers.
Is it necessary to stop the Nimsoft Robot Watcher service prior to installing Windows Updates with Automatic Reboot?
The desire is to implement automatic updates/reboot on some Windows servers.
Is it necessary to stop the Nimsoft Robot Watcher service prior to installing Windows Updates with Automatic Reboot?
Environment
UIM server: Any version
robot: Any version
robot: Any version
Resolution
There are no specific documents that address what to do with the Nimsoft Robot Watcher service when applying Operating System (OS) maintenance.
It is usually recommended that the robot service be stopped on the primary hub and ump robots if applying patches to these or the server hosting the UIM database. Once the OS patches are applied, and your database manager is once again restarted, then restart the robot on the primary hub and UMP robots. This is to assure that there is no loss of messages (QoS and alarms in particular) while patching any of these 3 systems.
For a basic robot or secondary hub, stopping the robot service first before applying OS patches and rebooting may not be as critical since you are minimizing the potential for message loss (more so at the robot level than the secondary hub).
The robots store messages that are to be transferred to the managing hub in a local q*.sds file for the spooler probe. If communication with the managing hub is lost during the Windows patching, the messages will be queued up locally until a connection with the managing hub is re-established. At that point the queue messages will be forwarded.
Secondary hubs perform the same type of function, writing messages from all of the managed hubs to an ATTACH queue for forwarding on to the primary hub (either directly or to another concentrator hub). If communication is lost between the secondary hub and the hub with the configured GET queue to receive the messages from the remote hub then the remote hub will save the messages in local .sds files. Once communication is re-established between the two hubs, the messages are sent to the upstream hub.
It is usually recommended that the robot service be stopped on the primary hub and ump robots if applying patches to these or the server hosting the UIM database. Once the OS patches are applied, and your database manager is once again restarted, then restart the robot on the primary hub and UMP robots. This is to assure that there is no loss of messages (QoS and alarms in particular) while patching any of these 3 systems.
For a basic robot or secondary hub, stopping the robot service first before applying OS patches and rebooting may not be as critical since you are minimizing the potential for message loss (more so at the robot level than the secondary hub).
The robots store messages that are to be transferred to the managing hub in a local q*.sds file for the spooler probe. If communication with the managing hub is lost during the Windows patching, the messages will be queued up locally until a connection with the managing hub is re-established. At that point the queue messages will be forwarded.
Secondary hubs perform the same type of function, writing messages from all of the managed hubs to an ATTACH queue for forwarding on to the primary hub (either directly or to another concentrator hub). If communication is lost between the secondary hub and the hub with the configured GET queue to receive the messages from the remote hub then the remote hub will save the messages in local .sds files. Once communication is re-established between the two hubs, the messages are sent to the upstream hub.
Feedback
Yes
No
Powered by
