KnowledgeBase Archive

An Archive of Early Microsoft KnowledgeBase Articles

View on GitHub

Q169205: XADM: Repercussions of Deleting Public Folder Replication Messag

Article: Q169205
Product(s): Microsoft Exchange
Version(s): winnt:5.0,5.5
Operating System(s): 
Keyword(s): exc5 exc55
Last Modified: 16-OCT-1999

-------------------------------------------------------------------------------
The information in this article applies to:

- Microsoft Exchange Server, versions 5.0, 5.5 
-------------------------------------------------------------------------------

SUMMARY
=======

This article explains the repercussions of deleting public folder replication
messages from the MTA queues using the Exchange Administrator program or the
Mtacheck.exe utility with the /rp option.

MORE INFORMATION
================

To resolve a backlogged MTA, it may be necessary to remove all public folder
replication messages in the MTA queues. When this is done, the result may be the
generation of even more public folder replication messages, which may exacerbate
the MTA problem.

During normal public folder replication, when a change is made to one of the
replicas of a public folder, the change is sent out to all the other servers
that have replicas of that public folder. This change is sent out as a single
mail message addressed to the public information store on each server, in each
of the other sites in the organization. The MTA is responsible for routing this
message to the correct destinations.

When public folder replication messages in the MTA queues are removed, these
regular public folder messages are not received by the destination servers.
Eventually, the other servers will generate backfill request messages asking the
server with the changes to send them the changes. These changes are now
individually sent to each server requesting a backfill, and in turn, the number
of public folder replication messages generated are larger.

Consider a Microsoft Exchange organization with 20 sites with public folder
replicas on one server in each site. If a public folder on a server in Site 1 is
modified, public folder replication messages are sent out to all other servers
in the other sites that contain a replica of this public folder.

Now, suppose the MTA on the bridgehead server in Site 1 is backlogged and all the
public folder replication messages in the MTA queues to the other sites are
removed. When this is done, the public folder replication messages containing
the changes to the public folder in Site never reach the other sites. This
causes the servers in the other sites to generate Backfill request messages
requesting these changes. In response to these Backfill messages, another
message is sent to each server requesting the changes. This results in an
individual message being sent to each server in the other sites containing a
replica of the public folder. As a result, the MTA queues to the other sites
will now have 19 new messages instead of the one original message which was
deleted from the queue. This is in addition to the traffic generated by the
Backfill messages from each of the other servers.

In a large organization with several sites and several servers in each site, the
amount of additional traffic caused by public folder backfill requests can be
significant. Therefore, you should use caution when you use the MTACHECK utility
with the /rp option or delete public folder replication messages.

Additional query words:

======================================================================
Keywords          : exc5 exc55 
Technology        : kbExchangeSearch kbExchange500 kbExchange550 kbZNotKeyword2
Version           : winnt:5.0,5.5
Issue type        : kbinfo

=============================================================================

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.