Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1000
  • Last Modified:

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?
0
Assist-Netopa
Asked:
Assist-Netopa
  • 5
  • 2
1 Solution
 
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 SharmaSenior ConsultantCommented:
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
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 
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
 
Assist-NetopaAuthor Commented:
Found a article that resolved the problem.
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now