Solved

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

Posted on 2014-11-14
8
693 Views
Last Modified: 2015-01-09
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?
0
Comment
Question by:Assist-Netopa
  • 5
  • 2
8 Comments
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 40442923
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
 
LVL 7

Expert Comment

by:Satyendra Sharma
ID: 40442951
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
 

Author Comment

by:Assist-Netopa
ID: 40442996
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
 

Author Comment

by:Assist-Netopa
ID: 40446811
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
Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 40452068
"The scoping settings are all the same barring the port differences"

What do you mean by that?
What port differences?

Simon.
0
 

Author Comment

by:Assist-Netopa
ID: 40452099
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
 

Accepted Solution

by:
Assist-Netopa earned 0 total points
ID: 40531124
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
 

Author Closing Comment

by:Assist-Netopa
ID: 40539830
Found a article that resolved the problem.
0

Featured Post

Find Ransomware Secrets With All-Source Analysis

Ransomware has become a major concern for organizations; its prevalence has grown due to past successes achieved by threat actors. While each ransomware variant is different, we’ve seen some common tactics and trends used among the authors of the malware.

Join & Write a Comment

Check out this infographic on what you need to make a good email signature that will work perfectly for your organization.
Local Continuous Replication is a cost effective and quick way of backing up Exchange server data. The following article describes the steps required to configure Local Continuous Replication. Also, the article tells you how to restore from a backup…
In this video we show how to create a User Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Mailb…
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now