How to troubleshoot public folder replication problems in Exchange 2000 Server and in Exchange Server 2003

• Whether a computer sends the public folder replication messages
• Whether a computer receives the public folder replication messages
• Whether a computer responds to the received public folder replication messages

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 address

In 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.

1. Start the Active Directory Service Interface (ADSI) Edit tool. To do this, click Start, click Run, type adsiedit.msc in the Open box, and then click OK.
   
   Note ADSI Edit is included with the Microsoft Windows 2000 Server Support Tools and with the Microsoft Windows Server 2003 Support Tools. To install the Windows 2000 Support Tools, double-click Setup.exe in the Support\Tools folder on the Windows 2000 CD. To install the Windows Server 2003 Support Tools, double-click Suptools.msi in the Support\Tools folder on the Windows Server 2003 CD.
2. Connect to a domain controller if you are not already connected.
3. Note In this step, "contoso.com" is a placeholder for your domain name, and the other italic words are also placeholders.
   
   Expand Configuration Container [computername.contoso.com], expand CN=Configuration,DC=contoso,DC=com, expand CN=Services, expand CN=Microsoft Exchange, expand CN=OrganizationName, expand CN=Administrative Groups, expand CN=AdministrativeGroupName, expand CN=Servers, expand CN=ExchangeServerName, expand CN=InformationStore, and then click CN=First Storage Group.
4. In the right pane, right-click CN=Public Folder Store (EXCHANGESERVERNAME), and then click Properties.
5. In the Select which properties to view list, click Both.
6. In the Select a property to view list, click proxyAddresses.
7. In the Value(s) box, determine whether an e-mail address is assigned. Typically, the public folder store is stamped with a Simple Mail Transfer Protocol (SMTP) address that appears similar to the following:
   SMTP:ExchangeServerName-IS@contoso.com
8. In the Select a property to view list, click mail.
9. In the Value(s) box, verify the SMTP address is the same as the SMTP address that is displayed in step 7.

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:

Step 2: Increase diagnostics logging on public folder replication messages

Because 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:

• Replication Incoming Messages
• Replication Outgoing Messages
• Non-Delivery Reports

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:

• Replication Errors

Note When you increase diagnostic logging to Maximum, significantly more events are generated in the application log. Therefore, make sure that the application log is large enough to contain these events. When diagnostics logging is set to Maximum for the MSExchangeIS object, the Application Event Log may contain an event ID 3093 message that can be regarded as harmless. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
To increase diagnostic logging, follow these steps:

1. On the Exchange Server computer on which you experience the public folder replication problem, start Exchange System Manager.
2. Expand Administrative Groups, expand AdministrativeGroupName, and then expand Servers.
3. Right-click your Exchange Server computer, and then click Properties.
4. Click the Diagnostics Logging tab, and then expand MSExchangeIS in the Services list.
5. Press the CTRL key, and then click all the following items:
   Replication AD Updates
   Replication Incoming Messages
   Replication Outgoing Messages
   Non-Delivery Reports
   Replication Backfill
   Replication General
6. Click Maximum, and then click Apply.
7. Click Replication Errors, click Medium, click Apply, and then click OK.
8. Follow steps 2 through 7 on an Exchange public folder server on which you do not experience the public folder replication problem.

To troubleshoot public folder replication problems by using diagnostic logging, increase diagnostic logging on both the Exchange Server computer where you experience this problem and on an Exchange Server computer where you do not experience the public folder replication problem. This is because an outgoing public folder replication message from one Exchange Server computer corresponds to an incoming public folder replication message on another Exchange Server computer. Therefore, you can view the event logs from the two computers to match the outgoing public folder replication messages from one Exchange Server computer with the corresponding incoming public folder replication messages on the other Exchange Server computer.

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:

• Create
• Delete
• Modify

These change numbers are used by the Exchange Server replication engine to track public folder updates. Every modification to a folder is assigned a change number. When a public folder replicates an update to another Exchange Server computer, the change numbers are included with the update. The receiving Exchange Server computer uses these change numbers to determine whether the public folder update is a new change, and also to determine whether the public folder is missing any data. A set of change numbers is referred to as a CNSet.

The types of public folder replication messages that are delivered between public folder stores

The following types of messages are delivered between public folder stores.

Hierarchy replication messages

The following changes generate a hierarchy replication message:

• When a public folder is created
• When a public folder is removed
• When a public folder is modified
  
  Note This does not include the modification of the public folder content. This only includes the modification of the public folder itself. For example, when the public folder is renamed, when the public folder replica list is modified, when the public folder's display name is changed, when the public folder permissions are modified, when the public folder description is changed, and more. Any change to the public folder other than adding or removing content from that folder is replicated by a hierarchy replication message.

