There are a few articles online about this error, but none were correct for the scenario i found a clients network in.
Not that I think the specifics matter, but this was Exchange Server 2016, Windows Domain Controllers running 2012 R2 and Exchange Hybrid. All the mailboxes had already moved to the cloud and the Exchange Server is used for attribute management and SMTP relay.
Sometimes, randomly it would seem, the applications fail to send email and get back the above error. So what does it mean! Lets dive into the Exchange logs to find out more.
In my example, TCP 25 is listening on a number of separate IPs on two different network cards on a server hosted in Azure (maybe all that matters for this case?)
Protocol Logs (Frontend)
In the Exchange Transport logs I turned on Protocol Logging for all connectors and sent some emails and had them rejected with the PRX2 error in the title. After 5 or so minutes the protocol logs contained the erroring session as shown below:
2019-01-31T13:45:09.477Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,0,10.10.10.16:25,10.150.14.108:59877,+,, 2019-01-31T13:45:09.478Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,1,10.10.10.16:25,10.150.14.108:59877,>,220 COMPANY Relay Connector SERVER, 2019-01-31T13:45:09.479Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,2,10.10.10.16:25,10.150.14.108:59877,<,HELO, 2019-01-31T13:45:09.479Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,3,10.10.10.16:25,10.150.14.108:59877,>,250 SERVER.internal.co.uk Hello [10.150.14.108], 2019-01-31T13:45:09.480Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,4,10.10.10.16:25,10.150.14.108:59877,<,MAIL FROM: <appserver@international.com>, 2019-01-31T13:45:09.480Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,5,10.10.10.16:25,10.150.14.108:59877,*,08D68772EDC476C6;2019-01-31T13:45:09.477Z;1,receiving message 2019-01-31T13:45:09.480Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,6,10.10.10.16:25,10.150.14.108:59877,>,250 2.1.0 Sender OK, 2019-01-31T13:45:09.482Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,7,10.10.10.16:25,10.150.14.108:59877,<,RCPT TO: <internal.user@international.com>, 2019-01-31T13:45:09.482Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,8,10.10.10.16:25,10.150.14.108:59877,>,250 2.1.5 Recipient OK, 2019-01-31T13:45:09.483Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,9,10.10.10.16:25,10.150.14.108:59877,<,RCPT TO: <brian@nbconsult.co>, 2019-01-31T13:45:09.483Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,10,10.10.10.16:25,10.150.14.108:59877,>,250 2.1.5 Recipient OK, 2019-01-31T13:45:09.484Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,11,10.10.10.16:25,10.150.14.108:59877,<,DATA, 2019-01-31T13:45:09.484Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,12,10.10.10.16:25,10.150.14.108:59877,>,354 Start mail input; end with <CRLF>.<CRLF>, 2019-01-31T13:45:09.498Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,13,10.10.10.16:25,10.150.14.108:59877,*,,Proxy destination(s) obtained from OnProxyInboundMessage event. Correlation Id:80e0d560-be23-4910-bcb0-43139bee131f 2019-01-31T13:45:09.501Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,14,10.10.10.16:25,10.150.14.108:59877,*,,Message or connection acked with status Retry and response 451 4.4.0 DNS query failed. The error was: DNS query failed with error InfoNoRecords -> DnsQueryFailed: InfoNoRecords 2019-01-31T13:45:09.501Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,15,10.10.10.16:25,10.150.14.108:59877,>,451 4.7.0 Temporary server error. Please try again later. PRX2 , 2019-01-31T13:45:09.503Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,16,10.10.10.16:25,10.150.14.108:59877,<,QUIT, 2019-01-31T13:45:09.503Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,17,10.10.10.16:25,10.150.14.108:59877,>,221 2.0.0 Service closing transmission channel, 2019-01-31T13:45:09.503Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,18,10.10.10.16:25,10.150.14.108:59877,-,,Local
The protocol logs contain a number of columns to the left. The interesting ones for this are the connector name (“SERVERFrom Internal Servers (Relay)”), the session ID (08D68772EDC476C6) and the sequence number (each item on the protocol has a incrementing sequence number, in the above it goes from 0 where the session connects (which is the + at the end) to 18, where it disconnects (the – at the end of the last line).
This log looks no different from a session that works (as it was random as I said above), but we see more about the error. Specifically we see the following:
Proxy destination(s) obtained from OnProxyInboundMessage event. Correlation Id:80e0d560-be23-4910-bcb0-43139bee131f Message or connection acked with status Retry and response 451 4.4.0 DNS query failed. The error was: DNS query failed with error InfoNoRecords -> DnsQueryFailed: InfoNoRecords 451 4.7.0 Temporary server error. Please try again later. PRX2 ,
So we see that it is DNS. Online there are articles about this being to do with IPv6, AAAA records and invalid responses to those queries and fixes include using external DNS settings or smarthost values. None of this worked in this example.
So lets follow down the logs some more
Connectivity Logs
In the connectivity logs we search the same date/time/hour log for the session number, which in this case is 08D68772EDC476C6 from the above logs. In the connectivity logs we see a session that matches for this ID and its for “internalproxy”
2019-01-31T13:45:09.499Z,08D68772EDC476C7,SMTP,internalproxy,+,Undefined 00000000-0000-0000-0000-000000000000;QueueLength=<no priority counts>. Starting outbound connection for inbound session 08D68772EDC476C6 2019-01-31T13:45:09.501Z,08D68772EDC476C7,SMTP,internalproxy,>,DNS server returned InfoNoRecords reported by 10.10.10.21. [Domain:Result] = SERVER.internal.co.uk:InfoNoRecords; 2019-01-31T13:45:09.501Z,08D68772EDC476C7,SMTP,internalproxy,-,Messages: 0 Bytes: 0 (The DNS query for  'Undefined':'internalproxy':'00000000-0000-0000-0000-000000000000' failed with error : InfoNoRecords)
Internalproxy is what Exchange users to send email from the frontend transport service to the hub transport service. But which hub transport service are we going to use? If does not matter if you have 1 or x number of Exchange Servers in your site, it will use DNS to look up the IP of one of these servers. So even if you have a single Exchange box, DNS is vital.
In the above log we see that DNS 10.10.10.21 returns InfoNoRecords when queried for the Exchange Servers own name.
So I resort to nslookup to check DNS from this Exchange server. I have two DNS server, .20 and .21. The error appears to be related to .21 in this case.
To I enter “nslookup server.internal.co.uk 10.10.10.21” which means look up the name of the server using the DNS server 10.10.10.21. I got back a message saying cannot find server.internal.co.uk: Query refused.
When I tried the other DNS server I got back a successful response and the IP address of the server.
So for immediate fix, I removed 10.10.10.21 as an option for DNS for this server. Exchange immediately went back to work and PRX2 errors where not displayed and email got to its destination.
Now to go and see who has broken DNS!
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:
There is a reason why I have been stuck with Exchange 2010 for a while. Ever since Exchange 2013 was releases, the same error has always been around for me, no matter where I installed it.
Now I thought it was time to give the latest Exchange 2016 a try. I thought that Microsoft must have had time to patch the annoying error, but I could be no more wrong. How is it even possible that the same problem persist?!
Okey, so the error I’m talking about is this annoying SMTP error preventing you from actually receive any mail. The sending SMTP server is receiving a “451 4.7.0 Temporary server error. Please try again later.”. In the Event Viewer on the Exchange server, one can read something like “No DNS servers could be retrieved from network adapter…”.
The problem is that the Exchange server is unable to do any DNS queries because it doesn’t know any DNS servers. Even though it’s supposed to find your DNS servers by itself… I have googled around a bit and after a few trial and error I found what I think is the solution.
1. Log on to your ECP (https://mail.domain.com/ecp) with a Domain Admin credential and go to Servers, mark your server and edit it.
2. Go to DNS lookups and change both External DNS lookups and Internal DNS lookups to Custom settings. Now, enter your DNS servers in both fields and hit Save.
Now this is the funny part – the ECP only changes the Backend(?) Transport Service, not the Frontend Transport Service. To do this, we need PowerShell.
3. Logon to your Exchange server via RDP and fire up the Exchange Management Shell (pick “Run as Administrator” just in case).
First of all, we need to find out your network adapter’s GUID. I’m not sure if this step is actually needed, but let’s play safe here.
4. Run the following command: Get-NetworkConnectionInfo
You will get an output similar to this:
RunspaceId : xxxx
Name : Intel(R) 82574L Gigabit Network Connection
DnsServers : {10.1.1.7}
IPAddresses : {10.1.1.9, aaaa::bbbb:cccc:dddd:eeee}
AdapterGuid : xxxx
MacAddress : 00:00:00:00:00:00
Identity : xxxx
IsValid : True
ObjectState : Unchanged
5. Copy the AdapterGuid and type in the following commands (replace SERVER with your Exchange server and xxxx with your adapter’s GUID):
Set-FrontendTransportService -Identity SERVER -InternalDNSAdapterGuid xxxx
Set-FrontendTransportService -Identity SERVER -ExternalDNSAdapterGuid xxxx
7. Verify that your adapter’s GUID and DNS servers is set correctly by typing in the following command:
Get-FrontEndTransportService | Format-List *DNS*
You will get an output similar to this:
ExternalDNSAdapterEnabled : True
ExternalDNSAdapterGuid : xxxx
ExternalDNSProtocolOption : Any
ExternalDNSServers : {10.1.1.7}
InternalDNSAdapterEnabled : True
InternalDNSAdapterGuid : xxxx
InternalDNSProtocolOption : Any
InternalDNSServers : {10.1.1.7}
DnsLogMaxAge : 7.00:00:00
DnsLogMaxDirectorySize : 100 MB (104,857,600 bytes)
DnsLogMaxFileSize : 10 MB (10,485,760 bytes)
DnsLogPath :
DnsLogEnabled : False
8. Reboot the server.
EDIT: Make sure you do not turn off IPv6! I’m not hundred percent sure it’s needed, but I have been seeing mysterious errors when IPv6 is turned of on an Exchange 2013/2016 server. Better safe than sorry – leave it on!