Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
How to troubleshoot public folder replication problems in Exchange 2000 Server and in Exchange Server 2003
Article ID: 842273 - View products that this article applies to.
This article is a consolidation of the following previously available articles: 842273, 274301, 285844, 316760
You can store the same public folder content on many Microsoft Exchange Server computers by creating public folder replicas. By doing this, you can make the information that is contained in the public folders available to many users. However, when you create replicas of your public folders, Exchange Server must update the public folder replicas to make sure that they all contain the same data. Exchange Server performs this function by sending and by receiving public folder replication messages between the Exchange Server computers that hold a replica of the public folder. If public folder replication does not function correctly in your organization, you can use these replication messages to track all the following:
From the information that these replication messages contain, you may be able to determine the cause of the public folder replication problem.
This article describes specific suggestions and steps that you can use to troubleshoot public folder replication problems in Exchange Server.
Although this document deals primarily with Microsoft Exchange 2000 Server and Microsoft Exchange Server 2003, you can also apply much of this information to Microsoft Exchange Server 5.5. To successfully troubleshoot your public folder replication problem, we recommend that you first read this whole document before you perform any one of the troubleshooting steps that it contains.
Note The troubleshooting steps that this article contains appear in the order that you would typically perform them in.
Public Folder Guided Walk Through (GWT)
This walk through is a guide through the replication troubleshooting as outlined in this article. It is not meant to replace all of the data that helps you understand the public folder replication process, but rather quickly give you the steps you need to help find the root cause if there are problems with replication.
Step 1: Determine whether the public folder store has an e-mail addressIn Exchange 2000 Server and in Exchange Server 2003, all public folder replication is message-based. These public folder replication messages are sent from one public folder store to another public folder store. Public folder replication messages cannot be sent or delivered if the public folder store objects have not been stamped with proxy addresses by the Enterprise Configuration Recipient Update Service.
Typically, if this problem exists, the Exchange Server computer that contains the public folder store that is not stamped does not receive the public folder hierarchy from another Exchange Server computer. Therefore, the Exchange Server computer that contains the public folder store that is not stamped does not see a list of public folders, except for the public folders that have been created locally by using the Exchange System Manager tool. Without this public folder hierarchy, no public folder content can be replicated. To restate this, the public folder hierarchy must be replicated before the public folder content can be replicated.
To determine whether the public folder store has a proxy address assigned, view the value of the proxyAddresses attribute in the Active Directory directory service. To do this, follow these steps.
Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.
Note Because there are several versions of Microsoft Windows, the following steps may be different on your computer. If they are, see your product documentation to complete these steps.
If the proxyAddress value is incorrect or is missing, see the following Microsoft Knowledge Base articles for information about how to troubleshoot the Microsoft Exchange Recipient Update Service:
(http://support.microsoft.com/kb/286356/ )Exchange Recipient Update Service does not stamp proxy addresses in Exchange 2000 Server and in Exchange Server 2003
(http://support.microsoft.com/kb/322313/ )Exchange Recipient Update Service fails to process accounts and MSExchangeAL 8151 event logged
Step 2: Increase diagnostics logging on public folder replication messagesBecause public folder replication traffic is message-based, you can help troubleshoot a problem by increasing the diagnostic logging level for public folder replication messages. Typically, to troubleshoot public folder replication problems, increase the logging level to Maximum on the following diagnostic logging categories:
Note In Exchange Server 2003, also increase the logging level to Maximum on the Transport Delivering logging category and on the Logons logging category. Increase the logging level to Medium on the following diagnostic logging category:
(http://support.microsoft.com/kb/225090/ )XADM: 3093 PF Replication Error 0x8004010f Reading Property 0x67010003
To increase diagnostic logging, follow these steps:
You can use more than the event date and the event time to match these messages. The event descriptions contain public folder replication information including change numbers, folder names, and more. You can use this information to match the exact outgoing message from one public folder server computer with the corresponding incoming public folder replication message on another public folder server computer. Additionally, you can use the event description information to match the generated responses to the public folder replication messages.
All updates to a public folder are assigned change numbers (CNs). These updates include the following:
The types of public folder replication messages that are delivered between public folder storesThe following types of messages are delivered between public folder stores.
Hierarchy replication messagesThe following changes generate a hierarchy replication message:
Content replication messagesContent replication messages replicate content updates between replicas of individual public folders. A store only sends a content replication message to another store that holds a replica of the public folder. The following changes generate a content replication message:
Backfill replication messagesBackfilling is the process that a store that has missed replication updates uses to request a re-send of the missing data. There are two parts to the Backfill process:
In this scenario, the following Event IDs appear in the application log:
Status replication messagesStatus replication messages are sent by one store to another store. When the receiving store receives the status replication message, the receiving store can determine whether it is synchronized with the sending store.
In this scenario, the following Event IDs appear in the Application log:
Status request messagesA status request message is sent by one store to another store to trigger the replication of missing updates. Status request messages are less common in Exchange 2000 Server than in Exchange Server 5.5. Status request messages occur when a new replica of a public folder is created in a store. In this scenario, the store where you create the new public folder replica determines that it must be missing the corresponding public folder information, and that it must perform a backfill operation to obtain that public folder information. A hierarchy status request message is generated when you create a new public folder store on an Exchange Server computer.
The two occasions where a status request message is generated are very similar:
Note In Exchange Server 5.5, a status request message is generated for all replicas including the hierarchy every time the Microsoft Exchange Information Store service starts. You can configure this behavior by modifying a registry value. However, in Exchange 2000 Server, it was determined that these status request messages generated too much replication traffic. Particularly, when you have multiple databases and when you use a backup program that requires the Microsoft Exchange Information Store service to be stopped during the backup process. Because of this, Exchange 2000 Server does not generate status request messages when you start the Microsoft Exchange Information Store service.
The events that are generated to indicate a status request message are the same as for a status replication message. In this scenario, the following Event IDs appear in the Application log:
Exchange Server 5.5 Information
You can enable Diagnostics Logging on the Exchange Server 5.5 computer to log events when Exchange Server 5.5 public folder replication messages do not reach the Exchange 2000 Server or the Exchange Server 2003 public folder store. To log these events, set the Public Non-Delivery Reports (NDR) category of the MSExchangeIS service Diagnostics Logging level to Maximum. If the public folder replication messages are not being delivered, the following events will appear in the Event Viewer Application log:
Event Source: MSExchangeIS Public
Event Source: MSExchangeIS Public
Step 3: Determine whether the replication messages that are sent from one computer are received by another computerDetermine whether the replication messages that are sent from one Exchange Server computer are received by the other Exchange Server computer. To do this, track the replication messages by using the Message Tracking feature on both the sending Exchange Server computer and the receiving Exchange Server computer. To configure message tracking, follow these steps:
(http://support.microsoft.com/kb/246856/ )How to enable message tracking in Exchange 2000 Server
262162If the destination Exchange Server computer does not receive replication messages, verify that Integrated Windows authentication is enabled on the SMTP virtual server on that destination computer. To do this, follow these steps:
(http://support.microsoft.com/kb/262162/ )Using the Message Tracking Center to track a message
(http://support.microsoft.com/kb/828420/ )Public folder replication does not occur, and event ID 3020 is logged on a computer that is running Exchange 2000 or Exchange 2003
If outgoing messages are sent from the server and are received by the destination server, but the messages are not received by the information store, and if you receive an event ID 7004 message and an event ID 7010 message in the application event log with "504 need to authenticate first" in the description, there is either a permissions issue or an incorrect setting in the Default SMTP Virtual server. To resolve this issue, click the following article number to view the following article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/843106/ )How to troubleshoot the "504 need to authenticate first" SMTP protocol error
You may receive the following messages in the application event log that indicate replication messages have been received successfully on a computer that is running Exchange 2003:
Event Type: Success Audit
Event Type: Information
After you receive event ID 9651, you will see an event ID 3028 message indicating that a replication message has been processed. The event ID 3028 will look similar to the following:
If message tracking shows that the messages are held in the transport component categorizer or are held elsewhere in transport, focus your troubleshooting on a transport problem instead of on an information store problem or on a public folder replication problem.
Sometimes, public folder replication is successful, but only for new public folder items or only for modified public folder content. In this scenario, previous public folder information does not replicate to other Exchange Server computers successfully. This problem occurs even if you restart the destination Exchange Server computers. Typically, this problem occurs more frequently in a scenario where the receiving computer is running Exchange 2000 Server or Exchange Server 2003 and the sending computer is running Exchange Server 5.5.
Frequently, this problem is caused by the changed behaviors between Exchange 2000 Server and Exchange Server 5.5. In Exchange Server 5.5, a status request message for all replicas, including the whole public folder hierarchy, is generated every time that the Microsoft Exchange information store service is started. This is not the default behavior in Exchange 2000 Server. However, with Exchange 2000 Service Pack 3 (SP3) and later versions, you can configure Exchange 2000Server and Exchange Server 2003 to generate status request messages every time that the information store service starts.
Public folder hierarchy replicationFor additional information about how to configure Exchange 2000 Server and Exchange Server 2003 to automatically send a status request message for public folder hierarchy when the information store starts, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/321082/ )How to send replication status request messages in Exchange 2000 Server
Public folder content replicationMicrosoft Knowledge Base article 321082 contains steps only to generate status request messages for the public folder hierarchy. It does not contain steps to generate status request messages for the content in the public folders. For additional information about how to configure Exchange 2000 Server and Exchange Server 2003 to automatically send a status request message for public folder content when the information store starts, click the following article number to view the article in the Microsoft Knowledge Base:
813629Note The Replication Flags registry value causes a replication status message to be generated for every public folder. Between 6 and 12 hours after these status request messages are generated, a backfill operation starts for the public folder replicas that are not synchronized. Sometimes, the backfill process may take from 48 to 72 hours or longer to complete. The Enable Replication Messages At Startup registry value performs the same functionality for the public folder hierarchy. However, to configure the public folder content status request message generation in Exchange 2000 Server, you must configure the registry values that are described in both of these Microsoft Knowledge Base articles, dismount, and then remount the public folder store. The ability to enable status request messages for public folder content replication first became available with the September 2003 Exchange 2000 Server Post-Service Pack 3 Rollup.
(http://support.microsoft.com/kb/813629/ )Update to send status request messages in Exchange 2000 Server
To configure public folder replication status request messages, follow these steps:
However, make sure that all the folders in the hierarchy that have been successfully replicated contain all the content that they are supposed to have. If they do not have all the content that they are supposed to have after you wait 48 to 72 hours or longer, configure the registry key that is described in Microsoft Knowledge Base article 813629.
Article ID: 842273 - Last Review: November 8, 2012 - Revision: 13.0