Thank you for the detailed description of the setup you have built. I also appreciate your efforts to find a solution on your own using any public resources on the topic.
Basically, the configuration seems to be correct as you pointed yourself, though the Storage service still cannot be accessed. This is the reason why there is no TSStorageData
collection in the MongoDB. There are few things, which I am not completely sure of, and will be happy if you correct me in any of the below statements:
1. The two machines are in different domains (since the VM is hosted in Azure)
2. Ping from machine A to B and vice versa is successful
3. Machine B is named sel-uks-01 and its IP is 18.104.22.168.
Assuming that the above notes are correct, here are few more things to try: If Machine A - the local one, has an active firewall and/or antivirus software, please stop these (or at least the firewall) for testing purposes. Then try to run a test list on the Machine B. Does this change the behavior?
- if the run is successful in this situation and it was the firewall that prevented the communication, please open ports 8009, 8492 and 55555 on Machine A both in- and outbound. Then activate the firewall (and AV if applicable) and verify if the run is still possible.
- if the execution with disabled firewall was still unsuccessful, please, open the Scheduling setup wizard
and in the third tab (pint 4. in the mentioned article) enter the IP address of Machine B for the Storage Service Location, then apply the changes. Will a remote run start with this configuration?
In addition, please, ensure the logged users on both machines have admin rights and they will not be restricted in any action.
In case the issue is still ongoing, please generate the complete application logs for both machines during an attempt to run - the application log on the local machine
can be accessed through the Help menu and the one from Machine B can be found in the Execution Status view
. Please, first clear the logs - that way the information in the files will be only relevant to the current issue. Then try to execute a remote run to generate the encountered error. After that you can collect the generated log records and send these zipped via this communication thread.
I hope the shared information is useful and will help us to find out what prevents the successful communication with the Storage. Please, do not hesitate to get back to me in case of any further questions or doubts.