451 4.7.0 Temporary server error. Please try again later. PRX2
I'm getting the dreaded "

451 4.7.0 Temporary server error. Please try again later. PRX2

" error when receiving SMTP mail.

does anyone know exactly what causes this error? there are many references to it on the web, but nobody seems to know exactly what causes it. maybe it's something to do with DNS?

can someone please ask someone on the exchange team to help document this?


  • Edited by spongman Saturday, January 12, 2013 7:40 PM
January 12th, 2013 7:39pm

ok, in lieu of any real support, and in case someone else might find this useful, i'm going to log my attempts to work out what's causing this problem.

initially, and during exchange 2013 installation, i had 2 NICs in the machine. one was connected to the (rfc1918) LAN containing the domain controller. the other was connected effectively to the internet (via another rfc1918 LAN). both NICs had their own default gateways and both NICs had DHCP-assigned DNS servers.

i have since disabled the internet-facing NIC and rebooted and now the PRX2 error has gone away and mail flow is working correctly (although, of course, i can't receive mail from the internet).

Free Windows Admin Tool Kit Click here and download it now
January 12th, 2013 8:01pm

ok, so adding back the internet NIC but with a static IP and no DNS still works.

however, adding a DNS server (4.2.2.1) to the internet NIC causes the PRX2 error.

I should add that ipv6 is disabled on the internet NIC (my ISP doesn't do ipv6).

January 12th, 2013 8:21pm

ok, screw the internet NIC, it's irrelevant.

I now have a single NIC with a single static ipv4 address (no ipv6) on the LAN with the domain controller. the 1st DNS server on that NIC is the domain controller (running AD DNS).

If I add a public DNS server (4.2.2.1) as the 2nd DNS server on the NIC then I get the PRX2 error. no public DNS, no error.

Free Windows Admin Tool Kit Click here and download it now
January 12th, 2013 8:33pm

On Sat, 12 Jan 2013 20:33:50 +0000, spongman wrote:   >ok, screw the internet NIC, it's irrelevant. > > > >I now have a single NIC with a single static ipv4 address (no ipv6) on the LAN with the domain controller. the 1st DNS server on that NIC is the domain controller (running AD DNS). > >If I add a public DNS server (4.2.2.1) as the 2nd DNS server on the NIC then I get the PRX2 error. no public DNS, no error.   Rather than have each NIC use a different gateway, why not use one gateway (on the Internet-facing NIC) and a static route for your LAN network(s)?   Create the static route like this:   netsh interface ipv4 add route 10.0.0.0/8 "Name-of-Internet-NIC" 10.1.1.1   Make sure the Internet-facing NIC is at the top of the binding order, too.   The Internet-facing NIC should be configured with DNS servers. The internal NIC should not.   --- Rich Matheisen MCSE+I, Exchange MVP  
January 13th, 2013 3:59am

Hi Rich, I'm not sure it makes any difference.

Firstly, I can repro the problem with only a single, internal NIC.

However, with multiple NICs it doesn't seem to make a difference what the gateways are set to, or what the binding order is I can still repro in either case.

I have to say I'm confused about the routing of DNS requests to DNS servers bound to the various cards. eg. when querying a NIC's DNS server, is the request always sent over that NIC even if there's a more appropriate route on a different NIC?

Regardless, there has to be a route to the internal LAN and there has to be a DNS entry on some nic for the domain's internal DNS server.

I have a feeling I'm going to be busting out wireshark to answer all this stuff.


Free Windows Admin Tool Kit Click here and download it now
January 13th, 2013 6:53pm

The Internet-facing NIC should be configured with DNS servers. The internal NIC should not.

if that's the case, how does the exchange server resolve internal domain addresses?

why does it matter which NIC is configured with which DNS server?
  • Edited by spongman Sunday, January 13, 2013 7:44 PM
January 13th, 2013 7:43pm

On Sun, 13 Jan 2013 19:43:39 +0000, spongman wrote:   > > >The Internet-facing NIC should be configured with DNS servers. The internal NIC should not. > >if that's the case, how does the exchange server resolve internal domain addresses? why does it matter which NIC is configured with which DNS server?   The external NIC is set to use your internal DNS server(s).   --- Rich Matheisen MCSE+I, Exchange MVP  
Free Windows Admin Tool Kit Click here and download it now
January 13th, 2013 10:17pm

On Sun, 13 Jan 2013 18:53:47 +0000, spongman wrote:   >Hi Rich, I'm not sure it makes any difference. > >Firstly, I can repro the problem with only a single, internal NIC. > >However, with multiple NICs it doesn't seem to make a difference what the gateways are set to, or what the binding order is I can still repro in either case. > >I have to say I'm confused about the routing of DNS requests to DNS servers bound to the various cards. eg. when querying a NIC's DNS server, is the request always sent over that NIC even if there's a more appropriate route on a different NIC?   You really only need one NIC configured with DNS, That DNS should be your internal DNS and that DNS should be configured as a forwarder to your ISP's DNS )assuming your IPS's DNS is working properly).   >Regardless, there has to be a route to the internal LAN   Yes, there does. But it doesn't have to be set on a NIC.   >and there has to be a DNS entry on some nic for the domain's internal DNS server.   Correct. But there _doesn't_ have to be an DNS on any NIC that uses your ISP's DNS. Your internal DNS is more than capable of forwarding the query to your ISP's DNS. Or you can set up one, or more, DNS as a caching DNS. There are lots of different ways to set up DNS.   >I have a feeling I'm going to be busting out wireshark to answer all this stuff.   Well, that's the way to understanding how things work. ;-)   --- Rich Matheisen MCSE+I, Exchange MVP  
January 13th, 2013 10:23pm

