Our customer has 160 remote hubs on windows 2016 servers. When this servers are rebooted after Windows Patching randomly nimbus.exe (Nimsoft Robot Watcher Service) does not start. We have already auto-delayed the startup but still see this problem from time to time. For our customer this is a serious problem because he does not have direct access to this Servers and cannot easily start this service manually after reboot.
Release : 20.4
Component : UIM - ROBOT
Windows 2016
hub and robot 9.33 (secondary hubs)
- Environmental
It’s a good idea to keep track of a few incidents where a given server which is already set to delayed start, was rebooted but the robot didn't start. Save the time frame information so you can examine Windows events on that same server for crashes, hangs, failed startup of the robot/controller process, and/or failure due to the specific user configured in the Properties for the Nimsoft Robot Watcher service.
You can examine the current Nimsoft Robot Watcher Properties, and configure actions to take when the robot fails for the 1st time, and / or 2nd time.
You can test the configuration by rebooting the server ~5 times, to see what happens and check the Windows events (Application/System), then analyze the results and hopefully understand how and why the robot is failing to start.
Experiment on at least one machine where this issue is happening using the Windows Service settings for the Nimsoft Robot Watcher (Properties), for example:
There have been a few cases reported by customers for this and community posts as well, but there can be other reasons this is occurring randomly and when it does occur the customer must do some investigation to determine possible causes so they don’t have to manually workaround it anymore. It is an important step to check if these robots are running as the Local System Account or a service account. If the servers where this is happening are using a service account, check how robot watcher service is configured and make sure there is no Windows group policy (GPO) that is removing the user from the ‘logon as service rights’ that may be happening in the background after reboot.