Troubleshoot public folder replication for Exchange Server

What does this guide do?

Helps you diagnose and resolve issues with public folder replication for Exchange Server 2003, Exchange Server 2007 and Exchange Server 2010.

Who is it for?

Exchange admins who help resolve public folder replication issues.

How does it work?

We’ll begin by asking you to enable diagnostic logging and message tracking as a prerequisite. Then we’ll take you through a series of steps to resolve your public folder replication issues.

Estimated time of completion:

45-60 minutes.

Home page

To troubleshoot public folder replication for Exchange Server 2003 / 2007 / 2010, you’ll first need to enable diagnostic logging and message tracking.


What do you want to do?

Home page

To troubleshoot public folder replication for Exchange Server 2003 / 2007 / 2010, you’ll first need to enable diagnostic logging and message tracking.


What do you want to do?

Enable diagnostic logging

You’ll need to turn on diagnostic logging on all servers you’ll be working with. The steps for different Exchange version might be different, please select your Exchange version:

For Exchange 2007 and Exchange 2010

  1. Start the Exchange Management Shell.
  2. Run the following cmdlet to check current logging levels:
    Get-EventLogLevel | ? { $_.EventLevel -ne "Low" -AND $_.EventLevel -ne "Lowest" }
  3. To turn on logging, run the following cmdlets on all public folder servers you’re working with:
    Set-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication DS Updates" -Level ExpertSet-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication Incoming Messages" -Level ExpertSet-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication Outgoing Messages" -Level ExpertSet-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication NDRs" -Level ExpertSet-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication Backfill" -Level ExpertSet-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication General" -Level ExpertSet-EventLogLevel –Identity "MSExchangeIS\9001 Public\Replication Errors" -Level Medium
  4. On the Destination Server, increase Transport Logging by running these cmdlets:
    Set-EventLogLevel –Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium'Set-EventLogLevel –Identity "MSExchangeTransport\SmtpSend" -Level 'Medium'
  5. To reset logging levels:
    1. Open the Exchange Management Console.
    2. In the console tree, navigate to Server Configuration > Mailbox.
    3. In the Actions pane, select Manage Diagnostic Logging Properties.
    4. On the Manage Diagnostic Logging Properties page, choose the Exchange service you want to change the logging level for.
    5. Select the logging level you want, and then choose Configure. If you want to restore defaults, select Reset all services to default logging levels, and then choose Configure.
    6. On the Completion page, confirm that the process completed successfully. Tasks will show a status of Completed or Failed. If the task failed, review the summary for an explanation, and then choose Back to make any needed configuration changes.
    7. Choose Finish to complete the Manage Diagnostic Logging Level wizard.

For Exchange 2003

  1. Start Exchange System Manager, and then display the properties of the server you want to enable diagnostic logging on.
  2. Choose the Diagnostics Logging tab, and then expand MSExchangeIS in the Services list.
  3. Select Public Folder, press and hold Ctrl, and then click on each of the following items to select them all:
    • Replication AD Updates
    • Replication Incoming Messages
    • Replication Outgoing Messages
    • Non-Delivery Reports
    • Replication Backfill
    • Replication General
  4. Choose Maximum > Apply.
  5. Choose Replication Errors > Medium > Apply >OK.
  6. To increase logging on the destination server for the MSExchangeTransport service and set the SMTP level to Medium:
    1. Expand Servers, right-click Your Server Name, and then choose Properties.
    2. Choose the Diagnostics Logging tab, and then choose MSExchangeTransport under Services.
    3. Under Categories, choose SMTP.
    4. Under Logging Level, choose Medium.

What do you want to do next?

Enable message tracking

To turn on Message Tracking on all servers you’ll be working with. The steps for different Exchange version might be different, please select your Exchange version:

For Exchange 2007 and Exchange 2010

  1. Verify that message tracking is on by going to Exchange Management Shell and running the following cmdlet:
    Get-MailboxServer $env:computername | fl MessageTracking*
  2. You should see output similar to this:

    3221_image7
     

  3. Make sure both MessageTrackingLogEnabled and MessageTrackingLogSubjectLoggingEnabled are set to True.

  4. Make sure you note the MessageTrackingLogPath for the Log Location.

For Exchange 2003

  1. Start Exchange System Manager, and then display the properties of the server where you want to enable message tracking. Message tracking collects data such as To, From, and Date Sent.
  2. On the General tab, select the Enable message tracking check box.
  3. Select the Enable subject logging and display check box.
What do you want to do?
Troubleshoot Public Folder Replication

Select one folder that includes data on one server but not on another server, and make just that folder the focus of your troubleshooting efforts.In the following steps, the server that contains the data is called the “source” server; the server that does not contain the data is called the “destination” server.

Exchange 2007 and Exchange 2010

  1. In Exchange Management Console, select Public Folder Management Console under Toolbox.
  2. Right-click Public Folders, and then choose Connect To.
  3. Choose the server you want to connect to.

Exchange 2003

  1. Open the Exchange System Manager.
  2. Navigate to the Public Folder Hierarchy Object.
  3. Right-click Public Folders, and then choose Connect To.
  4. Choose the server you want to connect to.

Does the folder you’re looking for now appear in the hierarchy on both servers?

Replicate Always Interval; Application log Event ID 3018

Replicate Always Interval

Verify that the Replicate Always Interval value is set to 15 or fewer minutes on the source server. If necessary, adjust the setting. Please select your Exchange version to check the steps:

Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the following cmdlets and verify that ReplicationPeriod, ReplicationSchedule, and ReplicationMessageSize are set:
    Get-PublicFolderDatabase -Server $env:computername| fl Replication*
     
    3221_image10
     


  3. Make sure all public f databases have the same ReplicationMessageSize.

Next, verify that the folder in question is configured to use the store schedule. To do this:
  1. Start Exchange Management Console.
  2. Run the following cmdlet and verify Replicas and UseDatabaseReplicationSchedule are set:
    Get-PublicFolder  | fl *Replica*
    3221_image9
     

  3. If UseDatabaseReplicationSchedule is set to False, make sure ReplicationSchedule is set.