Hi spongman

Any further question on this thread, if it was resolved, please Mark Richs Post As Answer

Cheers

If you have any feedback on our support, please click here

Free Windows Admin Tool Kit Click here and download it now
January 22nd, 2013 3:15am

Hello,

Just had the same issue 2013 exchange.

The answer for me was to check the two boxes in the network configuration (See below) on the internal Network Card, This cured it immediately.

I wish I could explain why since the IP of this server is registered statically in DNS so this seemed superfluous.

August 16th, 2013 11:36pm

Option A works for me...

  1. Important: DNS Lookup issues may prevent or delay message delivery or cause items to sit in OWA Drafts folder (7/22)
    • Ive been following a thread on this since CU1\April but just now getting around to post it here, sorry for the delay if youve hit this issue
    • Tony Redmonds also covered this on his blog here:http://thoughtsofanidlemind.wordpress.com/2013/03/25/exchange-2013-dns-stuck-messages/
    • In some environment message delivery will fail with the following error or be delayed by many seconds or minutes.
      451 4.7.0 Temporary server error. Please try again later. PRX5
    • Threads on MS TechNet Forums: http://bit.ly/14A1JQY &http://bit.ly/13UG1ks
    • Quick Fix:
      • Option A: Set the NIC to use for External DNS lookups in EAC under Servers
      • Option B: Set ExternalDNSAdapterEnabled and InternalDNSAdapterEnabled to $false and set DNS servers on ExternalDNSServers and InternalDNSServers with the  Set-FrontendTransportService command
      • Others have used a host file with the Exchange 2013 servers in it, but the above method is easier to manage

Free Windows Admin Tool Kit Click here and download it now
October 31st, 2013 1:03am

I can also replicate this problem in my lab also.. unchecking those 2 options on the nic card will causes transport services not to start.  I don't understand why as I have static entry in DNS.  If anyone has any other ideas I'd love to hear it.
January 30th, 2014 11:13pm

Hello,

Just had the same issue 2013 exchange.

The answer for me was to check the two boxes in the network configuration (See below) on the internal Network Card, This cured it immediately.

I wish I could explain why since the IP of this server is registered statically in DNS so this seemed superfluous.

This solved my issue.  I had these unchecked because my Exchange servers run on a DNS domain that is served by Solaris-hosted BIND DNS.  The servers are NOT allowed to registered themselves dynamically, and I'm sure I'll see DNS registration in the event logs now.  However, checking these boxes solved my issue.  This seems very buggy.
Free Windows Admin Tool Kit Click here and download it now
March 18th, 2014 4:49pm

I tried all of the other answers listed here for a Exchange 2013 CU5 installation without success. I finally resolved this by edited the host file. C:\Windows\drivers\etc\host

I had to add the following

server 10.0.x.x

server.domain.local 10.0.x.x

June 11th, 2014 11:58pm

I had the same issue.

Until I installed/enabled the DNS server, it just wouldn't work. Couldn't send or receive.

Now I have an additional issue. OWA works fine, BUT Outlook doesn't.

Free Windows Admin Tool Kit Click here and download it now
August 26th, 2014 8:20pm

Below also solved the issue for me. I really appreciate who posted this solution. it was a life saver.

The answer for me was to check the two boxes in the network configuration (See above picture from Dr. Peter) on the internal Network Card, This cured it immediately.

I wish I could explain why since the IP of this server is registered statically in DNS so this seemed superfluous.


This solved my issue.

The other fix i got from another trend was to go to the exchange default frontend receive connector property, then scoping, and edit where i have port 25 binding to all IPV4 to the exact IP of the exchange server.

Hope this help someone someday.


February 3rd, 2015 8:23am

Bill, have you solved this issue I had the same issue here:(, hope you can help me out.
Free Windows Admin Tool Kit Click here and download it now
March 8th, 2015 11:53pm

Nice to see the resolution.

Alternately if could have tried just adding the netbios name and FQDN of exchange server in the host-file to see how it would give the results.

March 9th, 2015 3:28am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics