DOCUMENT:Q184244 22-DEC-1999 [exchange] TITLE :XADM: Inbound Intersite Replication Fails With No Errors Logged PRODUCT :Microsoft Exchange PROD/VER:winnt:4.0,5.0 OPER/SYS: KEYWORDS:exc4 exc5 ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Exchange Server, versions 4.0, 5.0 ------------------------------------------------------------------------------- SYMPTOMS ======== Intersite directory replication fails without any errors logged in the event log. This problem occurs even if the following recommended Directory Service logging levels are enabled on both bridgeheads: Replication = MAX Internal Processing = MIN CAUSE ===== An area of memory holding a "USN" value is prematurely freed. Afterwards, that area of memory is dereferenced again. If that memory has been overwritten, a comparison fails, which results in the replication update message returned from the target bridgehead being discarded as invalid. Under normal operating conditions, the likelihood that the memory address will be overwritten before it is dereferenced is miniscule. However, this failure is almost guaranteed when Windows NT runs under certain memory diagnostics and debugging modes. These modes are enabled by setting specific registry keys, and are typically only enabled during server debugging or software performance profiling. STATUS ====== Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 4.0. This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 4.0. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces): S E R V P A C K Microsoft has confirmed this to be a problem in Microsoft Exchange Server version 5.0. This problem has been corrected in the latest U.S. Service Pack for Microsoft Exchange Server version 5.0. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces): S E R V P A C K MORE INFORMATION ================ A normal intersite replication sequence involves the repetition of the following: a. The originating site submits (small) messages requesting updates for various naming contexts from a target replication bridgehead. b. The target site responds with (larger) update messages to those contexts. c. The originating site receives these messages with updates and processes them. This sequence is repeated until there are no more updates to return for a given context. This can be traced and observed in the Application Event log by enabling the following Directory Service logging levels on both bridgeheads: Replication = MAX Internal Processing = MIN When you make a directed request for an update (new and modified objects) of a remote site context from the originating bridgehead server to the target bridgehead responsible for providing that site context, the following is revealed in the Windows NT Application Event Log: NOTE: A separate update request message is generated from the originating bridgehead for the Site, the Site-configuration, and perhaps the Address Book Views contexts that will be updated. Part A: From the requesting site's log: Make request for site context. 2005 (...logged when forcing an update request via Admin UI) Calling dra_replica_synchronize: NC = '/o=/ou=', destination DS = '', source DS = '', flags = 0x00004000. 1068 (...also logged for intrasite replication) Internal event: The directory replication agent (DRA) was asked to synchronize replica of /o=/ou= from directory ID with options 4000. 1100 During intersite replication, the directory replication agent (DRA) successfully submitted a message with a length of 120 while requesting updates in naming context /o=/ou= from the directory at . ("length of xxx" for update requests can vary, but will be small) 1058 (...also logged for intrasite replication) Internal event: The directory replication agent (DRA) call completed successfully. 2021 (...logged when forcing an update request via Admin UI) An update of the replica of naming context '/o=/ou=' was requested on server ''. Make request for site-configuration context (same sequence again). 2005 Calling dra_replica_synchronize: NC = '/o=/ou=/cn=Configuration', destination DS = 'local servername>', source DS = '', flags = 0x00004000. 1068 Internal event: The directory replication agent (DRA) was asked to synchronize replica of... 1100 During intersite replication, the directory replication agent (DRA) successfully submitted a message with a length of 144 while requesting updates in naming context /o=/ou=/cn=Configuration from the directory at . ("length of xxx" for update requests can vary, but will be small) 1058 Internal event: The directory replication agent (DRA) call completed successfully. 2021 An update of the replica of naming context '/o=/ou=/cn=Configuration' was requested on server ''. The MTA moves these request messages between originating and target bridgeheads. Part B: From the target site's log: The request is received at the target bridgehead. 1099 During intersite replication, the directory replication agent (DRA) received a message with a length of 120 from the directory at . Received an X.400 MTS Identifier of c=US;a= ;p=Microsoft;l=RICKBOLLT166-980403162551Z-29. ("Message length" is the same as what was logged in originator's 1100 event. MTS-ID established for possible message tracking.) 1070 Internal event: Directory asked the directory replication agent (DRA) to get changes from naming context /o=/ou= starting at update sequence number (USN) 97747 with flags a80 and sensitivity 100. ("Starting USN" established. Expect objects under the requested context with a "USN-Source" greater than this USN to be returned). Collect first 512 object changes under requested "site context" and compress message (if necessary). 1071 Internal event: The directory replication agent (DRA) got changes returning 512 objects and entries up to update sequence number (USN) . (USN numbers aren't necessarily sequential within a given context, so the USN returned is not necessarily "USNrequested + 512"). 1199 The replication message has been compressed from 454758 bytes to 102014 bytes. Submit reply to request for updates for site context. 1101 During intersite replication, the directory replication agent (DRA) successfully submitted a message with a length of 102014 while updating the replica of naming context /o=/ou= on the directory at . Received an X.400 MTS Identifier of c=US;a= ;p=Microsoft;l=RICKBOL66980403113339CK004500. ("Message length" will match the originator's 1100 event, below. MTS- ID established for possible message tracking.) Receive request for updates site-configuration context (same sequence as above). 1099 During intersite replication, the directory replication agent (DRA) received a message with a length of 144 from the directory at . Received an X.400 MTS Identifier of c=US;a= ;p=Microsoft;l=RICKBOLLT166-980403162552Z-30. 1070 Internal event: Directory asked the directory replication agent (DRA) to get changes from naming context /o=/ou=/cn=Configuration starting at update sequence number (USN) 97794 with flags a80 and sensitivity 100. ("Starting USN" established. Expect objects under the requested context with a USN-Source greater than this USN to be returned). Collect first 512 object changes under requested "site-configuration context" and compress message (if necessary). 1071 Internal event: The directory replication agent (DRA) got changes returning 512 objects and entries up to update sequence number (USN) . 1199 The replication message has been compressed from 580483 bytes to 210486 bytes. Submit reply to request for updates for site context. 1101 During intersite replication, the directory replication agent (DRA) successfully submitted a message with a length of 210486 while updating the replica of naming context /o=/ou=/cn=Configuration on the directory at . Received an X.400 MTS Identifier of c=US;a= ;p=Microsoft;l=RICKBOL66980403113340CL004500. Larger update response messages returned by the target bridgehead. The MTA moves these response messages between target & originating bridgeheads. Part C: From the requesting site's log (later): The responses are received by the originating bridgehead. 1099 During intersite replication, the directory replication agent (DRA) received a message with a length of 102014 from the directory at . ("Message length" will match target site's compressed response message size logged in its' 1100 event from Part B: above). 1099 During intersite replication, the directory replication agent (DRA) received a message with a length of 210486 from the directory at . ("Message length" will match target site's response message size logged in its' 1100 event from Part B: above). End log examination. As mentioned above, this A, B, C sequence is repeated until there are no more updates to return regarding a given context. That is, after processing each batch of updates that are returned, the originating site will requests more updates for that context "starting with USN xxxxxx", but the target has no objects above that USN value to return. In the case of the error documented in this article, the signature behaviors are as follows: - The target site will return a large message to the originating site, but after processing this update, no changes in the Directory appear. - The A, B, C sequence documented above will not continue. - The "Reps-From, Replica-Link, USN" value of the target-context (site or site-configuration) will not increase. To examine the appropriate "Reps-From, Replica-Link, USN," perform the following steps: 1. Launch Admin in raw mode against the originating server. 2. Select the "\" or "\\Configuration" object. 3. From the File menu, select Raw Properties. 4. In the Object Attributes box, highlight the "Reps-From" object attribute. 5. Click the Viewer button, highlight "Replica Link," and then click OK. 6. Note the USN value listed. Furthermore, if a subsequent request for an update to that same context is manually performed, it can be noted that the target site will again log the same USN value in the 1070 event (documented above in Part B). This confirms that the update response message isn't reaching the originating site, or that the originating site is not processing the message that is returned to it. If a 1099 event is logged in the originating site (Part C, above), thus confirming that the update response has been received by the originating DRA, but no updates appear, it is likely that the message is being discarded. Additional query words: ====================================================================== Keywords : exc4 exc5 Technology : kbExchangeSearch kbExchange500 kbExchange400 kbZNotKeyword2 Version : winnt:4.0,5.0 Issue type : kbprb Solution Type : kbfix ============================================================================= 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. Copyright Microsoft Corporation 1999.