Exchange 2003

  1. Start Exchange System Manager.
  2. Expand your Administrative Groups container, and then choose the administrative group that contains the public folder server.
  3. Expand the Servers container, select the public folder database, and then choose Properties.
  4. On the Replication (Policy) tab, note the value in the Replication interval for always (minutes) box.
  5. If the value is not 15, type 15 in the Replication interval for always (minutes) box.
  6. Choose Apply, and then choose OK.
Next, verify that the folder you’re troubleshooting is configured to use the store schedule:
  1. Expand Public Folders, and then right-click the folder you’re troubleshooting.
  2. Choose Properties.
  3. On the Replication tab, choose Use public store schedule in the Public folder replication interval list.

Application log Event ID 3018

Create a new folder in the hierarchy on the source server, and then give the new folder a unique name you can remember.

We are using Test 1 as the name of our folder in this example.

Watch the application log on the source server for Event ID 3018, which indicates message type 0x2 and contains the name of the folder you created. You may have to wait up to 15 minutes for the event to be logged.

Event Type:Information
Event Source:MSExchangeIS Public Store
Event Category:Replication Outgoing Messages
Event ID:3018
Message:
An outgoing replication message was issued.
Type: 0x2
Message ID: <MessageID@Server.Domain.com>
Database "Storage Group\Public Folder"
CN min: 1-100, CN max: 1-200
RFIs:
1) FID: 1-1234, PFID: 1-1, Offset: 28
IPM_SUBTREE\Test 1

Do you see Event ID 3018?

Troubleshoot the source server; Event ID 3079 when the public folder database is mounted

Troubleshoot the source server

The source server is not generating outgoing hierarchy replication messages for new changes.We will first focus troubleshooting on the source server.

Event Type: Information
Event Source:
MSExchangeIS Public Store
Event Category:
Replication Outgoing Messages
Event ID:
3018
Message:
An outgoing replication message was issued.
Type: 0x2
Message ID: <MessageID@Server.Domain.com>
Database "Storage Group\Public Folder"
CN min: 1-100, CN max: 1-200
RFIs: 1
1) FID: 1-1234, PFID: 1-1, Offset: 28
IPM_SUBTREE\Test 1

Event ID 3079 when the public folder database is mounted

When the public folder database is mounted, Event ID 3079 is recorded in the Application log on the source server.Examine the Application log on the source server.

Event Type:Information
Event Source:
MSExchangeIS Public Store
Event Category:
Replication Errors
Event ID:
3079
Message:Unexpected replication thread error on database "<name>".
1) FID: 1-1234, PFID: 1-1, Offset: 28
IPM_SUBTREE\Test 1
Do you see Event ID 3079?
An unknown error has occurred

Sorry, we cannot resolve an unidentified issue using this guide. For more help resolving this issue, use the Exchange Self-Support Options. If you contact support about this issue, please tell them that the source server is not generating outbound hierarchy replication messages and there is no 3079 event when the database mounts.

EcReplStartup

Examine Event ID 3079 for the text: “EcReplStartup”.


Does Event ID 3079 contain “EcReplStartup”?

Replication thread is dying at startup

If Event ID 3079 contains “EcReplStartup,” this indicates that the replication thread is dying at startup. For more help to resolve this issue, use the Exchange Self-Support Options. If you contact support about this issue, please tell them that when the database mounts a 3079 event is logged, indicating that the replication thread died.


Is this information helpful?

Track the message in message tracking; Was the message delivered to the destination server?

Track the message in message tracking

On the source server, use the message ID from the description of Event ID 3018 to track the message in message tracking.

Event Type:
Information
Event Source:
MSExchangeIS Public Store
Event Category:
Replication Outgoing Message
Event ID:
3018
Message:
An outgoing replication message was issued.
Type: 0x2
Message ID: <MessageID@Server.Domain.com>
Database "Storage Group\Public Folder"

Was the message delivered to the destination server?

In the description of Event ID 3018, note the message ID, and then use message tracking to determine whether the message was delivered to the destination server. For example, the following message tracking excerpt includes the following text:

 “Message transferred to through SMTP”.

Message History

SMTP Store Driver: Message Submitted From StoreSMTP: Message Submitted to Advanced QueuingSMTP: Started Message Submission to Advanced QueueSMTP: Message Submitted to CategorizerSMTP: Message Categorized and Queued For RoutingSMTP: Message Routed and Queued For Remote DeliverySMTP: Started Outbound Transfer of Message Message transferred to through SMTP


Does message tracking indicate that the message was delivered to the destination server?

Transport issue; Does the message appear in message tracking?

Transport issue

The message was not delivered to the destination server, which indicates that a transport issue is causing the problem. Next, we’ll troubleshoot the transport process.

Does the message appear in message tracking?

Go to the source server and find the outgoing Message ID. Next, go to the Destination server and run message tracking to see if it received the message. Please select your Exchange version to check the steps to run message tracking.

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the following cmdlet:
    Get-MessageTrackingLog –MessageId

For Exchange 2003

  1. Start Exchange System Manager.
  2. In the console tree, expand Tools, and then choose Message Tracking Center.
  3. In the Server box, type the name of the server running Exchange 2003.
To browse a list of available servers, click Server, choose a server, and then click Add. You can search for a message that was sent from or delivered to a particular server. You are only required to specify the server name.

Did it receive the message?
Event ID 3028 on the destination server

On the destination server, examine the Application log for Event ID 3028, which contains the same message ID you noted from the description of Event ID 3018.

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category:
Replication Incoming Messages
Event ID:  3028
Message: An incoming replication message was issued.
Type: 0x2
Message ID: <MessageID@Server.Domain.com>
Database "Storage Group\Public Folder"
CN min: 5-100 CN max: 5-200
RFIs: 1
1) FID: 5-1234, PFID: 1-1, Offset: 28
IPM_SUBTREE\Test 1
Does the destination server Application log show Event ID 3028, and does this event contains the same message ID as Event ID 3018?
Event ID 7004 and Event ID 7010 on the destination server

On the destination server, examine the Application log in Event Viewer for events that resemble the following events.

