I've noticed that on occassion when I connect to my Exchange 2013 CU 1 server, the server will respond with "451 4.7.0 Temporary server error. Please try again later. PRX5" after I submit an e-mail for delivery.  It accepts the sender, verifies the recipient, asks for data and fails only upon submission.  Trying again right after the failure usually takes care of the problem what that's not a fix.  What's causing the problem? Anyone else seen this?

yes, i have seen the same behavior and i don't have a solution yet (my (unanswered) thread in the mail flow subforum is called "mailflow broken - error 451 4.7.0").

seems to be a common problem when you search for it in the forums, but all the suggested solutions didn't work for me. all i know is that it seems to be DNS related, but i verified my configuration again and again and cant find whats wrong :( 

I would be surprise if it really does turn out being DNS.  But at the same time, I'm not discounting anything. I think I came across your post and am surprised that others aren't reporting this problem.  Exchange 2013 has been out for a while now.

I had a comparable problem after adding a new receive connector for internal relaying. After removing my custom connector everything worked again. I don't remember the exact error message but I think it was the same.

The problem was the role of the connector that defaults to frontend transport whereas it should be hub Transport.

Maybe not exactly the solution but maybe it helps finding the cause.

Alex

I would be surprise if it really does turn out being DNS.  But at the same time, I'm not discounting anything. I think I came across your post and am surprised that others aren't reporting this problem.  Exchange 2013 has been out for a while now.

what are you seeing in the logs in C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\Connectivity and C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive (maybe you have to turn on logging first)?

in the connectivity-log i'm getting messages like:

2013-04-15T19:47:51.161Z,08D007D2D7C5ABEE,SMTP,internalproxy,>,DNS server returned ErrorRetry reported by 0.0.0.0. [Domain:Result] = EX01.zmatlo.priv:ErrorRetry; EX02.xyz.priv:ErrorRetry;
2013-04-15T19:47:51.161Z,08D007D2D7C5ABEE,SMTP,internalproxy,-,Messages: 0 Bytes: 0 (The DNS query for  'Undefined':'internalproxy':'00000000-0000-0000-0000-000000000000' failed with error : ErrorRetry)

and i really want to understand what he is trying to resolve and why it fails...what on earth does 'internalproxy' and 'Undefined' stand for??

whohoo, i FINALLY figured it out - and what can i say? the cause was another hickup of the ECP, i would call it a bug but what do i know? ;)
turns out that ex2013 has huge problems when you leave the DNS lookups setting in the server properties to "All network adapters", instead you should select a specific NIC or enter the IPs of your DNS servers manually. well, this is mentioned in numerous threads all over the forums and obviously for many people, that was the solution.
BUT...i still had no mail flow after setting the DNS servers manually and my logs still filled up with DNS errors. in the end it turned out that the setting in the ECP only configures the transport service, but NOT the the frontend transport service. you can easily check this with get-transportservice and get-frontendtransportservice and looking at the ExternalDNS and InternalDNS settings...sure enough, for me only the Transport Service had the configuration applied that i set in the ECP.
so, i configured set-frontendtransportservice with the same DNS settings as the transport service, and finally my mailflow is working...i can hardly believe it, and i can't believe that i found literally nothing about this behavior/bug of the ECP on the net. so, this is my solution - maybe it helps someone else :)

• Marked as answer by Terence YuModerator Tuesday, April 16, 2013 5:55 AM

whohoo, i FINALLY figured it out - and what can i say? the cause was another hickup of the ECP, i would call it a bug but what do i know? ;)
turns out that ex2013 has huge problems when you leave the DNS lookups setting in the server properties to "All network adapters", instead you should select a specific NIC or enter the IPs of your DNS servers manually. well, this is mentioned in numerous threads all over the forums and obviously for many people, that was the solution.
BUT...i still had no mail flow after setting the DNS servers manually and my logs still filled up with DNS errors. in the end it turned out that the setting in the ECP only configures the transport service, but NOT the the frontend transport service. you can easily check this with get-transportservice and get-frontendtransportservice and looking at the ExternalDNS and InternalDNS settings...sure enough, for me only the Transport Service had the configuration applied that i set in the ECP.
so, i configured set-frontendtransportservice with the same DNS settings as the transport service, and finally my mailflow is working...i can hardly believe it, and i can't believe that i found literally nothing about this behavior/bug of the ECP on the net. so, this is my solution - maybe it helps someone else :)

• Marked as answer by Terence YuModerator Tuesday, April 16, 2013 5:55 AM

