4.7.0 Temporary Server Error. Please Try Again Later. Prx2

We had to rebuild 1 of our Commutation Server 2013 recently past performing disaster recovery steps as a result of an Os corruption. Once the server was dorsum in production we started noticing that the server was not accepting any new emails. In the Queue viewer of the Substitution server that was sending mails to this recovered server, we noticed the error "451 4.vii.0 Temporary server fault. Please try again later. PRX2.".

We had confirmed that Telnet to the problematic server on port 25 was working fine equally expected. The ship connector protocol logs of the sending Commutation Server was checked and information technology showed "Queued post 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 mistake as in the Queue viewer "451 4.7.0 Temporary server error. Please try once again later. PRX2.". The screenshot is shown below:

At this signal, we switched to the problematic server for farther troubleshooting. The Default Frontend receive connector protocol logs also showed the aforementioned 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 connectedness is made only reported proxy and DNS errors:

The connectivity logs likewise 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'due south network adapter with its corresponding adapter guid value. It as well suggeted to run the Get-NetworkConnectionInfo command for more information:

The Become-NetworkConnectionInfo command returned the results of unlike 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 u.s. to check the DNS Configurations on the FrontEndTransportService and TransportService by running the commands

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

It was and so identified that the InternalDNSAdapterGuid value was even so referencing the onetime 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 right guid of the server's network adapter. This can exist done by executing the command

Set-FrontEndTransportService ServerName -InternalDNSAdapterGuid {GUID}

Set-TransportService ServerName -InternalDNSAdapterGuid {GUID}

Y'all tin too assign the value of InternalDNSAdapterGuid to "00000000-0000-0000-0000-000000000000" so that internal DNS lookups are performed past using the DNS settings of whatsoever 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 Commutation 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 item 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. Yous 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:

https://www.petenetlive.com/KB/Commodity/0001251

lorenzsamelle.blogspot.com

Source: https://anishjohnes.wordpress.com/2021/11/03/error-451-4-7-0-temporary-server-error-please-try-again-later-prx2/

Share this post