Event Type:Error
Event Source:
MSExchangeTransport
Event Category:
SMTP Protocol
Event ID:
7004
Date:Date
Time:Time 
Users:Not available
Computer:Computer_Name
Description:This is an SMTP protocol error log for virtual server ID 1, connection #29. The remote host "E2k3server1.contoso.com", responded to the SMTP command "xexch50" with "504 Need to authenticate first ". The full command sent was "XEXCH50 2336 3 ". This will probably cause the connection to fail.
Event Type:
Error
Event Source:
MSExchangeTransport
Event Category:SMTP Protocol
Event ID:7010
Date:Date
Time: Time
User:Not available
Computer:Computer_Name
Description:This is an SMTP protocol log for virtual server ID 1, connection #30. The client at "6.5.2.4" sent a "xexch50" command, and the SMTP server responded with "504 Need to authenticate first ". The full command sent was "xexch50 1092 2". This will probably cause the connection to fail. These events indicate that the XEXCH50 protocol sink fired, but the exchange of the blobs failed between the servers that are listed in the events.
Do you see Event ID 7004 and Event ID 7010 on the destination server?
Resolve issue with the XEXCH50 command

The problem that you are experiencing may be caused by an XEXCH50 command issue.

To resolve the XEXCH50 command issue

  1. Verify that Integrated Windows Authentication is enabled on the SMTP virtual servers on the computers that are running Exchange Server in your organization. If Integrated Windows Authentication is not enabled:
    1. In Exchange System Manager, expand Administrative Groups, expand Servers, expand Exchange Server Name, expand Protocols, and then expand SMTP.
    2. Right-click the SMTP virtual server.
    3. Choose Properties, choose the Access tab, and then choose Authentication. Make sure that the Integrated Windows Authentication check box is selected.
  2. If Integrated Windows Authentication is enabled, but the events persist, the sending server in the 7004 event or in the 7010 event may lack or be denied the SendAs right on the receiving server. If the sending server and the receiving server are experiencing these events, the servers may lack the SendAs rights for each other. The SendAs right is not set explicitly. The SendAs right is typically inherited through membership in the Exchange Domain Servers (EDS) group. If the EDS does not have this DENY access control entry (ACE), the affected server may be nested in another group that has the DENY ACE, or the EDS may be nested in some other groups that have the DENY ACE. To run successfully, the XEXCH50 command has to have the SendAs right for servers in the Exchange organization.
  3. Determine whether you are using Transport Layer Security (TLS) and a security channel between servers in the Exchange organization. In this scenario, the STARTTLS transport event sinks occur before the AUTH command. The XEXCH50 command fails later in the session because the AUTH command is missing.
  4. If Exchange Protocol Security (EXPS) authentication is not working correctly between servers, the XEXCH50 command does not work. Events 1704 and 1706 indicate EXPS authentication failures in the Application log.
    Event Type:
    Warning
    Event Source:
    MSExchangeTransport Event
    Event Category:MTP Protocol
    Event ID:1706
    Description:EXPS is temporarily unable to provide protocol security with "..com". "CSessionContext::OnEXPSInNegotiate" called "HrServerNegotiateAuth" which failed with error code 0x8009030c ( i:\transmt\src\smtpsink\exps\expslib\context.cpp@1462 ). Data: 0000: 0c 03 09 80 ...?
    Note The description in Event ID 1706 includes error code 0x8009030c.
    Error code 0x8009030c is the SEC_E_LOGON_DENIED Hresult value. This code indicates that the account could not be logged on.
    These problems may be difficult to troubleshoot because the Microsoft Windows credentials of EXPS are required to pass this AUTH command. You can use various tools to troubleshoot the combination of Event ID 7004 and 7010; this includes the NLTEST tool and the NETDOM tool. Troubleshooting steps may include resetting computer account passwords.
    If you have a combination of Event ID 7004 and 7010 in the Application log as described earlier, and you cannot discover the source of the problem by using EXPS authentication, contact Microsoft Support Services.
    If you do not have the combination of Event ID 7004 and Event ID 7010 in the Application log, go to step 5.
  5. Check whether there is a firewall or an antivirus wall between servers in the Exchange organization. If a firewall is operating between servers in the organization, temporarily disable the firewall to determine whether it is causing the problem.

Did disabling the firewall resolve the issue?

Run isinteg –fix –test ReplState on the destination server; Tombstone because of a deletion

Run isinteg –fix –test ReplState on the destination server

Please choose your Exchange version to verify and adjust the ReplState setting with following steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Use the New-PublicFolderDatabaseRepairRequest cmdlet to detect and fix replication issues in the public folder database. Public folders on the public folder database can still be accessed while the request is running. However, the public folder currently being repaired is not available. After you begin the repair request, it can't be stopped unless you dismount the database.
  3. Run the following cmdlet:
    New-PublicFolderDatabaseRepairRequest -Database  -CorruptionType ReplState

For Exchange 2003

  1. On the destination server, install the hotfix described in Microsoft Knowledge Base article 925253.
  2. After the hotfix is installed, dismount the public folder database on the server, and then run the following command at a command prompt:
    cd C:\Program Files\Exchsrvr\binIsinteg –s  -fix -test ReplState
Next, run a test to determine whether the issue is resolved.

Tombstone because of a deletion

This indicates the folder is a tombstone because of a previous deletion that did not replicate. Go back to the source server and copy the folder to create a new folder with the same content, and then start over.

New folder visibility

Is the new folder visible in the hierarchy on the destination server?

Troubleshoot hierarchy backfill

At this point, we have verified that changes to the hierarchy are replicating correctly. We can now troubleshoot hierarchy backfill. To do this, run Synchronize Hierarchy on the destination server. Synchronize Hierarchy causes Event ID 3017 to occur. Event ID 3017 shows that a hierarchy status request (type 0x20) was sent to the source server.

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the Update-PublicFolderHierarchy -Server cmdlet.
  3. After you run Synchronize Hierarchy on the destination server, examine the Application log on the source server for the 3027 event and for the incoming status request.

For Exchange 2003

  1. Start Exchange System Manager.
  2. To run Synchronize Hierarchy, expand Folders, right-click the Public Folders object container, and then choose Synchronize Hierarchy.
  3. After you run Synchronize Hierarchy on the destination server, examine the Application log on the source server for event 3027 and for the incoming status request.

Is event 3027 in the Application log on the source server?

Retrieve the message ID and track the message

On the source server, locate Event ID 3017, and then note the message ID. Use message tracking to track the message ID to determine whether the message was delivered to the source server.


