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
Related
I'm having trouble connecting to an Active Directory server from my computer and server. I get "The server is not operational" error when trying to connect. The server I'm trying to connect to is in a different country than me.
LDAP Url is in the usual format:
LDAP://ip_address:389/CN=Users,DC=domain_name,DC=local
I've added the application that connects to the AD to the firewall (even disabled the firewall briefly to test) and added the IP to my hosts file but I can't seem to get past the error.
Now usually at this point, I would conclude that the issue is on the AD server side (or their server firewall) that is blocking requests from our server, however, the person in charge of the AD server has tested the same LDAP url using the same utility I'm using from an external network in their country and is able to authenticate without issues.
Any ideas on what we can try next?
Ok, it turns out the client's ISP was blocking international traffic over port 389. They had to write a letter to request the ISP to allow international traffic over that port. It is now working after they've done that.
Didn't know ISPs block traffic, but I suppose ISPs for corporate clients might as in this case.
When I try to create a Distributor on a SQL Server 2012 database I get the following error. I have tried a lot of things over the last 6 hours and can't get anything to work. Does anyone have any ideas?
This is a general connection error.
Are you configuring a remote distributor? Is the remote distributor named "LPUAT\"?
Here is a list of things to try:
Verify you are connecting to the right server.
Try pinging the server by machine name.
Try pinging the server by ip address.
Verify the target instance SQL service is started.
If the target instance is a named instance then make sure you are specifying a named instance when configuring distribution.
Verify the target instance has TCP enabled.
Verify the browser service is running on the target service if it is a named instance.
Temporarily disable any firewalls, then try to configure distribution, to see if your being blocked by a firewall.
When there genuinely is no web server installed on a machine, and the user types in the machine's IP address or FQDN into the web browser, the user will get a genuine "can't connect to the server" message from the web browser.
However, after installing the Apache web server, the direct IP address and the FQDN (i.e. archimedes.example.com) will now show the default "It works!" page. How can I make my server act as if there is no server in these places (for the IP and the FQDN)?
Note that a 404 error does not qualify, because that makes it clear that a web server is available.
Is this even possible to do in the first place?
The goal of this is that I just want my regular websites, say genuinewebsite.com, that is genuinely supposed to be on this server to be recognized. All the other "default" addresses (the IP address and FQDN) that really have no connection to any websites should just act as if there is no web server there in the first place.
No, it is not possible, because to get the hostname the browser used for the request, the browser first has to connect successfully and send it in the request. By that time, you can't really refuse the connection; the best you can do is close it on them which will appear as a connection reset error.
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.
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. :)