Jude's Blog

Posts Tagged ‘Exchange Server

Fixing “451 4.7.0 Temporary server error. Please try again later. PRX4”

leave a comment »


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.



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

Written by judeperera

October 11, 2019 at 11:28 am

Field Report: Cisco and Exchange woes. 451 5.7.3 Cannot achieve Exchange Server authentication. Telnet fails with 200*****

with one comment

So this was a strange case that i came across with. Here’s my setup.



In this scenario, strangely it was noticed that the mail is getting queued in our Exchange 2013 environment which is bound to Exchange 2010 mailboxes. Upon the error notification, we identified the below error.

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

Additionally, upon doing a telnet from the Server B range to Server A range, we noticed that we are not getting the expected banner while telnet’ing port 25 as below.

Also, EHLO command fails with 500 5.3.3 Unrecognized command


If i try to telnet the relevant server from the same subnet, I get the correct HELO banner and the EHLO reply as below.


If you are getting the above error, it could be due to two reasons.

  1. The sending Exchange Server do not have authentication permission on the receiving Exchange Server(s).
    If this is the case, that means the Exchange server which we cannot send email to doesn’t have it’s Exchange Server Authentication enabled. Because of this, when the Sending Exchange server is trying to authenticate against the receiving servers, it fails. To resolve this we need to set Exchange Server Authentication enabled, on the recipient servers receive connector.

    1. Login to your Exchange Hub Transport Server where you cant send the mail to.
    2. In the Exchange Management Console, expand Server Configuration in the console tree, and select Hub Transport.
    3. In the work pane, select the Receive Connectors tab.
    4. Double-click the Default Receive connector.
    5. Ensure that the Exchange Server authentication option is selected.
    6. Click OK to save.
    7. Restart the Microsoft Exchange Transport Service.
  2. There could be a Cisco firewall sitting between the Exchange Servers.
    This could be a trike situation. If you have placed a firewall between servers due to whatever reason and if your firewall is a Cisco FWSM,  Cisco PIX or Cisco ASA then the Mailguard feature might be the cause. (In my case, this was the culprit)
    If this is your issue. you need to disable ESMTP inspection. Microsoft has a KB article written which you can check out so the network team can set it up accordingly.


Did it work? Anything else you want to add? let us know..