Does message tracking say the message was delivered to the source server?

Determine whether the public folder store on the source server has an email address

To determine whether the public folder store on the source server has a proxy address assigned, examine the value of the proxyAddresses attribute in Active Directory directory service.

To examine the value

Warning If you use the Active Directory Service Interface (ADSI) Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly change the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows Server and Exchange Server. Microsoft cannot guarantee that problems that occur if you incorrectly change Active Directory object attributes can be resolved. Change these attributes at your own risk.

Note Depending on your version 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 ADSI Edit tool by choosing Start >Run, typing adsiedit.msc in the Open box, and then choosing OK.
    Note ADSI Edit is included with Microsoft Windows 2000 Server Support Tools and with Windows Server 2003 Support Tools. To install Windows 2000 Support Tools, double-click Setup.exe in the Support\Tools folder on the Windows 2000 CD. To install 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.
    Note In this step, contoso.com is a placeholder for your domain name; other words in italics are placeholders for the indicated names.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 choose CN=First Storage Group.
  3. In the right pane, right-click CN=Public Folder Store (EXCHANGESERVERNAME), and then choose Properties.
  4. In the Select which properties to view list, choose both.
  5. In the Select a property to view list, choose proxyAddresses.
  6. In the Value(s) box, determine whether an email address is assigned. Typically, the public folder store has a Simple Mail Transfer Protocol (SMTP) address stamp similar to: SMTP:ExchangeServerName-IS@contoso.com
  7. In the Select a property to view list, choose mail.
  8. In the Value(s) box, verify the SMTP address is the same as the SMTP address displayed in step 7.

Does the source public store have an email address?

Event ID 3017 on the source server

In the Application log on the source server, immediately before Event ID 3027, locate Event ID 3017 for the same folder, which has type 0x10.


Do you see Event ID 3017 and type 0x10 for the same folder?

Event ID 3027 on the destination server

Event ID 3027 is the status response on the source server. In the Application log on the destination server, locate Event ID 3027 to examine the status response.


Do you see Event ID 3027 on the destination server?

Troubleshooting backfill

At this point, we know that the destination server is aware that data is missing. Now we focus on troubleshooting having the hierarchy backfill itself.

On the destination server, run Synchronize Hierarchy again, and then check the Application log on the destination server for Event ID 3014, which has type 0x8. Event ID 3014 is an outgoing backfill request for the hierarchy.


Do you see Event ID 3014 and type 0x8 on the destination server?

Event ID 3024 on the source server

Event ID 3024 is the incoming hierarchy backfill request.


Do you see Event ID 3024 on the source server?

Event ID 3019 on the source server

Event ID 3019, which has type 0x80000002, is the outgoing hierarchy backfill response on the source server.Examine the Application log on the source server for Event ID 3019.


Is Event ID 3019 on the Application log on the source server?

Event ID 3029

Event ID 3029 is the incoming hierarchy backfill response on the destination server.


Do you see Event ID 3029 in the Application log on the destination server?

Look for the folder in the hierarchy

On the destination server, look for the folder in the hierarchy.


Do you see the folder in the hierarchy on the destination server now?

Track the message ID from Event ID 3014

On the destination server, examine Event ID 3014 to obtain the message ID. Use message tracking to track the message ID.


Does message tracking indicate that the message was delivered to the source server?

Track the message ID from Event ID 3019

On the source server, locate Event ID 3019, and then note the message ID in the event. Use message tracking to track the message ID.


Does message tracking indicate that the message was delivered to the destination server?

Focus on content; Replicate Always Interval and Schedule; Create a new item on the source server

Focus on content

Because the folder appears in the hierarchy on both servers, this is probably not a hierarchy replication issue. Therefore, we will focus on troubleshooting content.

Replicate Always Interval and Schedule

Verify that the Replicate Always Interval value is set to 15 minutes or fewer on the source server.

To verify and adjust the setting on Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the following cmdlet and verify ReplicationPeriod, ReplicationSchedule, and ReplicationMessageSize are set:
    Get-PublicFolderDatabase -Server $env:computername| fl Replication*
    3221_image10
     

  3. Make sure all public folder databases have the same ReplicationMessageSize.

Next, verify that the folder in question is configured to use the store schedule. To do this:

  1. Start Exchange Management Console.
  2. Run the following cmdlet and verify Replicas and UseDatabaseReplicationSchedule are set:
    Get-PublicFolder  | fl *Replica*
    3221_image11
     

  3. If UseDatabaseReplicationSchedule is set to False, make sure that ReplicationSchedule is set.

To verify and adjust the setting on Exchange 2003

  1. Start Exchange System Manager.
  2. Expand your Administrative Groups container, and then choose the administrative group that contains the public folder server.
  3. Expand the Servers container, expand the source server, select the public folder database, and then choose Properties.
  4. On the Replication (Policy) tab, type 15 in the Replication interval for always (minutes) box.
  5. Choose Apply, and then choose OK.

Next, verify that the folder you’re working with is configured to use the store schedule. To do this:

  1. Expand Public Folders, and then right-click the folder you’re working with.
  2. Choose Properties.
  3. On the Replication tab, choose Use public store schedule in the Public folder replication interval list.

Create a new item on the source server

Create a new item in the public folder on the source server, and then watch the Application log for Event ID 3020.


Do you see Event ID 3020, and does it include the name of the folder you are testing and the name of the item we created?

Event ID 3030

On the destination server, examine the Application log for Event ID 3030.


Does the destination server Application log contain Event ID 3030 for the same folder and item?

Source server is not generating outgoing content messages for that folder; Event ID 3079 when the public folder database is mounted

Source server is not generating outgoing content messages for that folder

The source server is not generating outgoing content messages for that folder. We’ll focus our troubleshooting on the source server.

Event ID 3079 when the public folder database is mounted

On the source server, examine the Application log for Event ID 3079. Event ID 3079 occurs when the database is mounted, and it should contain the text: “EcReplStartup”. For example, Event ID 3079 should resemble the following table.

Event Type:
Information
Event Source:
MSExchangeIS Public Store
Event Category:
Replication Errors
Event ID:
3079
Message:
Unexpected replication thread error 0x3f0.
EcGetReplMsg
EcReplStartup
FReplAgent
Do you see Event ID 3079, and does it contain “EcReplStartup” when the database is mounted?
Run isinteg –fix –test ReplState; Event ID 3020

