deepslalli
asked on
451 4.4.0 DNS query failed. SMTPSEND.DNS.NonExistendDomain
We have a problem with our transport server sending e-mail to other exchange servers in different sites within our forest.
The transport server which is trying to send the emails is a HUB/CAS exchange 2010 server
When trying to send e-mails to users in other sites the exchange server attempts to route the emails as expected vias the SMTP Relay to Remote Acrive directory site (Inter Organisational) however we continue to receive the error in the screen shot (451 4.4.0 DNS query failed. SMTPSEND.DNS.NonExistendDo main)
All the server names are in the DNS server correctly and can all be pinged and reached from the transport server without any problems.
Lastly if we ignore these errors eventually after a period of an hour or so the mails do get delivered, however as you can imagine this is not ideal.
Exchage-2010-DNS-Error.jpg
The transport server which is trying to send the emails is a HUB/CAS exchange 2010 server
When trying to send e-mails to users in other sites the exchange server attempts to route the emails as expected vias the SMTP Relay to Remote Acrive directory site (Inter Organisational) however we continue to receive the error in the screen shot (451 4.4.0 DNS query failed. SMTPSEND.DNS.NonExistendDo
All the server names are in the DNS server correctly and can all be pinged and reached from the transport server without any problems.
Lastly if we ignore these errors eventually after a period of an hour or so the mails do get delivered, however as you can imagine this is not ideal.
Exchage-2010-DNS-Error.jpg
And just to note when making changes to the send/receive connectors be sure to restart the hub transportation service. I think previous versions of Exchange will tell you when you needed to restart for change - but can tell you Exchange 2010 doesn't give this warning when you modify the connectors.
ASKER
Hiya,
We went into the properties in the network adaptor and disabled IPv6, restarted the transport service and the queue's are still the same....same error(s) as before.
Cheers,
Shaun
We went into the properties in the network adaptor and disabled IPv6, restarted the transport service and the queue's are still the same....same error(s) as before.
Cheers,
Shaun
First - disabling IPv6 is a very poor solution.
All Microsoft products are now designed with IPv6 being enabled. Disabling it is a waste of time. Furthermore, deselecting it in the Network Control panel doesn't actually disable it.
I would reset it back to how it was and restart the transport service.
Was this working? If so, what has changed? Exchange is very sensitive to AD. Changes there can be problematic. Have you confirmed connectivity between Exchange servers using telnet? DNS resolution?
Simon.
All Microsoft products are now designed with IPv6 being enabled. Disabling it is a waste of time. Furthermore, deselecting it in the Network Control panel doesn't actually disable it.
I would reset it back to how it was and restart the transport service.
Was this working? If so, what has changed? Exchange is very sensitive to AD. Changes there can be problematic. Have you confirmed connectivity between Exchange servers using telnet? DNS resolution?
Simon.
ASKER
Hi Simon,
I have re-enabled the IPv6 in the network adapter and restarted the Transport service.
I confirmed that I can telnet from the server to all other Exchange servers in all other sites without any issue using both the IP and the FQDN.
It was working initially.. and I can think of two things that would of affected our Exchanges AD environment.
1. We lost an Exchange Server in another site and had to recover it from AD.
2. We built an Exchange server in the same site as the this one and then moved it to another site.
Thank you.
Shaun
I have re-enabled the IPv6 in the network adapter and restarted the Transport service.
I confirmed that I can telnet from the server to all other Exchange servers in all other sites without any issue using both the IP and the FQDN.
It was working initially.. and I can think of two things that would of affected our Exchanges AD environment.
1. We lost an Exchange Server in another site and had to recover it from AD.
2. We built an Exchange server in the same site as the this one and then moved it to another site.
Thank you.
Shaun
Moving servers between sites shouldn't be a problem. I do that all the time.
The recovery server though - how exactly did you recover that server?
Has Transport been restarted on all other Exchange servers?
Simon.
The recovery server though - how exactly did you recover that server?
Has Transport been restarted on all other Exchange servers?
Simon.
ASKER
The recovery was done using Microsoft Exchange recovery option:
Setup /m:RecoverServer
http://technet.microsoft.com/en-us/library/dd876880.aspx
The Transport service has been restarted on all other Exchange servers in the past (not today).
Kind regards,
Shaun
Setup /m:RecoverServer
http://technet.microsoft.com/en-us/library/dd876880.aspx
The Transport service has been restarted on all other Exchange servers in the past (not today).
Kind regards,
Shaun
ASKER
Hi,
I have more information about this issue for you. On finding this page:
http://www.the-little-things.net/blog/2012/02/29/exchange-2010-changing-an-invalid-dns-suffixed-server/
All the Exchange Servers in other sites are in their own Sub-Domains:
domain.com - This server above with above issue.
uk.domain.com - Sub-Domain
in.domain.com - Sub-Domain
de.domain.com - Sub-Domain
I came to the conclusion that it is further to do with DNS and perhaps the way the servers are showing in ADSIEdit. Now I know enough not to touch anything in ADSIEdit without being sure I know what I'm doing. It seemed that even though most of the things the Author of the above post seemed to check out (I couldn't find where the virtual directory protocol objects were hiding) like "ncacn_ip_tcp" having the correct FQDN, I made the assumption that "Something" was not providing the full FQDN to exchange and telling it to use just the NETBIOS name. Using NSLOOKUP I did some testing and found that the servers were not available via the NETBIOS name (kinda expected really bearing in mind they are in different domains) but were fully available via the FQDN. I then changed the problematic servers network adapter TCP/IP --> Advanced TCP/IP Settings --> DNS tab to also append the sub-domains DNS suffixes when doing a DNS lookup for unqualified names,
I am running tests right now but it has been working okay for the past hour. If this is the issue then I would prefer to fix it properly and understand why than just leave it as is. Any ideas?
I have more information about this issue for you. On finding this page:
http://www.the-little-things.net/blog/2012/02/29/exchange-2010-changing-an-invalid-dns-suffixed-server/
All the Exchange Servers in other sites are in their own Sub-Domains:
domain.com - This server above with above issue.
uk.domain.com - Sub-Domain
in.domain.com - Sub-Domain
de.domain.com - Sub-Domain
I came to the conclusion that it is further to do with DNS and perhaps the way the servers are showing in ADSIEdit. Now I know enough not to touch anything in ADSIEdit without being sure I know what I'm doing. It seemed that even though most of the things the Author of the above post seemed to check out (I couldn't find where the virtual directory protocol objects were hiding) like "ncacn_ip_tcp" having the correct FQDN, I made the assumption that "Something" was not providing the full FQDN to exchange and telling it to use just the NETBIOS name. Using NSLOOKUP I did some testing and found that the servers were not available via the NETBIOS name (kinda expected really bearing in mind they are in different domains) but were fully available via the FQDN. I then changed the problematic servers network adapter TCP/IP --> Advanced TCP/IP Settings --> DNS tab to also append the sub-domains DNS suffixes when doing a DNS lookup for unqualified names,
I am running tests right now but it has been working okay for the past hour. If this is the issue then I would prefer to fix it properly and understand why than just leave it as is. Any ideas?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
On my Exchange servers I disable IPv6 from the Exchange servers.
does this issue happen from the remote sites to this hub?