whohoo, i FINALLY figured it out - and what can i say? the cause was another hickup of the ECP, i would call it a bug but what do i know? ;)
turns out that ex2013 has huge problems when you leave the DNS lookups setting in the server properties to "All network adapters", instead you should select a specific NIC or enter the IPs of your DNS servers manually. well, this is mentioned in numerous threads all over the forums and obviously for many people, that was the solution.
BUT...i still had no mail flow after setting the DNS servers manually and my logs still filled up with DNS errors. in the end it turned out that the setting in the ECP only configures the transport service, but NOT the the frontend transport service. you can easily check this with get-transportservice and get-frontendtransportservice and looking at the ExternalDNS and InternalDNS settings...sure enough, for me only the Transport Service had the configuration applied that i set in the ECP.
so, i configured set-frontendtransportservice with the same DNS settings as the transport service, and finally my mailflow is working...i can hardly believe it, and i can't believe that i found literally nothing about this behavior/bug of the ECP on the net. so, this is my solution - maybe it helps someone else :)

• Marked as answer by Terence YuModerator Tuesday, April 16, 2013 5:55 AM

I talked to a MS support rep today and they confirmed the same problem, except to resolve it we had to add the local server's IP to our hosts file:

192.168.1.5 server
192.168.1.5 server.domain.local

Restart "Microsoft Frontend Transport" and "Microsoft Exchange Transport" services

The support agent stated that he's seen this in a few cases now. All of which are when the Exchange server front and back-ends reside on the same box. Sounds like an Exchange bug to me.

• Marked as answer by Jacob Dybala Wednesday, April 17, 2013 2:42 AM

I talked to a MS support rep today and they confirmed the same problem, except to resolve it we had to add the local server's IP to our hosts file:

192.168.1.5 server
192.168.1.5 server.domain.local

Restart "Microsoft Frontend Transport" and "Microsoft Exchange Transport" services

The support agent stated that he's seen this in a few cases now. All of which are when the Exchange server front and back-ends reside on the same box. Sounds like an Exchange bug to me.

• Marked as answer by Jacob Dybala Wednesday, April 17, 2013 2:42 AM

I talked to a MS support rep today and they confirmed the same problem, except to resolve it we had to add the local server's IP to our hosts file:

192.168.1.5 server
192.168.1.5 server.domain.local

Restart "Microsoft Frontend Transport" and "Microsoft Exchange Transport" services

The support agent stated that he's seen this in a few cases now. All of which are when the Exchange server front and back-ends reside on the same box. Sounds like an Exchange bug to me.

• Marked as answer by Jacob Dybala Wednesday, April 17, 2013 2:42 AM

James,

I went ahead and followed your recommendation with the HOSTS file changes.  That would be in line with others were saying - that it's DNS related.

Look at my post...

I came to same conclusion that ECP is borked up: http://social.technet.microsoft.com/Forums/en-US/exchangesvrsecuremessaging/thread/66f0629f-21fb-444b-b3f1-99ed8a4f52b2

What the hell were they thinking when releasing CU1 in this state?

I talked to a MS support rep today and they confirmed the same problem, except to resolve it we had to add the local server's IP to our hosts file:

192.168.1.5 server
192.168.1.5 server.domain.local

Restart "Microsoft Frontend Transport" and "Microsoft Exchange Transport" services

The support agent stated that he's seen this in a few cases now. All of which are when the Exchange server front and back-ends reside on the same box. Sounds like an Exchange bug to me.

We also had this problem, but started with a PRX2 error. To solve the PRX2 error, we removed the secondary DNS entry from the NIC properties and only left the internal DNS entry (himself in fact). Then we got the PRX5 error and arrived on this post which solved the problem.

Steve Thanks for this solution it did help me.

The solution is "... to add the local server's IP to our hosts file:"???  And this is by design???!!!

No comments...

Someone still wants to deploy 2013 instead of 2010?

I talked to a MS support rep today and they confirmed the same problem, except to resolve it we had to add the local server's IP to our hosts file:

192.168.1.5 server
192.168.1.5 server.domain.local

Restart "Microsoft Frontend Transport" and "Microsoft Exchange Transport" services

The support agent stated that he's seen this in a few cases now. All of which are when the Exchange server front and back-ends reside on the same box. Sounds like an Exchange bug to me.

Hi James - I just wanted to clarify which server you are referring to above. Do you mean to add the sending server's IP address to the hosts file of the exchange server?

