SMTPSVC cannot bind to DNS.

So if you telnet from one of the servers to the exchange box you can send a message via telnet ok?  I mean not just making the initial connection but actually sending an email from telnet!

Do you get the same problem whether you use an IP or a FQDN?

Have you setup a Relay Connector called 'Allowed Relay' in your Exchange 2010 system and added the IP's of the phone system etc... into it so they can deliver into Exchange 2010 without needed to authenticate?

This would be in Exchange System Manager under Server, then Hub Transport and the 'Receive Connectors' pane.

Telnet full message->yes.
IP verse FQDN -> Same results
Relay Connector -> Different name but setup to allow all local addresses.

Are you getting that error message in event viewer on all the servers or is that error message specific to the phone system?

We've had the issue with some devices not being able to send to our Exchange system with a partial DNS name but they have worked with  the FQDN (i.e: 'exchange' wouldn't work but 'exchange.contoso.com' would and the IP has always worked ok )

How is the receive connector setup?

Ours is (tab by tab)

General
'Specify the FQDN this connector will provide in repsonse to HELO or EHLO'
- ExchangeSvr1.contoso.com
'Max message Size (KB)'
 - 75240

Network:
Use these local ip addresses to receive mail:
 - (All Available IPv4) Port 25
Receive mail from remote servers that have these IP addresses
- 172.16.11.0/24
- 172.25.2.3
- etc.. (we have a lot of addresses here)

Authentication:
Transport Layer Security (TLS) = Ticked
Externally Secured (for example with IPSEC) = Ticked

Permission Groups:
Anonymous users = Ticked
Exchange Servers = Ticked

------------------------------------

Note that on the general tab the server name is different to the name we point our systems at, we use a round robin DNS of exchange.contoso.com which has a short TTL and multiple entries in DNS, each entry points to the IP of one of our Exchange Client Access servers (ExchangeSvr1.contoso.com, ExchangeSvr2.contoso.com etc...)

Does the name on the general tab on your ReceiveConnector resolve ok?

All servers are having same problem.
Here's my receive connector (tab by tab)
General;
  Allowed Relay <- Changed from Internal Relay
  FQDN -> inki.hoodview.fcu
  Max Msg Size 10240

Network;
  (All Available IPv4) 25
