Similar things happened to us when we began with our setup, somewhat similar to yours. Our setup involves the following...1 computer holding SVN repos, running the telerik scheduling server, and running the telerik storage server. Another computer used for our teamcity build agent and telerik execution server. And then whatever other computer is being used to develop tests on. It looks like you have covered the basic suggestions I began with. Nothing jumps out to me in particular but I can do my best to give you some advice.
First things first: restart the telerik storage service and telerik scheduling service from the scheduling servers task manager or services menu (gotten to from the services button in task manager). Give running remotely a shot again.
1) We started out by getting our configuration running with the scheduling server & execution server on the same computer (I think that is what you were getting at in bullet point 2). Without any teamcity building involved, simply running test lists remotely from the development machine. Also, I did this with a completely new project that just did something really simple (like clicking on something) with the application we test against.
To address: Consider cleaning Job storage!
2) Have you ever dropped your old database? This seems to help remote execution issues significantly for us but beware, you will lose all your existing results in the database you drop. There is probobly a way to back it up but never looked into it. This can be done through the use a program by the name of Robomongo, a GUI interface to mongo databases (test studio storage, unless your using your own database or SQL this does not apply). Once you download it on the machine with scheduling & storage you can use the following settings to connect to the Test Studio storage database if everything you used to set up were the defaults. Connection Name: Test Studio Storage Database. Address: localhost:27017. Once in there, if set up correctly you should see your Test Studio Storage Database on the left hand side of the screen. To drop your database, right click TSStorageData and select Drop Database. The database will be recreated when you run a test list remotely again. I hope this one fixes your issue right here! It has been useful on numerous occasions, especially if you are running remotely and you get an error saying a test or test class type can't be found.
3) After re-installing everything, did you delete the C:\mongoDB file (or something similar to that) that the storage part of the installation left behind? This is something I did, whether it helped or not I am not exactly sure. I'm a bit superstitious when it comes to this kind of stuff.
4) This was suggested to me but didn't apply: if you have anti-virus turn it off.
5) I re-call that one specific issue that took me a bit to figure out. The machine I was installing my scheduling & storage servers on had test studio installed on it a while ago. One of the ports test studio needed was being used by an older telerik sql service causing connection issues between my scheduling and execution server.
As far as debugging ports goes... You can figure out which applications are using which ports on your scheduling server by using a dos command to display the PIDs of the applications using the ports on the machine. Then you can use your task manager to map the PID to an application name if you want to be confident the proper ports are being used by telerik services.
Now I'm just gunna spit ball a bit.
6) If you are testing against a WPF application...all of the projects referenced DLL's must be either located in the given projects root directory or in addition referenced from there as well.
7) If you can view your scheduling servers log from your development machine then at least you know that if its a communication issue, it isn't located there.
Also there are a few logs that one can look into. Here are some places to check if you haven't already.
- Development machine Test Studio Log (C:\ProgramFiles (x86)\Telerik\Test Studio\Logs).
- Scheduling server Test Studio Log (same location).
- Execution server Test Studio Log (same location).
Let us know what you learn!