Hi James, when you say that you added the local server's IP to your host file, are you referring to the DNS server or the Exchange server IP and FQDN?

Thanks in advance!

BJD

Not sure what fixed mine BUT it was one of these two -

Added the server name and FQDN to the HOSTS file and also I noticed the transport services wasn't started (just the front end transport) so I started it up.

After, all is well!

• Proposed as answer by BigSkyTom Sunday, June 15, 2014 7:27 PM

Not sure what fixed mine BUT it was one of these two -

Added the server name and FQDN to the HOSTS file and also I noticed the transport services wasn't started (just the front end transport) so I started it up.

After, all is well!

• Proposed as answer by BigSkyTom Sunday, June 15, 2014 7:27 PM

Not sure what fixed mine BUT it was one of these two -

Added the server name and FQDN to the HOSTS file and also I noticed the transport services wasn't started (just the front end transport) so I started it up.

After, all is well!

• Proposed as answer by BigSkyTom Sunday, June 15, 2014 7:27 PM

For three days I have been trying to figure out why SharePoint was not sending outbound emails.  I finally remembered my Exchange 5.5??? days and thought I'd better test Telnet to see if Exchange was the problem instead of Sharepoint.  I tried everything.

In the end I added Exchange to the local hosts file and restarted the transport services.  It all started working. 

Thanks for you post here Brandon.

• Edited by BigSkyTom Sunday, June 15, 2014 7:28 PM

For three days I have been trying to figure out why SharePoint was not sending outbound emails.  I finally remembered my Exchange 5.5??? days and thought I'd better test Telnet to see if Exchange was the problem instead of Sharepoint.  I tried everything.

In the end I added Exchange to the local hosts file and restarted the transport services.  It all started working. 

Thanks for you post here Brandon.

• Edited by BigSkyTom Sunday, June 15, 2014 7:28 PM

For three days I have been trying to figure out why SharePoint was not sending outbound emails.  I finally remembered my Exchange 5.5??? days and thought I'd better test Telnet to see if Exchange was the problem instead of Sharepoint.  I tried everything.

In the end I added Exchange to the local hosts file and restarted the transport services.  It all started working. 

Thanks for you post here Brandon.

• Edited by BigSkyTom Sunday, June 15, 2014 7:28 PM

I had the same problem for me the solution to your problem was to go the the receive connectors and to the default Front end Connector for your server.

go to scoping and on port 25 it is stating for all ipv4 addresses. change this to your exchange server address and all my mail started coming in to the mailboxes

http://www.techieshelp.com/exchange-2013-451-4-7-0-temporary-server-error-please-try-again-later-prx5/

• Edited by Catweazle293 Tuesday, July 08, 2014 11:17 AM

I had the same problem for me the solution to your problem was to go the the receive connectors and to the default Front end Connector for your server.

go to scoping and on port 25 it is stating for all ipv4 addresses. change this to your exchange server address and all my mail started coming in to the mailboxes

http://www.techieshelp.com/exchange-2013-451-4-7-0-temporary-server-error-please-try-again-later-prx5/

• Edited by Catweazle293 Tuesday, July 08, 2014 11:17 AM

I had the same problem for me the solution to your problem was to go the the receive connectors and to the default Front end Connector for your server.

go to scoping and on port 25 it is stating for all ipv4 addresses. change this to your exchange server address and all my mail started coming in to the mailboxes

http://www.techieshelp.com/exchange-2013-451-4-7-0-temporary-server-error-please-try-again-later-prx5/

• Edited by Catweazle293 Tuesday, July 08, 2014 11:17 AM

Others have fixed this issue by editing the HOST FILE of the server , but i think that is incorrect. We should look at the root of the problem.

In our environment, running the cmdlet

Get-Transportserver [YOUREXCHANGESERVER] : Format-List internaldnsservers, externaldnsservers

Shows a blank value. Those values need to be populated, so we can run:

Set-TransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-TransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

Set-FrontEndTransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-FrontEndTransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

 After doing this and rebooting, these SMTP errors went away in our environment.

• Proposed as answer by Thestephenh Thursday, January 29, 2015 12:23 AM

Others have fixed this issue by editing the HOST FILE of the server , but i think that is incorrect. We should look at the root of the problem.

In our environment, running the cmdlet

Get-Transportserver [YOUREXCHANGESERVER] : Format-List internaldnsservers, externaldnsservers

Shows a blank value. Those values need to be populated, so we can run:

