Article ID: 321318
Article Last Modified on 2/27/2007
APPLIES TO
- Microsoft Exchange 2000 Server Standard Edition
This article was previously published under Q321318
SUMMARY
This article provides a list of the top support issues for the Exchange 2000 Server and Exchange Server 2003 directory service.
MORE INFORMATION
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:
284934 An event ID 1029 message is logged after you install Exchange 2000 Server
290189 C1041722 error message occurs when you attempt to mount databases
314294 Exchange 2000 error messages are generated because of SeSecurityPrivilege right and Policytest issues
316709 "Store Could Not Be Mounted" error message when you try to mount Mailbox Store or Public Folder Store
281537 Description of the Policytest.exe utility
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:
303180 Active Directory Connector Connection Agreement requirements for mixed administrative groups
281223 Understanding Connection Agreements in Exchange
253841 Troubleshooting Active Directory Connector replication issues
296260 How to configure a two-way recipient Connection Agreement for Exchange Server 5.5 users
253665 How the Active Directory Connector uses block search to replicate changes
291385 Distribution lists are not replicating from Exchange Server 5.5 to Active Directory
266147 How to re-create a configuration Connection Agreement
268142 ADC does not replicate proxy addresses over inter-organizational Connection Agreement
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:
Event ID : 9176
Source : MSExchangeSA
Description : NSPI Proxy can contact Global Catalog (GCName) but it does not support the NSPI service. After a domain controller is promoted to a Global Catalog, the Global Catalog must be rebooted to support MAPI clients. Reboot (GCName) as soon as possible.
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:
304403 Exchange considerations for promoting a domain controller to a Global Catalog server
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:
823163 "Setup cannot locate a qualifying Global Catalog server" error message when you try to start the Information Store service
303186 The Information Store service may fail to start and an error message may be displayed
273428 Error message when you restart Exchange services if Global Catalog cannot be contacted
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:
- 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:
309622 Clients cannot browse the Global Address List after you apply the Q299687 Windows 2000 security hotfix
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:
297801 Troubleshooting Check Name errors
253770 Tasks performed by the Exchange Recipient Update Service
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:
288807 Troubleshooting the Recipient Update Service
319065 How to work with the Exchange Recipient Update Service
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:
286356 Exchange Recipient Update Service does not stamp proxy addresses in Exchange 2000 Server and in Exchange Server 2003
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:
319065 How to work with the Exchange Recipient Update Service
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:
274173 Documentation for the NTDSNoMatch utility
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:
278966 You cannot move or log on to an Exchange resource mailbox
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:
256862 How to correct mismatched accounts after Active Directory Connector replication
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.
Additional query words: RUS Config CA Directory Services NTDSNoMatch GC GAL
Keywords: kbinfo KB321318
