Top support issues for the Exchange directory service

This article provides a list of the top support issues for the Exchange 2000 Server and Exchange Server 2003 directory service.

Note This article does not provide a complete list of all of the support issues for the Exchange 2000 Server and Exchange Server 2003 directory service. This article provides some potentially useful Microsoft Knowledge Base articles about Exchange directory service support and troubleshooting.

The Missing SeSecurityPrivilege right prevents services from starting

The Exchange Information Store databases may not mount. The following error message may be logged in the Event Viewer Application log: To resolve this issue, use one of the following methods:

• Manually grant the Manage Auditing and Security Log right (SeSecurityPrivilege) to the Exchange 2000 Enterprise Server computers.
  
• Run Exchange 2000 Setup again with the /domainprep switch. This automatically grants the Manage Auditing and Security Log right (SeSecurityPrivilege) to the Exchange 2000 Enterprise Server computers.
  
• Use the resolution that is described in the following Microsoft Knowledge Base article:
  284934 An event ID 1029 message is logged after you install Exchange 2000 Server

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base: For additional information, also see the "Microsoft Exchange 2000 Server Installation and Setup" white paper at the following Microsoft Web site:

The Active Directory Connector does not replicate mailboxes because a Directory or Recipient Connection Agreement is configured incorrectly

Incorrectly configured Connection Agreements may produce a variety of symptoms. The most common symptoms are:

• Users on one side of the Connection Agreement are not visible from the other side of the Connection Agreement (from Exchange 2000 to Microsoft Exchange Server 5.5, or from Exchange Server 5.5 to Exchange 2000).
• No replication occurs. This symptom may occur if you have only a one-way recipient Connection Agreement. Your recipient Connection Agreement may point to the wrong container or a container that is not valid. The scheduling for the recipient Connection Agreement also may not be set correctly.

To resolve this issue, make sure that the settings on the recipient Connection Agreements are correct. Fix any incorrect settings. Also check the Event Viewer for any relevant messages that may have been logged. For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

The Global Catalog server cannot be located because the Named Service Provider Interface (NSPI) is not enabled on the Global Catalog server

If you promote a computer to a global catalog server and do not restart the computer, service location (SRV) records are placed in Domain Name System (DNS). The Exchange System Attendant tries to use the new server. The System Attendant determines that the Named Service Provider Interface (NSPI) is not enabled and logs the following message in the Application event log on the Exchange 2000 server: If you try to resolve a new Microsoft Outlook profile for an Exchange mailbox, you may receive the following error message: However, you can gain access to the mailbox by using Internet Message Access Protocol (IMAP) and Post Office Protocol version 3 (POP3).

This issue may occur if the NSPI is not enabled on the global catalog server.

To resolve this issue, restart the global catalog server. This enables the NSPI. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

A Global Catalog server is unavailable

For additional information on events that may be logged in the Event Viewer Application log when a Global Catalog server is unavailable, click the following article number to view the article in the Microsoft Knowledge Base:

A security hotfix prevents clients from gaining access to the Global Address List

After you apply one of the following fixes on a global catalog server

• The 299687 Microsoft Windows 2000 security hotfix. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
  299687 MS01-036: Function exposed by using LDAP over SSL could enable passwords to be changed
• The 311401 Windows 2000 security rollup package. For additional information, click the article number below to view the article in the Microsoft Knowledge Base:
  311401 Windows 2000 Security Rollup Package 1 (SRP1), January 2002

the following symptoms may occur:

• Existing Messaging Application Programming Interface (MAPI) client computers cannot browse the Global Address List.
• If you try to do a "check name" procedure when you create a new Outlook profile, the procedure does not work. You receive the following error message:
  The name could not be matched to a name in the address list
• When you compose a new e-mail message, the names are not resolved.

This issue may occur if you use the 299687 Windows 2000 security hotfix, and you set the RestrictAnonymous registry key to a value of 0x2. In this scenario, the global catalog server does not allow anonymous access, and Exchange and Outlook cannot access Active Directory.

