I recently added a couple of new servers to a new environment which live on Azure VMs. The tenacle installed without any problems, the port in the firewall is open (I get the wsdl response if I contact the service on the port that is configured) but my Octopus Server still cannot do a health check.
I have other Azure VMs doing just fine, only difference is that I use port forwarding in the Azure Endpoints since they are living in a single cloud service. There are no errors in the remote servers and on the octopus server the error in the event log is the same as in the task log. Any ideas?
Thanks
Timo
Hi Tim,
Can you open a web browser on the Octopus server, and navigate to the WSDL
page on the Tentacle?
Regards,
Paul Stovell
Octopus Deploy
W: octopusdeploy.com | T: @octopusdeploy http://twitter.com/octopusdeploy
I can. I started IE with runas (the user that runs octopus server) and if I then go to http://+++++++.cloudapp.net:23779/?wsdl I can actually see the service.
In the log it only says:
2013-05-21 09:22:46 ERROR System.ServiceModel.EndpointNotFoundException: Unable to communicate with the remote tentacle ‘http://++++++.cloudapp.net:23779/’ . This happens when either the tentacle is offline, or when firewalls are preventing communication to the service. Please verify that TCP port 23779 is open on both the Windows Firewall and any other hardware/software firewalls between the machines, and that the Tentacle Windows Service is running on the remote machine. You can test the connection by browsing to ‘http://++++++.cloudapp.net:23779/’ in a web browser from the Octopus server. The error message given was: There was no endpoint listening at http://+++++++.cloudapp.net:23779/ that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
at Octopus.Server.Proxies.ClientBroker1.CallOneWay(MachineEndpoint endpoint, Action1 callback) in c:\w\e6923628be6eaf72\source\Octopus.Server\Proxies\ClientBroker.cs:line 118
at Octopus.Server.Proxies.ClientBroker1.Call[TResult](MachineEndpoint endpoint, Func2 callback) in c:\w\e6923628be6eaf72\source\Octopus.Server\Proxies\ClientBroker.cs:line 30
at Octopus.Server.Tasks.Health.CheckTentacleHealthActivity.<>c__DisplayClass2.b__0() in c:\w\e6923628be6eaf72\source\Octopus.Server\Tasks\Health\CheckTentacleHealthActivity.cs:line 29
Hi Timo,
Your message included a link to the full server URI - I’ve edited it out. But on the WSDL page I noticed that the service still thinks it is running under port 10933.
You’re accessing the service via port 23779 but the service seems to think it is on 10933. How was this configured? Is some kind of virtual server or proxy in place?
You can modify the Tentacle service to listen on a port other than 10933 - you could try setting it to 23779 and opening the port directly. This should resolve the issue.
Paul
Hi Paul,
The thing is, in Azure I only have one public IP for a cloud service. Then I can setup so calles end points which basically provide port forwarding.
So even if the services that run listen to the default port the configuration in the Azure mgmt portal basically takes my random ports and forwards it to those correct other ports. (I think that that works since I get the response from the services alright.
:curious:
And thanks for the edit… I found even more
Hi Timo,
Can you set up the port forwarding so that the same port forwards to the same port?
E.g., currently you have:
23779 -> 10933
Instead, change Tentacle to listen on port 23779. Then set up the port forwarding:
23779 -> 23779
Or alternatively change the external port to 10933:
10933 -> 10933
The problem currently is that Tentacle is receiving a WCF command that says it is for yourserver:23779, and it is confused because it thinks it is yourserver:10933. This is a feature of WCF that we don’t have any control over.
Paul
OK, this worked.
Thanks for that quick help.