After a reboot of the Primary hub, the customer could not access UMP without error.
The website was not accessible and the browser displayed an HTTP 500 Internal Server error when accessing ump via either http OR https.
- Unexpected reconfiguration of the UMP machine robot as a hub
First, confirm that the UMP robot machine belongs to/sits under the Primary Hub. The UMP machine must be a robot and NOT a hub otherwise you may get unexpected errors/results.
To test the robot location and connectivity, in IM, select the ump robot and choose Tools->Connect and then Get Info to see if the robot belongs to the Primary hub.
Using Firefox and then Chrome browser, clear the browser cache of everything, then close the browser sessions and open a new one.
Then collect and assess the results of the following commands issued from the same network segment that the Primary hub sits on, TO/FROM the related hosts as described below.
- telnet FROM the UMP machine TO the Primary Hub on port 48002
- telnet FROM the Primary Hub TO the ump robot on port 48000
- telnet <ump_machine> 80
- telnet <ump_machine> 443
- hostname command issued on the local ump machine
- nslookup <https://<ump_hostname>
- nslookup <ump_machine_ip_address>
In this case, the original robot machine had been updated to a hub, most likely from a hub probe update (e.g., a drag & drop operation to update hubs).
To demote the hub back to a robot:
1. Login to the UMP machine and Deactivate the robot watcher service on the UMP machine
2. Remove the <hub> entry from the controller.cfg in the robot directory.
3. Delete the hub folder
4. Activate the UMP robot watcher service
5. Open the hub probe on the Primary hub and choose the Hubs Tab and delete the 'old' ump hub entry, otherwise the robot may appear twice in the IM navigation window, once as a hub and also as a robot off of the Primary.
6. Access UMP url / ip_address, via the browser