Run isinteg –fix –test ReplState on the destination server

Please choose your Exchange version to verify and adjust the ReplState setting with following steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Use the New-PublicFolderDatabaseRepairRequest cmdlet to detect and fix replication issues in the public folder database. Public folders on the public folder database can still be accessed while the request is running. However, the public folder currently being repaired is not available. After you begin the repair request, it can't be stopped unless you dismount the database.
  3. Run the following cmdlet:
    New-PublicFolderDatabaseRepairRequest -Database  -CorruptionType ReplState

For Exchange 2003

  1. On the destination server, install the hotfix described in Microsoft Knowledge Base article 925253.
  2. After the hotfix is installed, dismount the public folder database on the server, and then run the following command at a command prompt:
    cd C:\Program Files\Exchsrvr\binIsinteg –s  -fix -test ReplState

Event ID 3020

Create a new item in the public folder on the source server, and then examine the Application log for Event ID 3020.


Do you see Event ID 3020, and does it include the name of the folder you are testing and the name of the item you created?
Verify that the item is in the source folder on the destination server

On the destination server, look for the item you created on the source server, and make sure that it is in the destination folder.


Do you see the item in the folder on the destination server?

Troubleshoot content backfill

We have verified that changes to content are replicating. Next, we’ll troubleshoot content backfill.

To do this, run Synchronize Content on the destination server. This should cause the destination server to ask the source server for the missing data.

To run Synchronize Content in Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the following command:
    Update-PublicFolder -Server <DestinationServer>
  3. After you run Synchronize Hierarchy on the destination server, examine the Application log on the source server for event 3027 and for the incoming status request.

To run Synchronize Content in Exchange 2003

  1. Expand Public Folders, and then click the destination folder.
  2. In the right pane, click the Status tab.
  3. Right-click the destination server, and then click Synchronize Content.
After you run Synchronize Content on the destination server, examine the Application log for Event ID 3017 for the outgoing status request.

Is Event ID 3017 in the Application log on the destination server?
Run isinteg –fix –test ReplState

Please choose your Exchange version to verify and adjust the ReplState setting with following steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Use the New-PublicFolderDatabaseRepairRequest cmdlet to detect and fix replication issues in the public folder database. Public folders on the public folder database can still be accessed while the request is running, but you cannot access the public folder currently being repaired. After you begin the repair request, it can't be stopped unless you dismount the database.
  3. Run the following cmdlet:
    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState

For Exchange 2003

  1. On the destination server, install the hotfix described in Microsoft Knowledge Base article 925253.
  2. After the hotfix is installed, dismount the public folder database on the server, and then run the following command at a command prompt:
    cd C:\Program Files\Exchsrvr\binIsinteg –s -fix -test ReplState
  3. After the isinteg process finishes, change the replica list on the public folder on the source server. To do this, either add a replica to or remove a replica from any server. Choose Apply, reverse the change you just made, and then choose Apply again.
  4. Run Synchronize Content on the destination server again for the same folder.
  5. Examine the Application log for Event ID 3017 for the outgoing status request.

Is Event ID 3017 in the Application log on the destination server?

Event ID 3027

On the source server, examine the Application log for Event ID 3027 that has type 0x20.


Do you see Event ID 3027, and does it have type 0x20 on the source server?

Event ID 3017 on the source server

In the Application log on the source server, immediately before Event ID 3027, locate Event ID 3017 that has type 0x10 for the same folder.


Do you see Event ID 3017, and does it have type 0x10 for the same folder?

Do the servers have different age limits?

Typically, if the source server does not generate a status response, it means that the source server has no data that the other server does not also have.

One situation where servers can be in-sync without having identical content is if they have different age limits. If the destination server has already expired the items in question, it will not backfill the items again.

Be sure to check and make sure that the servers do not have different age limits. There are several types of limits:

Storage Quotas

Use database quota defaults

Select this check box to use the public folder database quota limits on which the public folder resides. If you do not select the defaults, the Issue warning at (KB), Prohibit post at (KB), and Maximum item size (KB) check boxes will become available.

Issue warning at (KB)

Select this check box to automatically warn public folder owners that the public folder is approaching its storage limit. To specify this limit, select the check box, and then specify the size of the public folder in kilobytes (KB) at which you want to prohibit posting. You can enter a value between 0 and 2,147,483,647 KB (2.1 terabytes).

Prohibit post at (KB)

Select this check box to prevent posting to the public folder after the size of the folder reaches the specified limit. To specify this limit, select the check box, and then specify the size of the public folder in KB at which you want to prohibit posting. You can enter a value between 0 and 2,147,483,647 KB (2.1 terabytes).

Maximum item size (KB)

Select this check box to limit the maximum size of items users can post to the public folder. To specify the size, select the check box, and then specify the maximum size of items in KB that users can post to the public folders. You can enter a value between 0 and 2,097,151 KB.

Deleted Item Retention

Use database retention defaults

Select this check box to use the public folder database item retention limits on the server where this public folder resides. If you do not select this check box, the Retain deleted items for (days) check box becomes available.

Retain deleted items for (days)

Select this check box to set the number of days deleted items are retained in a public folder. You can enter a value between 0 and 24,855 days.

Age Limits

Use database age defaults

Select this check box to use the public folder database age limits for the server where this public folder resides. If you do not select this check box, the Age limit for replicas (days) check box becomes available.

Age limit for replicas (days)

Select this check box to limit the age of the public folder. Use the corresponding text box to specify the age limit in days. Replicas of this public folder are automatically deleted when the age limit is exceeded. You can enter a value between 0 and 24,855 days.

Do the servers have different age limits?

  • If the answer is "yes," the content difference is by design. You do not have to continue troubleshooting. You can work around the issue by copying the items so they become new items in a new folder.
  • If the answer is "no," an unknown error has occurred. For more help to resolve this issue, use the Exchange Self-Support Options.
Event ID 3027 on the destination server

On the destination server, examine the Application log for Event ID 3027 event that has type 0x10.


Do you see Event ID 3027, and does it have type 0x10?

Focus on backfill

At this point, the destination server has calculated that some data is missing. Therefore, we will focus on backfill.

