Temporary server error please try again later prx2

  • Remove From My Forums
  • Вопрос

  • Добрый день!

    При подключении telnet к exchange серверу возникает ошибка

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

    220 MSK-EX01.ban.loc Microsoft ESMTP MAIL Service ready at Thu, 1
    ehlo
    250-MSK-EX01.ban.loc Hello [x.x.x.x]
    250-SIZE 10485760
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-X-ANONYMOUSTLS
    250-AUTH
    250-X-EXPS GSSAPI NTLM
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250 XRDST
    mail from:testexch@banknp.org
    250 2.1.0 Sender OK
    rcpt to:testexch@banknp.org
    250 2.1.5 Recipient OK
    data
    354 Start mail input; end with <CRLF>.<CRLF>
    Test message
    .
    451 4.7.0 Temporary server error. Please try again later. PRX2

Ответы

    • Предложено в качестве ответа

      25 декабря 2013 г. 10:24

    • Помечено в качестве ответа
      Petko KrushevMicrosoft contingent staff, Moderator
      25 декабря 2013 г. 10:24

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,&amp;gt;,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,&amp;lt;,HELO,
2019-01-31T13:45:09.479Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,3,10.10.10.16:25,10.150.14.108:59877,&amp;gt;,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,&amp;lt;,MAIL FROM: &amp;lt;appserver@international.com&amp;gt;,
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,&amp;gt;,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,&amp;lt;,RCPT TO: &amp;lt;internal.user@international.com&amp;gt;,
2019-01-31T13:45:09.482Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,8,10.10.10.16:25,10.150.14.108:59877,&amp;gt;,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,&amp;lt;,RCPT TO: &amp;lt;brian@nbconsult.co&amp;gt;,
2019-01-31T13:45:09.483Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,10,10.10.10.16:25,10.150.14.108:59877,&amp;gt;,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,&amp;lt;,DATA,
2019-01-31T13:45:09.484Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,12,10.10.10.16:25,10.150.14.108:59877,&amp;gt;,354 Start mail input; end with &amp;lt;CRLF&amp;gt;.&amp;lt;CRLF&amp;gt;,
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 -&amp;gt; DnsQueryFailed: InfoNoRecords
2019-01-31T13:45:09.501Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,15,10.10.10.16:25,10.150.14.108:59877,&amp;gt;,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,&amp;lt;,QUIT,
2019-01-31T13:45:09.503Z,SERVERFrom Internal Servers (Relay),08D68772EDC476C6,17,10.10.10.16:25,10.150.14.108:59877,&amp;gt;,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 -&amp;gt; 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=&amp;lt;no priority counts&amp;gt;. Starting outbound connection for inbound session 08D68772EDC476C6
2019-01-31T13:45:09.501Z,08D68772EDC476C7,SMTP,internalproxy,&amp;gt;,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&amp;nbsp; '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:

Exchange – Event ID 205 and Event ID 16025

As soon as I completed installing Exchange 2013 CU1 in my home lab, naturally the very first thing I attempted was sending myself an email, using a simple Telnet, however I was presented with an error:

SMTPERROR2

A bit of searching revealed the answer:

In my home lab environment I currently only have 1 domain controller, so naturally I put my router as my secondary DNS server on all my configurations.

This results in the above error message. I simply removed the secondary DNS which does not point to my internal DNS/Domain Controller and now I am able to receive email.

Forwarding typically would be handled by the DNS servers in your environment, so a secondary public DNS would not be configured in a typical production environment. In a home Lab potentially you might run into this problem.

One of our client called saying that all thier Email went to Draft Folder in OWA and cannot Send & Receive Email via Exchange 2016 Server.

We do not see any error message in Event Viewer until we perform SMTP Telnet test on the Exchange Server

4.7.0 Temporary server error. Please try again later. PRX2

The root cause of this issue was they configure the alternative DNS Server to point to 8.8.8.8 (Google DNS Server) in Exchange 2016 Server.

Once we removed the DNS Google DNS Server, and only pointing to our internal AD/DNS Server, Exchange 2016 Server is back to normal and users can send & receive Email now

It is NOT required to point alternative DNS Server to External DNS if you only have a single AD Domain Controller as AD/DNS will help to resolve FQDN automatically

19 апреля Exchange 2013

В Exchange 2013 RTM и Exchange 2013 CU1 вы можете иногда получать следующие ошибки в своих клиентах Outlook, как показано ниже.

451 4.7.0 Временная ошибка сервера. Пожалуйста, попробуйте позже. PRX5
И в журналах подключения вы можете увидеть
Сервер NS возвратил ErrorRetry, о котором сообщили 0.0.0.0. [Домен: Результат] = server.domain.com:ErrorRetry
(DNS-запрос для «Не определено»: «internalproxy»: «00000000-0000-0000-0000-000000000000» завершился ошибкой: ErrorRetry)

В настоящее время это известная проблема с Exchange 2013 и может быть решена с помощью следующего. По умолчанию стандартный приемный соединитель внешнего интерфейса привязан ко всем адресам на сервере, как показано ниже, теперь известно, что это иногда вызывает проблемы с поиском DNS.

