Some time ago I had already pointed out the following error, here in connection with Exchange 2013:
If emails cannot be delivered and Exchange displays the error "451 4.7.0 Temporary server error. Please try again later. PRX2" in the queues, there may be another reason for this. This applies to both Exchange 2013 and Exchange 2016/2019.
The cause of the error is almost always problems with the DNS, and not always necessarily with the DNS server itself, as described in the article linked above, but also with the DNS settings of the Exchange server.
The following DNS configuration is often found on servers and clients, especially in very small environments:
In very small environments, for example, there is only one domain controller, which is also used as the DNS server. In this example, the DC has the IP 192.168.100.1 and is set as the preferred DNS server. As there is no other DC as a DNS server, a DNS forwarder is often entered as an alternative DNS server, in this example the router.
The reason why, for example, a router is specified here as an alternative DNS server: If the DC fails, at least I still have name resolution and can surf the Internet, for example. Of course, if the only domain controller fails, you still have a problem: without DNS and Active Directory, Exchange no longer works either. You might still be able to surf the Internet, but not much more.
However, Exchange has a problem with this configuration. Exchange uses all configured DNS servers, not just the preferred DNS server. This makes sense, because it is a very simple way to achieve simple load balancing across all configured DNS servers.
In most small environments, however, the router, for example, cannot resolve the DNS zones of the Active Directory. Routers and various other alternative "non-DC DNS servers" forward DNS queries to DNS servers on the Internet, but cannot do anything with DNS queries to the "Underscore Zones (e.g. _msdcs)" and return an NX domain (domain or entry does not exist).
In this example, a DNS query for "gc._msdcs.frankysweb.local" against the preferred DNS server (domain controller) would be successful and return the IP address of the domain controller. However, the same DNS query to the router would be answered with "non-existent domain (NX domain)":
This is also the reason for the error "451 4.7.0 Temporary server error. Please try again later. PRX2", Exchange can no longer find its domain controller or cannot resolve relevant DNS entries.
Solution:
In such small environments, the alternative DNS server for Exchange Server can be dispensed with. If the domain controller fails, you have a problem anyway and nobody will use the Exchange server for surfing anyway.
With some routers, it is possible to configure DNS forwarding. For example, you can configure that all queries to _msdcs.frankysweb.local are forwarded to the domain controller. Of course, this only helps to a limited extent with only one domain controller (limited in the sense of "not at all")...
This problem can also occur in environments with two or more domain controllers, as all configured DNS servers must be able to resolve the "Underscore Zones".
I have "inherited" a few Exchange servers to look after.
While searching for information, I have come across your website quite often, the toolbox has just helped me to fix an error that crept in after rebuilding an Exchange VM.
Thank you very much.
Many thanks (!!!) for the information, it helped me to get an Exchange that suddenly stopped working back on its feet.
Eliminated outdated DNS entry and set the Exchange with the only correct DNS.
Very well described :-)
There was no better way to explain it. After a total network failure with recovery and reconfiguration, exactly the same error crept in today. No more mails in, no more mails out, despite running services.
Saved my evening. As mentioned above, frankysweb.de has often helped with Exchange errors.
Thanks for the great article, fixed the problem immediately.
Hello Frank,
One more tip: never use the dyndns updater client on Exchange. It places two Oracle DNS servers at the beginning of the DNS resolution without being asked. It just cost me 2 hours of troubleshooting on an Exchange 2013...
These instructions saved me. However, the problem occurred in combination with Popcon.
https://anishjohnes.wordpress.com/2021/11/03/error-451-4-7-0-temporary-server-error-please-try-again-later-prx2/
So if these instructions here from Frank (many thanks again for this) do not help you. It may well be that, as in my case, the UUID of the network card has changed or been entered incorrectly. For me it worked again with the UUID (00000000-0000-0000-0000-0000-000000000000).
I don't want to admit that I'm driving around on an Exchange 2016, but yes: the article solved my problem exactly.
I have my Win Server 2016, on which I have Exchange running, set up as ADS and DNS Manager so of course I have to set the DNS setting to itself. *slap hand to forehead*
MAGIC
Madness.
Franky your site is amazing. I've landed here so often over the years.
Thank you.
Oh man ... thank you so much for the solution. You hit the nail on the head. I am soooo happy :)
Thanks for the article.
"Exchange uses all configured DNS servers, not just the preferred DNS server"
Does Exchange itself really use the settings of the DNS setup of the IP settings for queries or does the Exchange application pass this on to the DNS resolver of the operating system, which then uses the DNS cache => host file => DNS lookup against 1st DNS server => DNS lookup against 2nd DNS server for queries?
The second DNS server in the network must of course also know the answers of the first DNS server (in the cache or resolve), otherwise Exchange cannot work. Exchange without AD is not possible!
"Exchange uses all configured DNS servers, not just the preferred DNS server." I was not aware of that. Good to know, thanks!
I can only agree with that.
Remove the router from the DNS records and all is well.
I had actually expected the name resolution process to be as Erik describes it.
Thank you for the informative and clearly understandable article.
Quite a few knowledge base articles or their authors could learn something from this... ;-)