On the destination server, run Synchronize Content again on the destination folder. After you run Synchronize Content, Event ID 3016 is recorded in the Application log. Event ID 3016 has message type 0x8 that contains the name of the folder.


On the destination server, do you see Event ID 3016, and does it have message type 0x8 that contains the name of the folder?

Event ID 3026 on the source server

In response to Event ID 3016 on the destination server, you should see Event ID 3026 in the Application log on the source server.


On the source server, do you see Event ID 3026?

Event ID 3021 on the source server

In the Application log on the source server, immediately after Event ID 3026, you should see one or more incidents of Event ID 3021 that include message type 0x80000004 for the folder.


Do you see at least one Event ID 3021 that includes message type 0x80000004 for the folder?


Compare the number of Event ID 3021 to the number of Event ID 3031

Count the number of incidents of Event ID 3021 that are in the Application log on the source server. Then, count the number of incidents of Event ID 3031 that have message type 0x80000004 for the folder and that are in the Application log on the destination server.


Are there an equal number of Event ID 3021 incidents and Event ID 3031 incidents between the servers?

Locate the content in the folder on the destination server

On the destination server, look for the content that was synchronized from the source server to the same folder on the destination server.


Did you find the content in the same folder on the destination server?

Message may have been sent to a different source server

Examine Event ID 3016 to verify that the message was sent to the expected source server. On the destination server, examine Event ID 3016 to determine which source server should have received the message. If a different source server received the message, use that server as the new source server, and then examine the Application log on the new source server for Event ID 3016.

Event Type:
Information
Event Source:
MSExchangeIS Public Store
Event Category:
Replication Outgoing Messages
Event ID:
3016
Message:
Outgoing message type <value>
Message ID: <id>
Folder: <folder name>
Database "<name>".
CNSET: <value>
CNSET(FAI): <value>
Server: <server name>
Is the expected source server identified in Event ID 3016?

Outstanding backfill limit

By default, the Public Folders store can hold up to 50 outstanding backfill requests at one time. This is known as the Outstanding Backfill Limit (OBL). When 50 backfill requests are in the store array, those requests are made repeatedly until they are satisfied; no further new requests can be made until at least one request has been completed.

Each time a backfill request is satisfied, an opening occurs in the OBL and a new set of data can be requested. However, if all 50 requests experience issues and cannot be satisfied, no new openings occur, no new requests can be made, and replication cannot continue.

To determine whether Outstanding Backfill Limit is the cause of the problem, increase the OBL limit by one (1) on the destination server, and then examine the Application log for at least five minutes for an instance of Event ID 3016.

To increase the OBL limit by one (1) on the destination server

  1. Open the Registry Editor by choosing Start > Run, type regedit, and then choosing OK.
  2. Expand the following subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<Server_Name>\Public-<GUID>
  3. Right-click Public-<GUID>, point to New, and then choose DWORD Value.
  4. Type Replication Outstanding Backfill Limit, and then press Enter to name the new -subkey.
  5. Right-click Replication Outstanding Backfill Limit, and then choose Modify.
  6. In the Value data box, type 51, and then choose OK.
  7. Close the Registry Editor.
  8. Restart the Microsoft Exchange Information Store service on the Exchange 2003 server. To do this:
    • Choose Start, point to Administrative Tools, and then choose Services.
    • In the Services list, choose Microsoft Exchange Information Store, and then choose Restart.
If Event ID 3016 is recorded for some other folder, troubleshoot using that folder instead.

Do you see Event ID 3016 for some other folder?
Track the message that is identified in Event ID 3020

On the source server, use message tracking to track the message is identified in Event ID 3020.


Does message tracking indicate that the message was delivered to the destination server?

Troubleshoot the XEXCH50 command

To troubleshoot the XEXCH50 command, increase logging on the destination server for the MSExchangeTransport service, and set the SMTP protocol level to medium.

To verify and adjust the SMTP protocol level setting, please choose your Exchange version to check the steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Use the Set-EventLogLevel –Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium' and Set-EventLogLevel –Identity "MSExchangeTransport\SmtpSend" -Level 'Medium' cmdlets to turn on event logging for the SMTP.
  3. Use the Resume-PublicFolderReplication cmdlet to start public folder replication for the entire organization.

For Exchange 2003

Next, examine the Application log in Event Viewer for events that resemble the following:

Event Type:
Error
Event Source:
MSExchangeTransport
Event Category:
SMTP Protocol
Event ID:
7004
Date:Date
Time:Time
 User:Not available
Computer:Computer_Name
Description:This is an SMTP protocol error log for virtual server ID 1, connection #29. The remote host "E2k3server1.contoso.com" responded to the SMTP command "xexch50" with "504 Need to authenticate first. "The full command sent was "XEXCH50 2336 3 ". This will probably cause the connection to fail.
Event Type:
 Error
Event Source:
 MSExchangeTransport
Event Category:
SMTP Protocol
Event ID:
7010
Date:Date
Time:Time
User:Not available
Computer:Computer_Name
Description:This is an SMTP protocol log for virtual server ID 1, connection #30. The client at "6.5.2.4" sent a "xexch50" command, and the SMTP server responded with "504 Need to authenticate first." The full command sent was "xexch50 1092 2". This will probably cause the connection to fail. These events indicate that the XEXCH50 protocol sink fired, but the exchange of the blobs failed between the servers that are listed in the events.
Do you see Event ID 7004 and Event ID 7010 on the destination server?
Run isinteg –fix –test ReplState

Please choose your Exchange version to verify and adjust the ReplState setting with following steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Use the New-PublicFolderDatabaseRepairRequest cmdlet to detect and fix replication issues in the public folder database. Public folders on the public folder database can still be accessed while the request is running, but you cannot access the public folder currently being repaired. After you begin the repair request, it can't be stopped unless you dismount the database.
  3. Run the following cmdlet:
    New-PublicFolderDatabaseRepairRequest -Database -CorruptionType ReplState