DNS front end транспорт

Нам нужно изменить здесь настройку на конкретный IP-адрес, который использует сервер Exchange 2013, а также добавить строку в наш файл hosts. Чтобы изменить привязки в Exchange 2013, щелкните значок карандаша выше, чтобы отредактировать и изменить IP-адрес для сетевого адаптера серверов Exchange, как показано ниже.

обмен 2013 днс привязки

После этого примените все настройки. Теперь перейдите к файлу hosts, который находится в C:> Windows> System32> Drivers> и т. Д.

хост-файл Exchange 2013

Отредактируйте файл хоста и, например, добавьте записи для вашего IP-адреса Exchange 2013 и его имени хоста.

192.168.16.1 сервер
192.168.16.1 server.domain.local

Как видно здесь. Затем перезагрузите сервер, и вы не получите Exchange 2013 451 4.7.0 Временная ошибка сервера. Пожалуйста, попробуйте позже. PRX5 ошибка.
отредактированный файл хоста

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!

Issue

In this scenario we are going to talk about an issue related to Exchange server not being able to accept any inbound SMTP connections. The client had one Edge server and two Exchange 2016 Mailbox servers. Out of nowhere, they have noticed that they are unable to send emails within the Exchange organization as well as all inbound emails from internet seemed to have stopped. In such a scenario, what we should do first is to identify the role that the issue might be at. In our case this is to with the SMTP mail flow thus the Hub Transport service should be involved.

Also, looking at the mail queues in the gateway and exchange servers, the Last Known Error message is shown as below;

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

Step 01:
Our first step should be to make sure that all Exchange Services are running on the servers. You can do this by going to the “Services” or opening up Exchange Powershell and running the below command to ensure that all required services are in “Running” state.

Get-ServerComponentState -Identity <ServerIdParameter>

Step 02:
Now that we know our services are working (at least showing that it’s working) let’s do a telnet and verify. You can do this by sending an email using ‘Telnet‘ from your other hops. In my case;

  • Edge server to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 01 to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 01 to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 02 to Exchange server 02 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 02 to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 02 to Edge server 01 – Message relayed successfully
  • Exchange server 02 to Edge server 02 – Message relayed successfully

What does this say? Issue is on my internal Exchange Servers, ditto!

Step 03: Now that we have established where the issue occurs on which service, the next option was to check the AD connectivity. You can do this by checking the event log for “MSExchange
ADAccess” and confirm that Exchange and AD connection is working as expected.

Step 04: Check if the time is correct on all your Exchange servers along with the time of your AD.

Step 05: Verify that the entries in your DNS is correct and working by doing a NSLOOKUP from all Exchange servers.

Step 06: Verify that your certificates are valid and SMTP services are assigned properly.

In my scenario, all steps from 1-5 were perfectly fine except for step 6. I logged into my ECP, went to Servers and Certificates and in my list, I noticed that the certificate Status was showing as ‘Invalid‘. In addition, the certificate properties showed that the SMTP service was also assigned to this certificate.

Resolution

We can get an idea on what might the issue be. We have an Invalid certificate with SMTP assigned to it. And our issue is that the Exchange server is rejecting the SMTP connections. This seems to be a valid cause. Now check your other certificates too. In my case the certificate in issue was an older custom created one. But there was a proper certificate that was set to IIS,SMTP,POP,IMAP services. That means we can delete it. However, if the certificate is a built-in certificate or the only certificate that’s assigned to all services, ‘DO NOT DELETE’.

Before deleting, it’s always a good idea to take a backup of the certificate. To do this, follow the steps;

  1. Open MMC
  2. Click File and select Add/Remove Snap In
  3. Under the Available
    snapins, click on Certificates and Add
  4. Under Certificates snap-in select ‘Computer
    account’ and click Finish
  5. Select Local Computer to manage the snap-in
  6. Click OK to add the selected snap-in to console window
  7. Go to the MMC, under Personal Certificates store, right-click on your certificate that should be exported, and select All Tasks and click Export
  8. Proceed with exporting the certificate with the Private key.

Now that we have exported the certificate, we can go back to the ECP and delete the Invalid certificate.

  1. Login to Exchange
    Admin
    Center (ECP)
  2. Navigate to Servers and click on Certificates
  3. Select the server you want to list the certificates from the drop-down menu
  4. Select the certificate which is marked as Invalid that you want to delete
  5. Click on the delete icon (recycle-bin icon)
  6. If you have multiple servers, do steps 2-5

The next step is to restart the Microsoft Exchange Transport related services so that the service will now refresh its certificate and will only use the Valid certificate(s). Do this on all servers that you removed the certificate.

Give your services to run and the mail queues to automatically restart and you will be able to see that the mail Queue will now be delivered.

Понравилась статья? Поделить с друзьями:
  • Temporary failure in name resolution network error
  • Telegram ext dispatcher error no error handlers are registered logging exception
  • Telegram error telegramerror
  • Telegram error sending code
  • Telegram error import