Exchange Protocol Security authentication fails after you install Windows Server 2003 Service Pack 1 on a server that has multiple SMTP virtual servers in Exchange Server 2003

You install Microsoft Windows Server 2003 Service Pack 1 (SP1) on Microsoft Exchange Server 2003 Service Pack 2 (SP2). You do this on a server that has multiple SMTP virtual servers. After you do this, Exchange Protocol Security (EXPS) authentication fails. Additionally, the following errors are logged:

Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID 1706
User: N/A Computer: computer_name
Description: EXPS is temporarily unable to provide protocol security with "server.domain.com". "CSessionContext::OnEXPSInNegotiate" called "HrServerNegotiateAuth" which failed with error code 0x8009030c ( f:\tisp2\transmt\src\smtpsink\exps\expslib\context.cpp@1799 ).

Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID 7004
User: N/A Computer: computer_name
Description: This is an SMTP protocol error log for virtual server ID 1, connection #44. The remote host "server.domain.com", responded to the SMTP command "x-exps" with "535". The full command sent was "X-EXPS ". This will probably cause the connection to fail.

Event Type: Error
Event Source: MSExchangeTransport
Event Category: SMTP Protocol
Event ID 7004
User: N/A Computer: computer_name
Description: This is an SMTP protocol error log for virtual server ID 1, connection #44. The remote host "server.domain.com", responded to the SMTP command "rcpt" with "550 5.7.1 Unable to relay for user@contoso.com ". The full command sent was "RCPT TO: user@contoso.com ". This will probably cause the connection to fail.

This problem occurs when the following conditions are true:

• The server that is running Exchange Server 2003 has SMTP virtual servers that have a Fully Qualified Domain Name (FQDN) that does not match the server name.
• The FQDNs for the SMTP virtual servers do not have a Service Principal Name (SPN) registration.

Kerberos authentication is not possible for services that do not have correctly set SPNs. SPNs are unique identifiers for services that are running on servers. Each service that uses Kerberos authentication must have an SPN set so that clients can identify the service on the network.

The SPN is registered in Active Directory under a user account as an attribute that is called Service-Principal-Name. The SPN is assigned to the account under which the service that the SPN identifies is running. Any service can look up the SPN for another service. When the SMTP service must authenticate to another Exchange Server SMTP service, it uses that service�s SPN to differentiate that service from other services that are running on that computer.

Generally, only one SPN should be set for each service. Multiple SPNs can cause clients to connect to the wrong system. Alternatively, the ticket may be encrypted by using the wrong key. If there is no SPN, authentication failures occur between virtual servers.

To resolve this problem, use one of the following methods.

Method 1: Use the Setspn.exe tool

Use the Setspn.exe tool to add an SPN that has the correct FQDN to the Active Directory object for the server that is running Exchange Server. To do this, follow these steps:

1. Install the Setspn.exe tool. To obtain the Setspn.exe tool, visit the following Microsoft Web site:
   http://support.microsoft.com/kb/970536
   The Windows Server 2003 version of the Setspn.exe tool is available in the Windows Server 2003 Support Tools. These tools are included on the Windows Server 2003 CD. To install the Windows Server 2003 Support Tools, double-click the Suptools.msi file in the Support/Tools folder.
2. Open a command prompt, and then change to the directory in which you installed Setspn.exe.
3. At the command prompt, type setspn.exe-a SMTPSVC/mail.yourdomain.comYour_Server_Name. Press ENTER.
   
   Note Replace mail.yourdomain.com with the FQDN for the SMTP virtual server. Replace Your_Server_Name with the name of the Exchange server.

Method 2: Add the FQDN of the SMTP virtual server to the BackConnectionHostNames multi_sz registry value

For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.