For Exchange 2003

  1. On the destination server, install the hotfix described in Microsoft Knowledge Base article 925253.
  2. After the hotfix is installed, dismount the public folder database on the server, and then run the following command at a command prompt:
    cd C:\Program Files\Exchsrvr\binIsinteg –s -fix -test ReplState
  3. After the isinteg process is finished:
    1. Change the replica list on the public folder on the destination server. To do this, add a replica to or remove a replica from any server. Choose Apply, reverse the change you just made, and then choose Apply again.
    2. On the source server, create a new item.
    3. Examine the Application log on the source server for Event ID 3020.
    4. Examine the Application log on the destination server for Event ID 3030.
Do you see Event ID 3030 in the Application log on the destination server?
Conclusion

Congratulations! Your Public Folder Replication for Exchange Server 2003 issue is resolved.

An unknown error has occurred

Sorry, we cannot resolve an unidentified issue by using this guide. For more help to resolve this issue, use the Exchange Self-Support Options. If you contact support regarding this issue, please tell them that the source server is not generating outbound hierarchy replication messages. There is a 3079 event when the database mounts, but the event does not contain EcReplStartup.

Replication Receive Queue Size in Performance Monitor

Public folder replication messages are received by SMTP, categorized and handed to the local SMTP queue. The messages are then submitted to the Public Folder store. Once messages are submitted to the Public Folder store, they are put in the Replication Receive Queue. The messages in the Replication Receive Queue are then processed and changes are performed on the appropriate public folder. The Replication Receive Queue Size performance counter indicates the number of public folder replication messages waiting to be processed.

The larger the replication queue becomes, the more out of synchronization the content in the folders can become. When replication queues grow, there is an increased load on resources as the messages in the replication queue are processed. Also, growing replication queues indicate that public folder content on the server is outdated.

No action is required in the two instances where growth in the Replication Receive Queue is expected and can be planned for:

  • On a newly introduced public folder server, growth in the Replication Receive Queue can be caused by the expected initial backfill replication.
  • If site consolidation or other major changes in the Exchange topology are occurring, it is expected that there will be lots of replication as the content is moved.

For existing, steady state servers where public folder replicas are not being changed in bulk, this error may indicate:

  • Server resource performance bottlenecks such as disk, CPU, network, or memory. If there is a resource bottleneck on the server, the Store.exe process will not be able to process the replication messages fast enough and a queue will grow.
  • The public folder replication interval is too short for the replication to complete before the next replication cycle starts.

To resolve this error:

  • Monitor the MSExchangeIS Public\Replication Receive Queue Size until it shows that replication is completed before the next replication cycle starts.
  • Consider reducing the total number of replicas in the Exchange organization to reduce the volume of replication traffic required.
Pause replication

Pause replication of public folders and let the queues drain or call support.

To pause replication

  1. Start Exchange Management Console.
  2. Use the Suspend-PublicFolderReplication cmdlet to stop public folder replication for the entire organization.
  3. Monitor the Transport Queues by running Get-TransportServer | Get-Queue. Once the queue is reduced, you can resume replication.
  4. Use the Resume-PublicFolderReplication cmdlet to restart public folder replication for the entire organization.

Sorry, we cannot resolve an unidentified issue by using this guide. For more help to resolve this issue, use the Exchange Self-Support Options. If you contact support about this issue, please tell them that Replication is Paused and you are waiting for the queues to reduce.  

Update the public folder hierarchy

Update the public folder hierarchy and see if the message delivers. Please choose your Exchange version to check the steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the Update-PublicFolderHierarchy -Server <SourceServer> cmdlet.
  3. After you run Synchronize Hierarchy on the destination server, examine the Application log on the source server for event 3027 and for the incoming status request.

For Exchange 2003

  1. Start Exchange System Manager.
  2. To run Synchronize Hierarchy in Exchange System Manager, expand Folders, right-click the Public Folders object container, and then choose Synchronize Hierarchy.
  3. After you run Synchronize Hierarchy on the destination server, examine the Application log on the source server for event 3027 and for the incoming status request.

Did that work?

An unknown error has occurred

Sorry, we cannot resolve an unidentified issue using this guide. For more help to resolve this issue, use the Exchange Self-Support Options. If you contact support about this issue, please tell them that hierarchy is failing. Message tracking indicates that the hierarchy message was delivered, but the target server did not log the incoming hierarchy message.

Looking for the folder ID (FID) (Isolate?)

Does the Event ID 3028 event show the FID but not the folder’s name?

An unknown error has occurred

Sorry, we cannot resolve an unidentified issue using this guide. For more help to resolve this issue, use the Exchange Self-Support Options.

Tombstone because of a deletion

This indicates the folder is a tombstone because of a previous deletion that did not replicate. Go back to the source server and copy the folder to create a new folder with the same content, and then start over.


Is this information helpful?

An unknown transport error has occurred

Sorry, we cannot resolve an unidentified issue using this guide. For more help to resolve this issue, use the Exchange Self-Support Options.

Does the message appear in message tracking?

Go to the source server and find the outgoing Message ID. Next, go to the Destination server and run message tracking to see if it received the message. Please select your Exchange version to check the steps to run message tracking.

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Run the following cmdlet:
    Get-MessageTrackingLog –MessageId

For Exchange 2003

  1. Start Exchange System Manager.
  2. In the console tree, expand Tools, and then choose Message Tracking Center.
  3. In the Server box, type the name of the server running Exchange 2003.
To browse a list of available servers, click Server, choose a server, and then click Add. You can search for a message that was sent from or delivered to a particular server. You are only required to specify the server name.

Did it receive the message?
Does performance monitor show a large number of messages queued for submission?

Open Performance Monitor

Add Counter MSExchangeIS Public\Replication Receive Queue and monitor the size of the queue.

If you need to understand more about performance monitor you can go here: Performance Monitoring Getting Started Guide


Does performance monitor show a large number of messages queued for submission?

Check services
  1. Choose Start >Run.
  2. Type services.msc in the box.
  3. Find MSExchangeTransport and verify it is started

If you have PowerShell, open it and run the following cmdlet:

Get-Service MSExchangeTransport


Is the Transport Service Running?

An unknown error has occurred

Sorry, we cannot resolve an unidentified issue using this guide. For more help to resolve this issue, use the Exchange Self-Support Options. If you contact support about this issue, please tell them that the server is generating outbound hierarchy messages, but those messages do not appear in message tracking, and nothing is being queued for submission.

Does the 3030 event show the message ID (MID) of the item but not the subject?