To resolve this issue, check the value of the RestrictAnonymous registry key on the global catalog server. If the value is set to 0x2, and either the Q299687 Windows 2000 security hotfix or the Q311401 Windows 2000 security rollup package is installed, change the RestrictAnonymous value to 0x0. Restart the global catalog server to make this change take effect. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

The Recipient Update Service does not stamp accounts, which prevents users from creating profiles

You may not be able to create an Outlook profile. When you type your name in the mailbox box, and then click Check Name, you receive the following error message: This issue may occur if the Recipient Update Service has not stamped the user accounts with the following attributes:

• showInAddressBook ()
• textEncodedORAddress
• msExchUserAccountControl
• msExchALObjectVersion
• msExchPoliciesIncluded

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

The Recipient Update Service points to a server that is not valid, which prevents user objects from being stamped with proxy addresses

New user objects may not be stamped with proxy addresses.

This issue may occur if the Recipient Update Service points to an Exchange server or domain controller that is not valid. This issue may also occur if the Recipient Update Service does not point to any server. This issue typically occurs if you remove either the Exchange server or domain controller and forget to modify the Recipient Update Service properties.

To resolve this issue, make sure that the Recipient Update Service points to a valid Exchange server or domain controller, depending on which setting is not configured correctly. For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

Missing proxy address generation DLL causes the Recipient Update Service not to stamp proxy addresses

For additional information on diagnosing and troubleshooting a missing proxy address generator, click the following article number to view the article in the Microsoft Knowledge Base:

Recipient Update Service required for each domain that contains mail-enabled objects

Each domain where mail-enabled objects will exist requires a Recipient Update Service. For additional information on creating additional Recipient Update Services, click the following article number to view the article in the Microsoft Knowledge Base:

Multiple mailboxes with Microsoft Windows NT Accounts in Exchange Server 5.5 need the NTDSNoMatch option

If you have multiple mailboxes with the same primary Microsoft Windows NT account, when you use the Active Directory Connector (ADC) to synchronize an Exchange Server 5.5 organization with Active Directory, you can control how the ADC matches mailboxes to Active Directory user accounts.

In Exchange 2000 Server, unlike Exchange Server 5.5, a mailbox is an attribute of an object in Active Directory, not an object itself. Therefore, each user object in Active Directory can only be matched to one mailbox. For every mailbox that exists in the information store, a matching object must exist in Active Directory. Because of this difference, you can retain the permissions that are set directly on the mailbox object, such as delegate and additional mailbox owner permissions.

By default, the ADC creates disabled users in Active Directory if the ADC cannot match a mailbox to a user. You can also set a custom attribute on the mailbox to force the ADC to create a new object instead of matching it to an existing user. To do so, set Custom Attribute 10 to NTDSNoMatch. If you set this attribute on resource-type mailboxes, the ADC can match a mailbox that does not have the NTDSNoMatch option set to the correct user account.

You can use the NTDSNoMatch utility to help perform this task. The NTDSNoMatch utility checks for mailboxes with the same primary Windows NT account, and then determines whether the mailbox is the primary mailbox or a resource mailbox. Then the NTDSNoMatch utility creates a comma-separated values (.csv) file that you can import to the Exchange Server 5.5 directory. This file automatically sets Custom Attribute 10 to NTDSNoMatch for the resource mailboxes.

To resolve this issue, use the NTDSNoMatch utility to prevent this issue from occurring. For additional information about how to use the NTDSNoMatch utility, click the following article number to view the article in the Microsoft Knowledge Base: To work around this issue after it has already occurred, make sure that the mailboxes have msExchMasterAccountSID attributes. For more information about how to work around this issue after it has already occurred, click the following article number to view the article in the Microsoft Knowledge Base: Knowledge Base article 278966 describes the cause of this issue (the mailbox does not have an msExchMasterAccountSID attribute) and another symptom of this issue (an event ID error message 1022 is logged in the Application event log). For additional information about another way to work around this issue after it has already occurred, click the following article number to view the article in the Microsoft Knowledge Base:

Exchange Server 5.5 mailbox owner rights are removed when you change the Active Directory Connection Agreement from one-way to two-way

Microsoft has confirmed that this is a problem in Exchange 2000 Server.