Service Location:
http://1.1.1.1:5670/Test_Service/Service.SearchService.svc
Error:
The document was understood, but it could not be processed.
- The WSDL document contains links that could not be resolved.
- There was an error downloading 'http://mycompany.com/Test_Service/Service.SearchService.svc?xsd=xsd2'.
- The remote name could not be resolved: 'mycompany.com'
Metadata contains a reference that cannot be resolved: 'http://1.1.1.1:5670/Test_Service/Service.SearchService.svc?wsdl'.
There was no endpoint listening at http://1.1.1.1:5670/Test_Service/Service.SearchService.svc?wsdl that could accept the message.
This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The remote server returned an error: (404) Not Found.
If the service is defined in the current solution, try building the solution and adding the service reference again.
This only happens when i am not on the VPN. If i am on the VPN things work well. Also mycompany.com is only availalbe internally.
I can view the WSDL when not connected to the VPN
Your VPN probably gives you an ip address in the 1.1.1.* subnet (internal to your company's network). So, when you are connected to VPN, you can reach the server and when you are not connected, you cannot (because you are outside the company's network without VPN).
There is likely no resolution to this issue unless your company is willing to expose that server externally. Just use your VPN.
Per comment: Yes and you can see the WSDL like this http://1.1.1.1:5670/Test_Service/Service.SearchService.svc?wsdl but you will need to be VPN'd in. :)
Related
So, I'm supporting in a WCF that is having some interesting problems. In the application log file, it has appeared the following error:
There was no channel actively listening at 'http://hostanme.domain/Integration/IntegrationService.svc'. This is often caused by an incorrect address URI. Ensure that the address to which the message is sent matches an address on which a service is listening.
The case is that the application is configured to receive only requests in HTTPS, and if some external requests come with HTTP, it responds with a "404 Not Found". The point is that the error request up always comes HTTP and the hostname of the machine in the URL domain. We contemplated a lot here in the office whether it would be if the application calls this URL after the IIS recylce, but we are still on this question, and we can not repeat this error.
Has anyone had a similar situation , or know how to solve this case?
try to run this command :
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i
I have a Domino development server I can't get web-based emails to send from. The error I'm getting is "The remote server is not a known TCP/IP host". The server works fine for Notes based emails, but I'm generating emails from LotusScript in an app, and they are not sending.
This server was recently created (Dom 8.5.3).
I have the server sending email directly to the Internet on all location documents (for Notes client).
See IBM Technote #1099632 "Notes/Domino background agent fails to send mail; Errors may occur in logs":
These errors may be caused by an improper entry for the Mail Server field in the Server document in the Domino Directory (public Name and Address Book).
The errors may also be caused by a server configuration or TCPIP issue. For example, if the Network Address field for a TCPIP port contains either an incorrect host name or an IP address, the errors occur. If the DNS is not working correctly the errors will occur.
The issue was noted in at least one case because the server was resolvable by IP address but not resolvable by Fully Qualified Host Name (FQHN). The IP address was listed in the Net Address field of the Server document but this error message still appeared. To resolve this issue, update the DNS servers to point the FQHN to the correct server. In one case it was discovered that the particular Domino server was not listed in its own host table. Update the host file of the server with the FQHN pointing to its own IP or localhost address.
The Technote also provides steps to troubleshoot the issue.
Also, you can enable some debugging to determine where the problem surfaces.
For outbound SMTP-related issues, enable the debug parameters below on the server to capture data:
CONSOLE_LOG_ENABLED=1
DEBUG_THREADID=1
debug_show_timeout=1
debug_capture_timeout=1
SMTPClientDebug=1
See Collecting data for Domino SMTP mail routing issues for more details on that
I have a WCF service in Azure. I can reference its IP address and successfully hit it with a browser or with WcfTestclient.exe. I've gone into GoDaddy and mapped svc.mydomain.com to my IP/port and now I can't hit with a browser, but not with WcfTestClient.exe. The error is "Error: Cannot obtain Metadata from http://svc.mydomain.com/Service1.svc?wsdl... Metadata contains a reference that cannot be resolved: 'http://svc.mydomain.com/Service1.svc?wsdl'. The remote server returned an unexpected response: (408) Request. The remote server returned an error: (408) Request Timeout.HTTP GET Error URI: http://svc.mydomain.com/Service1.svc?wsdl The HTML document does not contain Web service discovery information."
When I hit it with the browser it comes back with the stock html showing that it found the service, but it refers to it by its IP, so I wonder if it's a config file change that I need to make.
Is it best practice to nickname my service with a CNAME (i.e. svc.mydomain.com) and thus reference my services with like: http://svc.mydomain.com/MyService.svc?
You shouldn't rely on the IP address for a Windows Azure service. The IP addresses can and almost certainly will change (for instance, if you deploy from within Visual Studio, it tends to result in a different IP address being allocated).
You service already has a DNS name: deployment name.cloudapp.net
The Windows Azure Management Portal will show you the DNS name.
If you want to address the service using a different DNS name, use a CNAME to create a DNS alias.
I built a WCF service that exposes itself for a web application, it accepts an object and prints the data on the clients machine. Works fine on my development machine, and the service is up and running on any machine i install it on. I can enter ip address in clients machine web browser and see it is running. Problem is when i send the object to the clients machine it returns an error, that sounds like it could be because of the clients windows firewall. Where would i start at to deal with this problem ?
There was no endpoint listening at http://192.168.1.168:2202/PrintLabel that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
And the InnerException: Unable to connect to the remote server
With further research and discussion with people in the community i came to understand that as was mentioned at the bottom of this article.
"Self-hosted HTTP addressing for WCF is not integrated into the Windows firewall. An exception must be added to the firewall configuration to allow inbound connections using a particular URL.
But this SO question led me to a page with how to control Windows Firewall through code to enable my WCF self hosted service to accept an object.
This the link below.
http://www.shafqatahmed.com/2008/01/controlling-win.html
That link was towards the direction i needed, but based on user comments it seemed to have some bugs. A colleague found this link and i believe this technique will be the best solution for this scenario.
I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)