I have a windows service that is making a call out to an IIS hosted WCF on the same server. This worked fine up until our virtual server crashed and had to be rebuilt. Ever since then I have been getting a "tcp error code 10060" error when the windows service tries to call this WCF service.
The IP that it gives does not exist, it is an old IP address. The IP address is not specified anywhere in code or in a config file. I can launch the WCF service from IE from that machine and any other machine that I call it from. I am told that DNS is fine.
Is there something else that I am missing somewhere?
This turned out to be a DNS issue where we had 2 entries in DNS.
Related
I am facing issue with Rest Endpoint. When I am trying to access url with machine name instead of localhost, It is giving Access Denied error. It will give this error only over VPN connection otherwise it is working fine without VPN.
I do not have same issue with browser. Browser is able to identify url with machine name. This issue is only when I am trying to consume any endpoint running on different microservice on same machine through Java code or Postman
For Example, If I am consuming some endpoint in Java.
restTemplate.getForEntity("http://localhost:8761/actuator/beans", Object.class).getBody()
//Working fine
restTemplate.getForEntity("http://my_machine_name:8761/actuator/beans", Object.class).getBody()
//Access denied
or through Postman
http://my_machine_name:8761/actuator/beans
Error: connect EACCES 192.xxx.x.x:8761
Mainly I am using Discovery Client to identity the machine name and port so that I need not to hard code localhost in the url. I am using FeignClient for loadbalancer but looks like restTemplate is also giving same error.
I have fixed above error. If you connect your machine with VPN, it change your network. So you need to find which ip address is getting used in your machine. Try ipconfig in command prompt to find the ip address in Windows.
If you give your machine name instead of above IP address then it will not be able to find your machine as your machine name is not available in your network (because of VPN connection).
machine.ip.address=XX.66.223.XXX
eureka.client.service-url.default-zone=http://${machine.ip.address}:8761/eureka
eureka.instance.hostname=${machine.ip.address}
Provide your network ip address in your URL instead of machine name to make it work.
I have a WCF service which is working perfect inside of my Parallels Bootcamp VM
However, I cannot get this working from outside, i.e. the MAC that parallels is running on
The IP address is shown as 10.211.55.3 using IP Config
The service is running via port 17377 so I am trying to use the URL 'http :// 10.211.55.3: 17377/CalculatorService.svc'
It appears as though this is normally caused by firewall issues
However, the firewall is off on both the windows VM and my MAC
Has anyone got any other ideas about what the problem could be?
I have tried this with another WCF service and still have the same problem, the 10.... IP address errors with invalid hostname
Paul
This has now been fixed thanks
If anyone else ever gets a similar issue to this the easiest thing is to change the parallels network to host only although this does disconnect the internet
I had to do that as well as modifyibg the host file on both the vm and mac to link the machines IP address to an specific host I gave it
Actually the question is kind of duplication of the following one Unable to access a locally hosted wcf service over the internet but with only difference that the service is hosted by a windows service on Azure Virtual Machine.
I can access the service on the machine and I have added an endpoint to the service port at Azure Configuration console, but still cannot access the service over the Internet.
The error message that is not possible to set up connection.
Is my scenario technical possible on azure? if yes - what is done wrong?
The answer to my question was pretty straightforward. Although I opened my endpoint in Azure Management Console the port was blocked by the virtual machine firewall (windows firewall). After setting in- and out- tcp port rule, the problem had gone.
My setup is as following:
Domain A: Visual Studio 20120 on my local workstation, pointing to my controller via an IP address
Workgroup (non-Domain): Visual Studio 20120 test controller in Amazon's EC2 cloud
When trying to connect my Visual Studio to the controller I received the following error "Cannot connect with controller ... The server has rejected the client credentials. The logon attempt failed"
To deal with that issue, I've created, on my workstation, a new local (non-domain) user with the same name and password as the user/password combination on the cloud.
Once I did that, I started an instance of Visual Studio as that user (using "Run as") and tried again. That gave out a different error message:
"the requested name is valid but no data of the requested type was found"
Turns out that what Visual Studio is actually complaining about (in a very obscure way) is that it is able to connect to the controller by the IP address, but it is unable to connect to its via its hostname.
To resolve it, I had to connect to my controller computer and get its hostname. Then I went to my hosts file (C:\Windows\System32\drivers\etc) and added the hostname as well as the ip address.
With that done, Visual Studio successfully connected to the controller.
I had a similar issue. I've notice some weird quirks when having the test controller in the domain, and the agents outside my network in workgroup computers. The controller seems to try to connect back to the agents using their netbios name, so you need to add that hostname to your hostfile with the public IP address if it isn't in your internal DNS. The agent seems to try to connect to the controller using the FQDN (active directory domain, not internet domain) of the controller, so that needs to go in the host file of the agent. You need to have the same account name and password for the agents and controller. If your controller is on a separate computer from your test manager, you need to have the controller service account be a domain account with the same username/password as the local service account on the agents. I have a complete walkthrough of what I did to make it work at http://nerdsknowbest.blogspot.com/2013/10/how-to-setup-visual-studio-tfs-test-agents-cloud.html if it helps you, or anybody else. Also, if you have anything in the hosts file that points to 127.0.0.1, comment it out.
I'm having some trouble with a WCF Service. When I host it in IIS, it runs fine, but I figure there is a problem somewhere.
When I run my WCF Service in Visual Studio 2010, it brings up the WCF Service Host.
It names the host, then the status is 'Error'.
The error it gave is this:
System.ServiceModel.AddressAlreadyInUseException: HTTP could not register URL http://+:8732/Design_Time_Addresses/EvalServiceLibrary/Service1/. Another application has already registered this URL with HTTP.SYS. ---> System.Net.HttpListenerException: Failed to listen on prefix 'http://+:8732/Design_Time_Addresses/EvalServiceLibrary/Service1/' because it conflicts with an existing registration on the machine.
I don't know if this has affected the service deployed in IIS, since that tells me I have created a service if I browse it through IIS.
Any ideas?
It's pretty clear, the address is already in use.
Does the service in IIS run on the same port? Change it, or change your port for the development.