Set-TransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-TransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

Set-FrontEndTransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-FrontEndTransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

 After doing this and rebooting, these SMTP errors went away in our environment.

• Proposed as answer by Thestephenh Thursday, January 29, 2015 12:23 AM

Others have fixed this issue by editing the HOST FILE of the server , but i think that is incorrect. We should look at the root of the problem.

In our environment, running the cmdlet

Get-Transportserver [YOUREXCHANGESERVER] : Format-List internaldnsservers, externaldnsservers

Shows a blank value. Those values need to be populated, so we can run:

Set-TransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-TransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

Set-FrontEndTransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-FrontEndTransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

 After doing this and rebooting, these SMTP errors went away in our environment.

• Proposed as answer by Thestephenh Thursday, January 29, 2015 12:23 AM

Thanks so much! I was trying to fix this issue for over a week. As soon as I did this, my mail started flowing correctly.

I did both - the host entries in "hosts" file, which doesn't really hurt anything

AND set the values for DNS in the UI.

BUT, still had some errors - so, two final things:

The Drop-down in the UI, choose "YOUR specific NIC," not "All available server NICs"

And STILL, mail was flowing ONLY inbound to the new 2013 server - only when I did this next change, did it flow both ways:

In Advanced properties of the NIC, under ipv4, DNS tab, "Check" the checkbox "Register this connection in DNS."

I had it un-checked, because MS said "If you have a DAG, and DAG communication uses the NIC, then UNCHECK that box." Well, unchecking that box breaks Exchange, so it has to be checked. We use the single NIC for email as well as DAG traffic, so we don't have a separate dedicated "DAG LAN." I might end up setting up a dedicated LAN for the DAG, if this "register in DNS" causes any issues.

I hope all these steps help someone.

PLEASE MARK ME AS HELFPUL, if you found my info helpful!

Thanks!

Thanks! I had the same problem and finaly it's working!!!

Saludos

Gracias por esta ayuda, yo tambin tenia miles de errores sobre todo en transporte y con la edicin del archivo host lo solucione, esto debido a que mis DNS estn aislados el interno del externo y aplicando buenas practicas ninguna funciono.

Tambin estoy de acuerdo con el problema de estabilidad en Exchange Server 2013 pero tal vez es para que todos se pasen a Officce 365 creo yo a modo personal.

Gracias.

Saludos

Gracias por esta ayuda, yo tambin tenia miles de errores sobre todo en transporte y con la edicin del archivo host lo solucione, esto debido a que mis DNS estn aislados el interno del externo y aplicando buenas practicas ninguna funciono.

Tambin estoy de acuerdo con el problema de estabilidad en Exchange Server 2013 pero tal vez es para que todos se pasen a Officce 365 creo yo a modo personal.

Gracias.

*******

Luego de editar este archivo como a eso de las 3PM me quede sin correo nuevamente, al parecer es un problema de sincronizacion de hora con el servidor que permite la entrada de los correos que en mi caso es un UTM Firewall y que tenia la hora no sincronizada y esto generaba este error, ya esta normal luego de ajustar la hora en l.

Segun reporte de Microsoft deben estar bien sincronizados mximo diferencia de 5 minutos los catalogos globales, FSMO, Client Access, Buzn y Fierwall o servidor perimetral de recepcin.

Gracias

• Edited by soporteredes 14 hours 59 minutes ago

Saludos

Gracias por esta ayuda, yo tambin tenia miles de errores sobre todo en transporte y con la edicin del archivo host lo solucione, esto debido a que mis DNS estn aislados el interno del externo y aplicando buenas practicas ninguna funciono.

Tambin estoy de acuerdo con el problema de estabilidad en Exchange Server 2013 pero tal vez es para que todos se pasen a Officce 365 creo yo a modo personal.

Gracias.

*******

Luego de editar este archivo como a eso de las 3PM me quede sin correo nuevamente, al parecer es un problema de sincronizacion de hora con el servidor que permite la entrada de los correos que en mi caso es un UTM Firewall y que tenia la hora no sincronizada y esto generaba este error, ya esta normal luego de ajustar la hora en l.

Segun reporte de Microsoft deben estar bien sincronizados mximo diferencia de 5 minutos los catalogos globales, FSMO, Client Access, Buzn y Fierwall o servidor perimetral de recepcin.

Gracias

• Edited by soporteredes Saturday, July 04, 2015 4:25 PM

Your the man! Still on a problem in Exchange 2013 as of this date.