In this scenario, the following Event IDs appear in the Aplication log:

• Event ID: 3018: This is the outbound replication message. This event is logged on the computer where the hierarchy change was made. This computer then sends the hierarchy change message to all the other public folder server computers that are in the same top level hierarchy (TLH).
• Event ID: 3028: This is the inbound replication message. This event is logged on the computer that receives the outbound replication message (Event ID: 3018) from another computer.

Content replication messages

Content 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:

• Posting items to the public folder
• Modifying items in the public folder
• Removing items from the public folder

In this scenario, the following Event IDs appear in the Application log:

• Event ID: 3020: This is the outbound replication message. This event is logged on the computer that sends the public folder content to another computer.
• Event ID: 3030: This is the inbound replication message. This event is logged on the computer that receives the outbound replication message (Event ID: 3020) from another computer.

Backfill replication messages

Backfilling 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:

• Backfill Request
• Backfill Response

For a store to issue a backfill request, it must verify that it is not synchronized. The store determines this by detecting a gap in a public folder�s CNSet. This detection occurs through the typical replication process, or from a status message that is sent from another store. Backfill replication messages follow the same procedure for both public folder hierarchy backfill and public folder content backfill.

In this scenario, the following Event IDs appear in the application log:

Backfill request:

• Event ID: 3014: This is the outbound replication message. This event is logged on the computer that sends the backfill request message.
• Event ID: 3024: This is the inbound replication message. This event is logged on the computer that receives the backfill request message (Event ID: 3014) from another computer.

Backfill response

• Event ID: 3019: This is the outbound replication message. This event is logged on the computer that sends the backfill response message.
• Event ID: 3029: This is the inbound replication message. This event is logged on the computer that receives the backfill response message (Event ID: 3019) from another computer.

Status replication messages

Status 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:

• Event ID: 3017: This is the outbound replication message. This event is logged on the computer that sends the status replication message.
• Event ID: 3027: This is the inbound replication message. This event is logged on the computer that receives the status replication message (Event ID: 3017) from another computer.

Status request messages

A 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:

• A new replica of a public folder causes a status request message to be generated to obtain the public folder content.
• A new public folder store causes a status request message to be generated to obtain the public folder hierarchy. This behavior occurs because a new hierarchy folder has been created.

Additionally, status request messages are generated when a public folder replica is removed from a store.

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:

• Event ID: 3017: This is the outbound status request message. This event is logged on the computer that sends the status request message.
• Event ID: 3027: This is the inbound status request message. This event is logged on the computer that receives the status request message (Event ID: 3017) from another computer.

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 ID: 3039
Description:
Message ID: #-######
NDR recipients: 1 of 1
/O=Exchange_Organization_Name/OU=Exchange_Site_Name/CN=Configuration/cn=Servers/cn=Exchange_Server_Name/cn=MICROSOFT PUBLIC MDB
The recipient name is not recognized (0,0)

