Exchange 2013 451 4.7.0 Temporary server error. Please try again later. PRX5
In Exchange 2013 RTM and Exchange 2013 CU1 you may occasionally receive the following errors in your Outlook clients as seen below.
451 4.7.0 Temporary server error. Please try again later. PRX5 And in the connectivity logs you may see NS server returned ErrorRetry reported by 0.0.0.0. [Domain:Result] = server.domain.com:ErrorRetry (The DNS query for 'Undefined':'internalproxy':'00000000-0000-0000-0000-000000000000' failed with error : ErrorRetry)
This is currently a know problem with Exchange 2013 and can be resolved with the following. By default the standard frontend receive connector is bound to all addresses on the server as seen below, this is now know to occasionally cause issues with DNS lookups.
We need to change the setting here to the specific IP address that the Exchange 2013 server uses and also put a line in our hosts file. To edit the bindings in Exchange 2013 click the pencil sign above to edit and change the ip address to the Exchange servers NIC as seen below.
Once done apply all settings. Now browse to the hosts file that is located in C:>Windows>System32>Drivers>etc
Edit the host file and add entry’s for your Exchange 2013s IP and its host name, for example.
192.168.16.1 server 192.168.16.1 server.domain.local
As seen here. Then reboot your server and you will not receive the Exchange 2013 451 4.7.0 Temporary server error. Please try again later. PRX5 error.
Tags: error
Loading ...
Uwe Wieczorek
| #
Dear Allen,
Thanks, this is a very good blog entry. It helps me in my Exch2013 test Environment. Now the mail flow runs perfectly.
Best regards
Uwe
Reply
Carlos Uribe
| #
I had the same issue when i tried to install CU2. when i did a get-ServerComponentState -identity “MailboxServer”. All the server components where in an Inactive state. i sent them active one by one by doing.
set-ServerComponentState ‘MailboxServer’ –Component ‘ComponentName’ –State Active –Requester Functional
Reply
Holger
| #
Just for the record. The HOSTS entry patches the effect, but the real problem is probably elsewhere, namely:
See http://exchangeserverpro.com/exchange-2013-manually-configure-dns-lookups/
to find out how to explicitly define DNS servers for the transport services – this is necessary when you have multiple network cards, e.g. for a DAG network on a combinded CAS/MBX server cluster (you won’t want to have the DAG network in DNS, as it might cause certificate trouble with autodiscover.
You can user get-transportservice | fl name,*dns* to verify that ExternalDNSServers and InternalDNSServers are now populated, instead of relying on some networkcard settings.
But this is only half the truth, because a similar setting exists for set/get-frontendtransportservices. And *this* is not set by the ECP GUI. See
http://social.technet.microsoft.com/Forums/exchange/en-US/be568eab-45c1-4648-88df-99f4939dd845/mailflow-broken-error-451-470
Set the DNS servers for the frontend servers using above powershell command, and the effect should go away.
Reply
Will Bryant
| #
Holger, I’ve been knocking myself out trying to find out why this was happening, and thanks to your info about the front end transport dns was the fix. Not a word anywhere on MS. Thanks!!!!!!!
Reply
Albert Martinez
| #
Thank you for this article. This helped get mail flow working again in our Exchange 2013 environment.
Reply
Edward Koome
| #
This worked well.Thanks Allen White for your solutions.
Reply