Article ID: 979175 - Last Review: December 27, 2011 - Revision: 2.0

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

System TipThis article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.

On This Page

Expand all | Collapse all

SYMPTOMS

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.

CAUSE

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.

RESOLUTION

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:

  1. Start Exchange Management Console.
  2. Expand Server Configuration and then click Hub Transport.
  3. Click the Receive Connectors tab.
  4. 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.
  5. 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.
  6. On the Authentication tab, make sure that the Exchange Server authentication check box is selected.

For Microsoft Exchange Server 2003 remotes servers:

  1. Start Exchange System Management.
  2. Expand the Servers container.
  3. Under the problematic remote Exchange server, locate to the Protocols container.
  4. Expand the Protocols container, right-click SMTP.
  5. Right-click Default SMTP Virtual Server and then click Properties.
  6. Click the Access tab and then click Authentication.
  7. Make sure that the Integrated Windows Authentication check box is selected.

MORE INFORMATION

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*'}

APPLIES TO
  • Microsoft Exchange Server 2010 Enterprise
  • Microsoft Exchange Server 2010 Standard
  • Microsoft Exchange Server 2007 Enterprise Edition
  • Microsoft Exchange Server 2007 Standard Edition
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
Keywords: 
kbemail kbexpertiseinter kbsurveynew kbprb KB979175