Exchange Server 2007: Some e-mail messages become stuck in an Exchange Server environment

SUPPORT SOLUTION:
In a Microsoft Exchange Server environment, some e-mail messages become stuck in a remote delivery queue going to another Exchange server. If you open the Queue Viewer tool from the Toolbox node on the Exchange Management Console, the Last Error field displays the following error message:
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.
.This problem occurs because the Exchange server cannot authenticate with the remote Exchange server. Authentication is required for Exchange servers to route internal e-mail messages between them.
Upon connection to another Exchange server, the sending server tries to use the X-EXPS command to authenticate. This failure can occur if the remote server does not enable the command, or if a firewall is preventing the authentication.
.To resolve this issue, all receive connectors that receive internal e-mail messages should have Exchange Authentication enabled.
Note If there is a firewall located between the two servers, the Extended SMTP verbs X-ANONYMOUSTLS, X-EXPS, and GSSAPI must be able to pass.
.For Microsoft Exchange Server 2007 or Microsoft Exchange Server 2010 remote servers:
2, ‘resolution’);
Start Exchange Management Console.
Expand Server Configuration and then click Hub Transport.
Click the Receive Connectors tab.
Locate the remote Exchange server receive connector that the e-mail message is trying to be sent to.

Note To determine this, you can review the send protocol logs
(http://technet.microsoft.com/en-us/library/aa997624.aspx)
from the server that the e-mail message is stuck in.
Right-click the receive connector and then click Properties.

NoteThis is typically the Default server_name receive connector for the remote Exchange server, unless modifications were made. If you are not sure which connector is used, receive protocol logs
(http://technet.microsoft.com/en-us/library/aa997624.aspx)
shows the receive connector that is used.
On the Authentication tab, make sure that the Exchange Server authentication check box is selected.
.For Microsoft Exchange Server 2003 remotes servers:
2, ‘resolution’);
Start Exchange System Management.
Expand the Servers container.
Under the problematic remote Exchange server, locate to the Protocols container.
Expand the Protocols container, right-click SMTP.
Right-click Default SMTP Virtual Server and then click Properties.
Click the Access tab and then click Authentication.
Make sure that the Integrated Windows Authentication check box is selected.
.This article replaces solution objects SOX070130700052 and SOX070518700065.
An alternative way to identify possible problematic receive connectors by using Exchange Management Shell, is if the queue delivery type is SmtpRelayToRemoteAdSite. To do this, run the following shell commands:
$remotesite = (get-queue | where {$_.LastError -like “451 4.4.0*”}).NextHopDomain
get-exchangeserver | where {$_.site -like ‘*’+$remotesite} | get-transportserver | Get-ReceiveConnector | where {$_.Bindings -like ‘*:25*’} | where {$_.AuthMechanism -notlike ‘*Exchange*’}
.; ; .

For File Repair and Data Recovery, visit File Repair / Data Recovery