Service principal name should not be registered

[This topic is intended to address a specific issue called out by the Exchange Server Analyzer Tool. You should apply it only to systems that have had the Exchange Server Analyzer Tool run against them and are experiencing that specific issue. The Exchange Server Analyzer Tool, available as a free download, remotely collects configuration data from each server in the topology and automatically analyzes the data. The resulting report details important configuration issues, potential problems, and nondefault product settings. By following these recommendations, you can achieve better performance, scalability, reliability, and uptime. For more information about the tool or to download the latest versions, see "Microsoft Exchange Analyzers" at https://go.microsoft.com/fwlink/?linkid=34707.]  

Topic Last Modified: 2009-02-04

The Microsoft Exchange Server Best Practices Analyzer examines the service principal name (SPN) entries for Exchange Server 2003-based servers. The Best Practices Analyzer generates an error message if the following conditions are both true:

  • The following SPNs are registered on the Exchange server:

    • exchangeAB/<ExchangeServerName>

    • exchangeAB/<ExchangeServerName>.contoso.com

  • The Exchange server is not a global catalog server.

If these SPNs are registered on an Exchange 2003-based server that is not also a global catalog server, you experience the following symptoms in your Exchange organization:

  • You cannot use Microsoft Office Outlook 2007 to access an Exchange 2003 mailbox. In this scenario, when you try to access Exchange 2003 mailboxes from Outlook 2007, you are repeatedly prompted for credentials.

  • An SPN is a unique name that identifies an instance of a particular service. Also, an SPN is associated with the logon account under which the service instance runs. Exchange 2003 requires correctly configured SPNs to enable Kerberos authentication for mailbox access. By default, Outlook uses Kerberos authentication for mailbox access. However, Outlook 2007 does not fall back to Windows Authentication (NTLM) if Kerberos authentication is unsuccessful.

    Note

    Earlier versions of Outlook do fall back to Windows Authentication if Kerberos authentication is unsuccessful.

To address these issues, configure the exchangeAB resources in the Active Directory directory service. To do this, see Microsoft Knowledge Base article 927612, You are repeatedly prompted to enter your credentials when you try to connect to an Exchange mailbox by using Outlook 2007.