One or both of the following events may be logged in the application logs:
Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 7004
Time: 5:23:43 PM
This is an SMTP protocol error log for virtual server ID 1, connection #29. The
remote host "E2k3server1.contoso.com", responded to the SMTP command "xexch50" with
"504 Need to authenticate first ". The full command sent was "XEXCH50 2336 3 ".
This will probably cause the connection to fail.
Event Type: ErrorNote
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID: 7010
Time: 5:43:49 PM
This is an SMTP protocol log for virtual server ID 1, connection #30. The client at
"126.96.36.199" sent a "xexch50" command, and the SMTP server responded with "504 Need to
authenticate first ". The full command sent was "xexch50 1092 2". This will
probably cause the connection to fail. These events indicate that the XEXCH50 protocol sink fired, but the exchange of the
blobs failed between the servers listed in the events.
You will see Event IDs 7004 and 7010 only if you turn up diagnostic logging on the MSExchangeTransport event source to medium or higher.
To troubleshoot this issue, follow these steps:
- Verify that Integrated Windows Authentication is enabled on the SMTP virtual servers on the Exchange Server computers in your organization. If it is not enabled, follow these steps:
- In Exchange System Manager, expand Administrative Groups, expand Servers, expand Exchange Server Name, expand Protocols, and then expand SMTP.
- Right-click the SMTP virtual server. (By default, this is named Default SMTP Virtual Server.)
- Click Properties, click the Access tab, and then click Authentication. Make sure that the Integrated Windows Authentication check box is selected.
- If Integrated Windows Authentication is enabled, but the events persist, the sending server in the 7004 event or in the 7010 event may lack or be denied the SendAs right on the receiving server. If the sending server and the receiving server are experiencing these events, the servers may lack the SendAs rights on each other. The SendAs right is not set explicitly. The SendAs right is typically inherited through membership in the Exchange
Domain Servers (EDS) group. If the EDS does not have this DENY access control entry (ACE) , the affected server
may be nested in another group that has the DENY ACE, or the EDS may be nested in some
other groups that have the DENY ACE. To succeed, the XEXCH50 command has to have the SendAs right for servers in the
- Check to see whether you are using Transport Layer Security (TLS) and a security channel between servers in the Exchange organization. In this scenario, the STARTTLS transport event sinks fire
before the AUTH command. The XEXCH50 command fails later in the session because of lack of the AUTH command.
- If Exchange Protocol Security (EXPS) authentication is not working correctly between servers, the XEXCH50 command will
not work. Events 1704 and 1706 indicate EXPS authentication failures in the application log.
Event Type: WarningNote error code 0x8009030c translates to the SEC_E_LOGON_DENIEDHresult.
Event Source: MSExchangeTransport
Category: SMTP Protocol
Event ID: 1706
EXPS is temporarily unable to provide protocol security with
"<ServerName>.<Domain>.com". "CSessionContext::OnEXPSInNegotiate" called
"HrServerNegotiateAuth" which failed with error code 0x8009030c
0c 03 09 80 ...?
These problems may be difficult to troubleshoot, because the Microsoft Windows credentials of EXPS are required to pass this AUTH command. You can use various tools to troubleshoot the combination of Event ID 7006 and 7004, including the NLTEST tool and the NETDOM tool. Troubleshooting steps may include resetting machine account passwords.
If you have a combination of Event ID 7006 and 7004 in the application log as described earlier, and you cannot discover the source of the problem by using EXPS authentication, contact Microsoft Product Support Services. If you do not have the combination of Event ID 7006 and 7004 in the application log, go to step 5. If you want more information about EXPS, see the More Information section.
- Verify whether there is a firewall or a virus wall between servers in the Exchange organization. If there is a firewall between servers in the organization, you can test whether it is causing the problem. To do this, temporarily disable the firewall.
For more information about how to turn up diagnostic logging for transport issues, click the following article numbers to view the articles in the Microsoft Knowledge Base:
How to troubleshoot for Exchange Server 2003 transport issues
General troubleshooting for transport issues in Exchange 2000 Server and in Exchange Server 2003
Other scenarios where you may see Event ID 7004 with error 504
Event ID 7004 with error 504 is expected, if the server that is indicated in Event ID 7004 is an Exchange 2000 Server computer, or an Exchange Server 2003 computer in a different Exchange organization, if there is no connector configured for cross-forest trust between the Exchange organizations.
For more information about cross-forest implementations, click the following article number to view the article in the Microsoft Knowledge Base:
Resolve anonymous senders functionality in Microsoft Exchange 2003
In article 828770, see the "Authentication in cross-forest scenarios" section.
Event ID 7004 with error 504 is also expected if the server is an external Internet server (Exchange 2000 Server or Exchange Server 2003).
If an Exchange 5.5 server has version 5.5.2657.72 of Msexcimc.exe or later of the Internet Mail Service (IMS) connector, and if the Exchange 5.5 server exists in an e-mail domain that is external to the sending Exchange 2000 Server computer or to the Exchange Server 2003 computer, the receiving Exchange 5.5 IMS connector will not understand the XEXCH50
command from the sending Exchange Server computer. The 7004 event with the "505 Authentication required" error in the application log on the sending Exchange Server computer is typical when mail is being sent from an Exchange 2000 Server computer or from an Exchange Server 2003 computer to an Exchange 5.5 Server computer in an external e-mail domain over the Internet. One way to resolve this issue to suppress sending the XEXCH50
command outside the Exchange organization where the Exchange 2000 Server computer or the Exchange Server 2003 computer resides.
To resolve this behavior on the Exchange 2000 Server computer or on the Exchange Server 2003 computer, you can set the SuppressExternal registry key to 1. This setting prevents Exchange Server from trying to send the XEXCH50
command outside the Exchange organization.
For more information about how to create the SuppressExternal registry key and set it to 1, click the following article number to view the article in the Microsoft Knowledge Base:
Messages remain in an outbound queue until a non-delivery report is generated when you send e-mail to a remote domain
Additional symptoms that may accompany Event IDs 7004 and 7010
If the XEXCH50
command is not working correctly, as indicated by the 7004 events and by the 7010 events,
you may see the following symptoms:
- Public folder replication to Exchange 2000 Server computers and to Exchange Server 2003 computers will be affected.
- Mail to public folders will be affected.
- Typical message journaling may not work, or duplicate journal messages
may be experienced.
For more information about troubleshooting message journaling, click the following article number to view the article in the Microsoft Knowledge Base:
Troubleshooting message journaling in Exchange Server 2003 and in Exchange 2000 Server
- Envelope Journaling may not work correctly if it is enabled in the Exchange organization for reports.
- Delivery Report settings for Distribution Groups may not work correctly.
- Distribution Group expansion may not work correctly.
- Distribution Group permissions and restrictions may not work as expected.
- Mail to hidden Distribution Groups may not work as expected.
- Messages to alternate recipients may cause duplicates.
- Intelligent Message Filtering (IMF) may not work as expected.
More information about XEXCH50
XEXCH50 is an Exchange ESMTP extension that is used to relay certain
properties, such as envelope properties, message properties, and recipient properties. The XEXCH50
a short command. An XEXCH50
command that has received a success type
response is then followed by a binary large object (BLOB) of variable size. (The size
corresponds to the first argument of the XEXCH50
More information about TLS and STARTTLS
command is described in RFC 2487 that is named SMTP Service Extension for Secure SMTP over TLS
. To view this RFC, visit the following IETF Web site:Note
To help protect communications, you can configure Microsoft SMTP Service to encrypt SMTP transmissions by using Transport Layer Security (TLS). This functionality is provided through the STARTTLS
SMTP protocol command.
More information about EXPS
X-EXPS is a verb that is proprietary to Exchange Server, although it is similar to AUTH.
The syntax of the data commands and of the responses depends on the AUTH package that you select, such as LOGIN, NTLM, GSSAPI, or others. For more information, see the AUTH RFC.
Although EXPS stands for Exchange Protocol Security, the only protocol that it refers to is the SMTP. Some verbs that are used in Exchange 2000 Server and in Exchange Server 2003 are proprietary to these products and are together with ESMTP verbs. They are known as ESMTP X verbs.
For more information about ESMTP X verbs, click the following article number to view the article in the Microsoft Knowledge Base:
Definitions of verbs that are used between 2 Exchange servers
If the ehlo
name that is being sent and that is being advertised cannot be found in an Exchange organization, the GSSAPI authentication (EXPS) capabilities of a receiving server will persist. The ehlo
name will be ignored as if it never was advertised. Essentially, the sending server will not try to authenticate.
Network Monitor traces have shown that the sending server never issues GSSAPI authentication and logs the "504 need to authenticate" SMTP protocol error after the XEXCH50 verb. To resolve this issue, make sure that you have the correct fully qualified domain name (FQDN) in the SMTP virtual server properties.
To verify the delivery settings for the SMTP virtual server, follow these steps:
- Click Start, point to All Programs, point to Microsoft Exchange, and then click System Manager.
- If the Display administrative groups check box is selected, expand Administrative Groups, and then expand First Administrative Group.
To display administrative groups, right-click Your_Organization, click Properties, click to select the Display administrative groups check box, click OK two times, and then restart Exchange System Manager.
- Expand Servers, expand Your_Exchange_Server, expand Protocols, and then click SMTP.
- In the right pane, right-click Default SMTP Virtual Server, and then click Properties.
- Click the Delivery tab, and then click Advanced.
- Verify that value that is listed in the Fully-qualified domain name box is the actual FQDN of the server.
The FQDN value can either be the network basic input/output system (NetBIOS) name or the FQDN.
If the name that is listed in the Fully-qualified domain name
box has been changed to try to spoof the 220 response name or to spoof the names in the RFC 2821 received headers, the symptoms that are listed in the "Symptoms" section are some of the results.
Additionally, verify that there are no dropped packets between the servers. Make sure that the firewall does not block extended SMTP verbs such as XEXCH50
Article ID: 843106 - Last Review: October 25, 2007 - Revision: 5.3
- Microsoft Exchange Server 2003 Enterprise Edition
- Microsoft Exchange Server 2003 Standard Edition
- Microsoft Exchange 2000 Enterprise Server
- Microsoft Exchange 2000 Server Standard Edition