Does the 3030 event show the MID of the item, but not the subject?

Tombstone

This is usually the result of a tombstone because of a message deletion that has not replicated. You can copy the messages within the folder to create new messages, or copy the entire folder.


Is this information helpful?

Track the Event ID 3027

Track the 3027 to see how far it got. If it didn’t leave the source server, check the Messages Queued For Submission performance counter under MSExchangeIS Public to see if the outbound messages are stuck in the public store.


Is this information helpful?

Possible ReplState problem

It is possible that this issue could be an XEXCH50 problem or a ReplState issue. Before we continue, let’s verify that SMTP logging is enabled.

Please choose your Exchange version to verify and adjust the ReplState setting with following steps:

For Exchange 2007 and Exchange 2010

  1. Start Exchange Management Console.
  2. Use the Set-EventLogLevel –Identity "MSExchangeTransport\SmtpReceive" -Level 'Medium' and Set-EventLogLevel –Identity "MSExchangeTransport\SmtpSend" -Level 'Medium' cmdlets to turn on event logging on the SMTP.
  3. Use the Resume-PublicFolderReplication cmdlet to start public folder replication for the entire organization.

For Exchange 2003

  1. Start Exchange System Manager.
  2. Expand Servers, right-click Your_ Server Name, and then choose Properties.
  3. Choose the Diagnostics Logging tab, and then choose MSExchangeTransport under Services.
  4. Under Categories, choose SMTP.
  5. Under Logging Level, choose Medium.

What’s your Exchange version?

One or more of the messages was lost in transport

If the number of 3031 events on the destination server is fewer than the number of 3021 events on the source server, one or more of the messages was lost in transport. To troubleshoot the message loss, identify the message ID of the messages which were not replicated.

To do this, examine the Application log on the source server. Then, use message tracking to track the messages and troubleshoot the issue.


Are there any Exchange 2007 or 2010 servers in the path of that message?

Did that resolve the issue?

Is your issue now resolved?

Exchange 2007 and Exchange 2010 in the path

The most common reason for a lost content backfill response on Exchange 2007 or Exchange 2010 is a store driver failure. For instance, a backfill response will be sent to an Exchange 2007 server, but if you look at the application log on the 2007 side, you never see the incoming replication event. Message tracking shows that the replication message got to the hub transport server and then failed in the store driver.

The first step for troubleshooting is to track the message and see where it failed.

Usually, the hub transport server will log an event 1020 that describes the problem with that particular content. After tracking the message and determining which hub transport server it failed on, please check 1020 event with source MSExchange Store Driver on that hub transport server.


Do you see a 1020 event with source MSExchange Store Driver on that hub transport server?

Exchange 2007 and Exchange 2010 in the path

Please follow the instructions given in Microsoft Knowledge Base Article 2487271.

For more help resolving this issue, use the Exchange Self-Support Options. If you contact support about this issue, please tell them there is an Empty Servers Container.


Is this information helpful?

Exchange 2007 and Exchange 2010 in the path

Does it contain the error “The message content has become corrupted.”?

Exchange 2007 and Exchange 2010 in the path

This message is usually because of corrupt TNEF. If this is a hybrid environment, apply Exchange 2013 CU6 to prevent new corrupt messages, and delete the old ones. To identify the corrupt items, continue with the steps below.

To identify which items are corrupted:

  1. Reduce the replication message size to 1k on the source server.
  2. On the destination, force another backfill request with Synchronize Content or Update-PublicFolder.
  3. You’ll now see one backfill response (event 3021) per item in the folder on the source server. The application log may fill up with backfill responses if the folder contains a lot of items. Once the 3021 activity has calmed down, clear the application log on the source server and force another backfill request. Since all of the good items already replicated in the last round of backfills, the only new items you should see in the new event 3021’s should be the corrupted items.

Now you should have one backfill response (3021) for each corrupted item in the application log on the source server, and one 1020 event for each corrupted item in the application log on the hub transport server. Since you now know which items are corrupted (because you can read the item subjects in the 3021 events), you can delete those items or try to fix them.

See also Bill Long’s blog article about "Fixing Public Folder Replication Errors From Exchange 2003 to Exchange 2007 or 2010".


Did that resolve the issue?

Exchange 2007 and Exchange 2010 in the path

This is some other type of corrupted item. To identify which items are corrupted:

  1. Reduce the replication message size to 1k on the source server.
  2. On the destination, force another backfill request with synchronize content or Update Public Folder.
  3. You’ll now see one backfill response (event 3021) per item in the folder on the source server. The application log may fill up with backfill responses if the folder contains a lot of items. Once the 3021 activity has calmed down, clear the application log on the source server and force another backfill request. Since all of the good items already replicated in the last round of backfills, the only new items you should see in the new event 3021 should be the corrupted items.

Now you should have one backfill response (3021 event) for each corrupted item in the application log on the source server, and one 1020 event for each corrupted item in the application log on the hub transport server. Since you now know which items are corrupted (because you can read the item subjects in the 3021 events), you can delete them or try to fix them.

See also Bill Long’s blog article about "Fixing Public Folder Replication Errors From Exchange 2003 to Exchange 2007 or 2010."


Is your issue now resolved?

Application log Event ID 3018

Create a new folder in the hierarchy on the source server, and then give the new folder a unique name you can remember.

We are using Test 1 as the name of our folder in this example.

Watch the application log on the source server for Event ID 3018, which indicates message type 0x2 and contains the name of the folder you created. You may have to wait up to 15 minutes for the event to be logged.

Event Type:
Information
Event Source:
MSExchangeIS Public Store
Event Category:
Replication Outgoing Messages
Event ID:
3018
Message:
An outgoing replication message was issued.
Type: 0x2
Message ID: <MessageID@Server.Domain.com>
Database "Storage Group\Public Folder"
CN min: 1-100, CN max: 1-200
RFIs: 1
1) FID: 1-1234, PFID: 1-1, Offset: 28
IPM_SUBTREE\Test 1

Do you see Event ID 3018?

Congratulations!

Congratulations! Your Public Folder Replication for Exchange Server issue is resolved.

Still having problems?

Sorry, we cannot resolve this issue by using this guide.

內容

文章識別碼:10042 - 最後檢閱時間:2016年4月14日 - 修訂: 117

意見反應