none
451 4.7.0 Temporary server error. Please try again later. PRX2 RRS feed

  • Question

  • 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
    Saturday, January 12, 2013 7:39 PM

Answers

  • 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
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, January 13, 2013 10:23 PM
  • 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
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, January 13, 2013 10:17 PM

All replies

  • 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).

    Saturday, January 12, 2013 8:01 PM
  • 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).

    Saturday, January 12, 2013 8:21 PM
  • 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.

    Saturday, January 12, 2013 8:33 PM
  • 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
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, January 13, 2013 3:59 AM
  • 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.


    Sunday, January 13, 2013 6:53 PM
  • 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
    Sunday, January 13, 2013 7:43 PM
  • 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
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, January 13, 2013 10:17 PM
  • 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
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, January 13, 2013 10:23 PM
  • Hi spongman

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

    Cheers

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


    Zi Feng
    TechNet Community Support

    Tuesday, January 22, 2013 3:15 AM
    Moderator
  • 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.

    Friday, August 16, 2013 11:36 PM
  • 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)
      • I’ve been following a thread on this since CU1\April but just now getting around to post it here, sorry for the delay if you’ve hit this issue
      • Tony Redmond’s 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

    Thursday, October 31, 2013 1:03 AM
  • 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.
    Thursday, January 30, 2014 11:13 PM
  • 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.
    Tuesday, March 18, 2014 4:49 PM
  • 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

    Wednesday, June 11, 2014 11:58 PM
  • 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.


    William A. Fink

    Tuesday, August 26, 2014 8:20 PM
  • 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.


    Tuesday, February 3, 2015 8:23 AM
  • Bill, have you solved this issue? I had the same issue here:(, hope you can help me out.
    Monday, March 9, 2015 3:52 AM
  • 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.


    BR/Deepak

    Monday, March 9, 2015 7:26 AM
  • I just saw this in my history.  This ended up being the answer.  The crazy thing... After unchecking it again and rebooting, everything still worked.  I don't understand why this randomly caused the issue.
    Thursday, January 28, 2016 10:54 PM
  • I was having the same issue, but mine was due to me using a secondary external DNS server (8.8.8.8) - Even though all of my internal records were there, it was trying to go out the secondary and causing issues.  As soon as I removed it all was well!
    • Proposed as answer by Carlos Durazno Saturday, October 5, 2019 5:08 AM
    Tuesday, July 23, 2019 7:03 PM
  • I was having the same issue, but mine was due to me using a secondary external DNS server (8.8.8.8) - Even though all of my internal records were there, it was trying to go out the secondary and causing issues.  As soon as I removed it all was well!
    Same issue, solved as you proposed on Core 2019 server with EXch 2019 cu3.  Thnx
    Saturday, October 5, 2019 5:10 AM