Event Source: MSExchangeIS Public
Event ID: 3040
Description:
An outgoing replication message resulted in a non-delivery report.
Type: 0x20
Message ID: #-######
Folder: (#-######) IPM_SUBTREE\Public_Folder_Name
NDR recipients: 1 of 1
/O=Exchange_Organization_Name/OU=Exchange_Site_Name/CN=Configuration/cn=Servers/cn=Exchange_Server_Name/cn=MICROSOFT PUBLIC MDB
The recipient name is not recognized (0,0)

Step 3: Determine whether the replication messages that are sent from one computer are received by another computer

Determine 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:

1. Start the Exchange System Manager tool.
2. Expand Administrative Groups, expand your administrative group, expand Servers, right-click your Exchange Server computer, and then click Properties.
3. On the General tab, click to select the Enable message tracking check box, and then click OK.
4. After you enable message tracking on both Exchange Server computers, create a new public folder or add content to an existing public folder, and then wait for the events to appear that indicate that the replication messages have been sent from the originating Exchange Server computer.
5. Start the Exchange System Manager tool, expand Tools, and then click Message Tracking Center.
6. In the Message Tracking Center on both the Exchange Server computers, track both the following message types:
   • Messages that are sent from the originating computer.
   • Messages that are sent to ExchangeServerNane-IS@DomainName.com where ExchangeServerNane-IS@DomainName.com is the name of the destination public folder store.
   To view information about the message, including information about whether the message was delivered successfully or not, double-click the message in the Message Tracking Center.

For additional information about message tracking, click the following article numbers to view the articles in the Microsoft Knowledge Base: If 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:

1. Start the Exchange System Manager tool.
2. Expand Administrative Groups, expand your administrative group, expand Servers, expand the Exchange Server computer that does not receive replication messages, expand Protocols, expand SMTP, right-click the SMTP virtual server, such as Default SMTP Virtual Server, and then click Properties.
3. Click the Access tab, and then click Authentication.
4. Click to select the Integrated Windows Authentication check box if it is not already selected, and then click OK two times.

If you notice outgoing replication messages after you turn up the diagnostics logging, verify the message tracking logs. The information that is displayed in the message tracking logs should help you determine your next steps in troubleshooting. However, if the following conditions are true, see the article number at the end of this list for more information:

• Message tracking was enabled before generating the replication message.
• You see the outgoing replication messages on the source server.
• You cannot locate any record of the outgoing replication messages being sent in the message tracking logs.

If these conditions are true, click the following article number to view the article in the Microsoft Knowledge Base:


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:


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 Source: MSExchangeIS Public Store
Event Category: Logons
Event ID: 1018
Description: NT AUTHORITY\SYSTEM was validated as NT AUTHORITY\SYSTEM and logged on to the Public Folder Store "First Storage Group\Public Folder Store (ServerName)" as an owner using administrator privileges.

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: Transport Delivering
Event ID: 9650
Description: Message delivery is being attempted. Internet Msg Id:<B1E7E7ADC8AB4049B6D77127293363C6012AA7@DomainName.com>, Submit Time: 04/02/2004 17:14:51.8308048, Recipient:/O=OrganizationName/OU=OrganizationalUnitName/cn=Configuration/cn=Servers/cn=ServerName/cn=Microsoft Public MDB, MDB:First Storage Group\Public Folder Store (ServerName).

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: Transport Delivering
Event ID: 9651
Description: Message was successfully delivered to <B1E7E7ADC8AB4049B6D77127293363C6012AA7@DomainName.com> on /O=OrganizationName/OU=OrganizationalUnitName/cn=Configuration/cn=Servers/cn=ServerName/cn=Microsoft Public MDB. Internet Msg Id:First Storage Group\Public Folder Store (ServerName).

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:

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: Replication Incoming Messages
Event ID: 3028
Description: An incoming replication message was processed.

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.

Step 4: Determine whether only new or modified public folder information is replicated successfully

When public folder information does not replicate correctly to other Exchange Server computers, the replication may work if you modify the folder contents or the folder settings. To troubleshoot this issue, you can try to modify the folder contents that are not replicated or modify the folder properties.

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 replication

For 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:

Public folder content replication

Microsoft 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: Note 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.

To configure public folder replication status request messages, follow these steps:

1. Follow the steps in Microsoft Knowledge Base article 321082 to configure the registry value for the public folder replication status request messages on an Exchange 2000 Server or Exchange Server 2003 computer that does have up-to-date public folder hierarchy information.
2. Dismount and then remount the public folder store on this Exchange Server where you configured this registry key. To do this, follow these steps:
   1. Start Exchange System Manager.
   2. Expand Servers, expand your Exchange Server computer, expand the storage group that contains the public folder store that you want to dismount, and then expand Public Folder Store (computername).
   3. Right-click Public Folder Store (computername), and then click Dismount Store.
   4. When you receive the following message, click Yes:
      Dismounting this store will make it inaccessible to any user.
      
      Do you want to continue?
   5. Right-click Public Folder Store (computername), and then click Mount Store.
   6. When you receive the following message, click OK:
      The store was successfully mounted.
3. Wait approximately 12 to 24 hours or longer, and then verify that the whole public folder hierarchy has replicated to the computer where you experience this problem.
   
   Important You must make sure that the public folder hierarchy has replicated successfully before you enable the registry key to replicate the public folder content. If the server receives a content replication message for a public folder that does not exist in its hierarchy, that content replication message is discarded.
4. After the public folder hierarchy has replicated successfully, follow the steps in the following Microsoft Knowledge Base article to configure the registry key to enable public folder content replication status messages on the server that currently does have the content:
   813629 Update to send status request messages in Exchange 2000 Server
5. Public folder content replication takes much longer to complete than public folder hierarchy replication. Wait at least 48 to 72 hours or longer, and then verify that the public folder content for all the public folders that have replicas on that public folder store has been replicated.

Note If you want to configure the public folder hierarchy status request message generation only, and not the content of the public folders, it is sufficient to configure only the registry key that is described in Microsoft Knowledge Base article 321082.

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.