451 4.4.0 DNS query failed - when sending email from Exchange 2007 to Exchange 2013 during coexistence. Internal Mail delayed

Hi Experts

We have installed Exchange 2013 CU6 working in co-existence with Exchange 2007 SP3 RU14. Due to some issues with EAS we have only migrated a few mailboxes to 2013 so far.

We have spotted that when a 2007 mailbox user sends a 2013 mailbox user an email there is a delay in the 2013 recipient receiving the message. In 2007 queue viewer it reports:

Hub Version 15         451 4.4.0 DNS Query failed. The error was: SMTPSEND.DNS.NonExistentDomain; nonexistent domain

The messages will get through eventually but between 15-60 delay as it is retried.

I have followed this article but the ExternalDNSServers and InternalDNSAdapterGUID settings are correct as well as nslookup of the 2013 server name

http://jerridwills.com/2013/05/19/451-4-4-0-dns-query-failed/

Email flows normally between 2013 to 2007 and between 2013 homed mailboxes just not where the sender's mailbox is on 2007 and the recipient is on 2013.

During the deployment we followed the MS Exchange Deployment advisor and disabled IPV6 on the Exchange 2007 server in the registry.

Can you help smooth over the transition period?
Assist-NetopaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Simon Butler (Sembee)ConsultantCommented:
Did the deployment tool say to disable IPv6 in the registry? That is not something I have ever done.
Ensure that the FQDN on the receive connectors resolves to the server - so if you have changed the connector to something else (external FQDN for example) change it to the server's REAL name.

Simon.
0
Satyendra SharmaMicrosoft UC Technical ArchitectCommented:
Sounds like your 2007 server is struggling on DNS quering, have you tried adding a host entry on the 2007 server for 2013 and see if that makes any difference?

http://forums.msexchange.org/451_4%254%250_DNS_query_failed_-_NonExistentDomain/m_1800593506/tm.htm
0
Assist-NetopaAuthor Commented:
Simon

Yes it did, see below from the MS deployment guide

Disable IPv6 on Exchange 2007 servers

Estimated time to complete: 5 minutes

Before you install Exchange 2013, you might need to disable IPv6 on some of your Exchange 2007 servers. Some connections between Exchange 2007 and Exchange 2013 don't work correctly when IPv6 is
enabled and an Exchange 2007 server has both the Mailbox and Client Access server roles installed.
If you have Exchange 2007 servers that have both the Mailbox and Client Access server roles installed, complete the following steps on each of those servers to disable IPv6 on them.

How do I do this?
Do the following on each Exchange 2007 server in your organization that has both the Mailbox and Client Access server roles installed:
1. Open the Registry Editor on your Exchange 2007 Client Access server.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
3. If the DisabledComponents entry doesn’t exist, do the following to create it:
1. In the Edit menu, click New, and then click DWORD (32-bit) Value.
2. Type DisabledComponents and then press enter.
4. Double-click DisabledComponents.
5. In the Value data field, enter 0xFFFFFFFF.
6. Click OK.
7. Reboot the server.

How do I know this worked?
To verify that you've correctly set the DisabledComponents in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\, do the following:
1. Open a Windows command prompt.
2. Run the following command:
Reg Query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents
If the DisabledComponents entry is properly set, you'll see the following:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents REG_DWORD 0xFFFFFFFF
If you see a value other than 0xFFFFFFFF for the DisabledComponents entry, or if you receive the error ERROR: The system was unable to find the specified registry key or value., the entry isn't set
correctly. Verify that you placed the DisabledComponents entry in the correct path and that it's spelled correctly.
Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange Server, Exchange Online, or Exchange Online Protection.


Never made any change to the receive connectors on either server, will check these on Monday but I've had enough of Exchange for one week!!

Satyendra - Do you mean in the 2007's box's host file for the 2013 box so it checks there first rather than go to AD DNS? No because it didn't seem to work for the guy in the post you linked too either as I had already read that article. But thanks for the response.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Assist-NetopaAuthor Commented:
Simon

In the Exchange 2013 box the receive connectors are default as the installation put them in. The scoping settings are all the same barring the port differences. The security are the defaults.

1) Client Frontend servername
2) Client Proxy servername
3) Default servername
4) Default Frontend servername
5) Outbound Proxy Frontend servername
EX13-Receive-Connector.JPG
0
Simon Butler (Sembee)ConsultantCommented:
"The scoping settings are all the same barring the port differences"

What do you mean by that?
What port differences?

Simon.
0
Assist-NetopaAuthor Commented:
For each receive connector the settings are the same except for the port used in the network adapter bindings, for example in the screenshot the client proxy is using port 465 but default is using port 25.
0
Assist-NetopaAuthor Commented:
There was a 3rd and 4th DNS entry in the Exchange's IPv4 stack for google DNS. No sure why it was using them first but removing them seems to have cured the problem.

https://exchangemaster.wordpress.com/2014/04/15/bad-nic-settings-cause-internal-messages-to-queue-with-451-4-4-0-dns-query-failed-nonexistent-domain/
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Assist-NetopaAuthor Commented:
Found a article that resolved the problem.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Servers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.