Error “451 4.7.0 Temporary server error. Please try again later. PRX2”

We had to rebuild one of our Exchange Server 2013 recently by performing disaster recovery steps as a result of an OS corruption. Once the server was back in production we started noticing that the server was not accepting any new emails. In the Queue viewer of the Exchange server that was sending mails to this recovered server, we noticed the error “451 4.7.0 Temporary server error. Please try again later. PRX2.”.

We had confirmed that Telnet to the problematic server on port 25 was working fine as expected. The send connector protocol logs of the sending Exchange Server was checked and it showed “Queued mail for delivery”. This indicated that the sending server was trying to send the emails to the recovered problematic server. Next, we tried to send an email using Telnet to the problematic server and received the same error as in the Queue viewer “451 4.7.0 Temporary server error. Please try again later. PRX2.”. The screenshot is shown below:

At this point, we switched to the problematic server for further troubleshooting. The Default Frontend receive connector protocol logs also showed the same PRX2 error along with a DNS error “451 4.4.0 DNS query failed“.

We had a custom receive connector which was actually responsible for receiving the emails from the Exchange server, the protocol logs showed that connection is made but reported proxy and DNS errors:

The connectivity logs also had similar DNS retry errors. The application event logs on the server reported Event ID 16025 that the DNS Servers could not be contacted from the server’s network adapter with its respective adapter guid value. It also suggeted to run the Get-NetworkConnectionInfo command for more information:

The Get-NetworkConnectionInfo command returned the results of different Network adapters on the server and its configurations. To our surprise the Adapter guid value on the server did not match the Adpater guid value shown in the above screenshot. This prompted us to check the DNS Configurations on the FrontEndTransportService and TransportService by running the commands

Get-FrontendTransportService Servername | fl *dns*
Get-TransportService Servername | fl *dns*

It was then identified that the InternalDNSAdapterGuid value was still referencing the old server’s Adapter guid instead of the correct value diplayed when executing the Get-NetworkConnectionInfo. The DNS issues were finally resolved by mapping the InternalDNSAdapterGuid value to the correct guid of the server’s network adapter. This can be done by executing the command

Set-FrontEndTransportService ServerName -InternalDNSAdapterGuid {GUID}

Set-TransportService ServerName -InternalDNSAdapterGuid {GUID}

You can also assign the value of InternalDNSAdapterGuid to “00000000-0000-0000-0000-000000000000” so that internal DNS lookups are performed by using the DNS settings of any available network adapter.

More info on InternalDNSAdapterGuid parameter:

-InternalDNSAdapterGuid

The InternalDNSAdapterGuid parameter specifies the network adapter that has the DNS settings used for DNS lookups of servers that exist inside the Exchange organization. The concept of an internal network adapter and an external network adapter is only applicable in a multi-homed Exchange server environment. When no particular network adapter is specified as the network adapter for external DNS lookups, the value of the InternalDNSAdapterGuid parameter is 00000000-0000-0000-0000-000000000000, and internal DNS lookups are performed by using the DNS settings of any available network adapter. You may enter the GUID of a specific network adapter to use for internal DNS lookups. The default value of the InternalDNSAdapterGuid parameter is 00000000-0000-0000-0000-000000000000.

Reference:

Exchange – Event ID 205 and Event ID 16025