Receive mail from.....
 192.168.6.0/24 (will lock down once everything's working)
Authentication;
  TLS
  Ext. Secured....
Permission Group;
  Anonymous users
  Exchange Servers

Pretty much looks like what you had.

Do you have any other receive connectors listening on port 25 that are set to allow anonymous users?

Are you using the IIS SMTPSVC on the servers to relay mail to Exchange or some other application?

->Do you have any other receive connectors listening on port 25 that are set to allow anonymous users?  -> Yes "Default INKI"

->Are you using IIS on the servers to relay mail to Exchange or some other application? -> Both but primarily IIS

Try disabling the 'Default INKI' receiver temporarily.

These are my settings for our remote IIS SMTP relays.

Got to go for a bit, I'll try to get back on later to have a look at any responses.
CaptureSMTP.PNG

Disabled Default connector.

My IIS properties for the test server is definitely different. I've never had to configure anything on these servers before.

Restarted IIS admin and SMTP on test server still not sending. Will test on other server as well. Same results.

Will try configuring IIS as your picture shows.

Created new domain under IIS "*.domain.org"

Still no joy.

Made minor modification for the Allowed Relay connector to allow for my devices (printers) etc. at my outlying locations to email the server as when I disabled the default it stopped these devices. So that confirms that devices that communicate directly with the email server are working.

I'll post some more screenshots of how my IIS SMTP service is setup at one of my remote sites in the morning when I am back in work.

It sounds like you are doing the same as we are, remote devices talk to an SMTP instance that is also at that remote site and it then relays to the central site where the exchange servers are?

Below are a couple more screenshots, my IIS SMTP instance is setup with mostly the defaults apart from message size.

If you right click on the SMTP Virtual Server #1 and go into properties and then the Access tab make sure that Authentication is set to anonymous, Connection Control is set 'All except the list below' and the actual list is empty and under Relay Restrictions it is also set to 'All except the list below' and that list is also empty.

There is a screenshot of the 'Advanced' settings under the 'Delivery' tab, replace contoso.com with your domain details.

The most inportant bit is that you have your domain listed under the domains listing and it is set to forward any emails for your domain to your central exchange server, either by FQDN or IP.

"It sounds like you are doing the same as we are, remote devices talk to an SMTP instance that is also at that remote site and it then relays to the central site where the exchange servers are? " Not quite. Devices are primarily network printers and they talk to the exchange box directly.

I'll setup an IIS system and test.

Tried what you showed without success. This has got me stumped. I've also checked and rechecked my DNS settings. This problem appears to have started about the same time as I decommissioned my last 2k3 DC and raised the domain level to 2k8.

So you setup an IIS SMTP service from scratch at your central location so that any email delivered to it is forwarded on to the Exchange server.

And that doesn't work?

Can you try sending an email to your Exchange server using a testing tool for SMTP such as: http://sourceforge.net/projects/smtp-test/

I can send email using telnet without a problem. That smtp-test tool appears to be Linux based and I don't have any Linux boxes.
Used a different SMTP Test tool and got the following results.
From my workstation;

Connecting to mail server.
Connected.
220 inki.hoodview.fcu Microsoft ESMTP MAIL Service ready at Wed, 26 Jun 2013 10:31:36 -0500
EHLO WIT2
250-inki.hoodview.fcu Hello [192.168.6.62]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW
RSET
250 2.0.0 Resetting
MAIL FROM: <rwolf@texaspartnersfcu.org>
250 2.1.0 Sender OK
RCPT TO: <rwolf@texaspartnersfcu.org>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
.
250 2.6.0 <31888d1dc560569501bb602eb9663653@texaspartnersfcu.org> [InternalId=129150] Queued mail for delivery
Forcing disconnection from SMTP server.
QUIT
221 2.0.0 Service closing transmission channel
Disconnected.

Message Sent Successfully

From the test server;

Connecting to mail server.
Connected.
220 inki.hoodview.fcu Microsoft ESMTP MAIL Service ready at Wed, 26 Jun 2013 10:34:47 -0500
EHLO TPWSUS
250-inki.hoodview.fcu Hello [192.168.6.18]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW
RSET
250 2.0.0 Resetting
MAIL FROM: <rwolf@texaspartnersfcu.org>
250 2.1.0 Sender OK
RCPT TO: <rwolf@texaspartnersfcu.org>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
.
250 2.6.0 <b90f5a5cc578bbd5565d3c14e5641b07@texaspartnersfcu.org> [InternalId=129172] Queued mail for delivery
Forcing disconnection from SMTP server.
QUIT
221 2.0.0 Service closing transmission channel
Disconnected.

Message Sent Successfully

What I don't know is if this program is doing all of the smtp functions from within the program or if it's using IIS.

You'll know by running it on a machine with no SMTPSVC installed.  I would expect it to be fully self contained with its own SMTP engine.

It doesn't look like an issue with the exchange server not accepting emails from those particular servers if the SMTP tester works ok, this leads me to think it is an issue with the SMTPSVC configuration.

I'm going to be out of the office for the rest of the day (Installing new networking cable in one of our remote offices). Since I've raised the domain level I'm trying to setup SMTP mail under IIS7 - just to see - if that works. I'll let you know tomorrow.

OK, back in the office for a bit. Tried setting up in IIS7. Results the same (didn't really expect any different).

Interesting development. Under IIS6, I stopped SMTP service and under authentication I added Integrated Windows Authentication. Place email messages in the pickup folder and started SMTP service. Messages were moved to the queue folder as expected and they didn't go out. But I didn't get an error in the system log. Only information message was for a TLS certificate which I don't use.

It probably didn't get to the stage of trying to send the emails and so didn't generate the same error, if you did have a TLS certificate on the server it would get past the initialisation stage and be able to generate the DNS errors.

Have you check this KB article? http://support.microsoft.com/kb/884421

When you decommissioned your old DC did all the DNS get changed so that nothing is trying to reference the old servers, we had to strip quite a few old items manually out of our DNS to stop various strange errors occuring.

Will take a look at the article shortly.

When we decommissioned the old DCs and put in the new we used the same name and IP so as to minimize what had to be updated on the clients etc.

TLS error, I've always seen this error and the follow on message is that it disables TLS.
---------------------
OK, I removed the external DNS settings from the exchange box that I had originally set when I first started this diagnostic session. I've since restarted the IIS admin and the SMTP service. And since I enabled integrated windows authentication and also removed it about 15 minutes later I get a "new" error message;

 " Message delivery to the host '192.168.6.42' failed while delivering to the remote domain 'domain.org' for the following reason: The connection was dropped by the remote host." with an event ID of 4006.

Does it actually say 'domain.org' or have you replaced your domain name with 'domain.org' for display purposes?

display. Not that it really matters but the actual message was "Message delivery to the host '192.168.6.42' failed while delivering to the remote domain 'texaspartnersfcu.org' for the following reason: The connection was dropped by the remote host."

That's ok, just wanted to check you hadn't set something incorrectly ;)

So to clarify this is on a Windows 2003 server using the built in SMTP service that you manage via IIS6, the server is at a remote site talking over what sort of link?  And the central server is Exchange 2010.

The same issue occurs on local and remote Windows 2003/2008 servers but when you test this using a dedicated SMTP testing tool or event telnet the emails are accepted and relayed without problem?

Have you also retried the SMTP testing tool on the remote server you are testing on since you made other changes?

"So to clarify this is on a Windows 2003 server using the built in SMTP service that you manage via IIS6, the server is at a remote site talking over what sort of link?  And the central server is Exchange 2010."
    All servers to date are local on same subnet.

"Have you also retried the SMTP testing tool on the remote server you are testing on since you made other changes? "
  Yes, just did, results below.


Connecting to mail server.
Connected.
220 inki.hoodview.fcu Microsoft ESMTP MAIL Service ready at Thu, 27 Jun 2013 10:21:25 -0500
EHLO TPWSUS
250-inki.hoodview.fcu Hello [192.168.6.18]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW
RSET
250 2.0.0 Resetting
MAIL FROM: <tpwsus@texaspartnersfcu.org>
250 2.1.0 Sender OK
RCPT TO: <rwolf@texaspartnersfcu.org>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
.
250 2.6.0 <54aa0789edc62f9e521a469ecfd420c3@texaspartnersfcu.org> [InternalId=132380] Queued mail for delivery
Forcing disconnection from SMTP server.
QUIT
221 2.0.0 Service closing transmission channel
Disconnected.

Message Sent Successfully

Can you put up screenshots of your SMTP setup in IIS6 or 7, maybe that might help me, I'm still thinking it's something hinky with DNS that the IIS SMTP service is doing that the testing tool isn't.  I can't see a reason why the central Exchange server would allow an SMTP connection from one tool on the same server but not the other so therefore it has to be something in that tool that is not right.

OK, I've attached the file.
Doc1.docx

Recreate the domain, change it from '*.texaspartnersfcu.org' to just 'texaspartnersfcu.org'.

I don't use the *. in my domains.  Also make sure the domain is set to use HELO instead of EHLO, it should help with compatibility.

Done. Recreated domain, set for Helo, Stopped IIS admin and SMTP, Moved test message into Pickup folder, Started IIS Admin and SMTP. Message moved from pickup to queue and stayed there.

Test message consists of;
from:shoreware@texaspartnersfcu.org
To:rwolf@texaspartnersfcu.org
Subject: Test
This is a test.

Same errors in event viewer?

Now we're back to the original error message "unable to bind to dns".

Yes, I had read that article before. That's where today I removed all reference to my external DNS. I'm using just internal. Didn't restart the exchange box and not sure if I need to.

Update, I'm hesitantly optimistic that my problem is solved. On the original server that was giving me problems I added the remote domain and added some emails that were pending and they worked. I was able to send about 200 with only about 14 not being delivered. I'm going to let it go for a day or two to see what happens. I still don't know "why" the other server won't send the emails but.....

if you don't mind I'm going to keep this question open for a day or two and will keep you apprised of what happens.

Thank you for your excellent help. I will return.

My problem seemed to resolve itself but still want to award you the points as you directed me in the right direction. Thank you very much