The information in this article applies to:
SYMPTOMSAn object persists in the directory of a remote site even though the object has been deleted from its original site. CAUSETypically, the site that still contains the object failed to receive a replica of that object prior to the object's tombstone expiring. Once an object's tombstone expires, it is no longer considered an "object," and is not replicated. See MORE INFORMATION, below. RESOLUTIONThere are two possible approaches to resolution: re-creating the orphaned object in its "original context" or re-orienting replication bridgehead servers. The second method has a slim chance of resolving the issue, but may be worth a try if the Tombstones of the deleted objects have only recently expired in the feeder site. Method 1. Re-create the Orphaned Object in Its "Original Context"
Method 2. Re-orient Replication Bridgehead ServersThis method involves re-orienting replication bridgehead servers between the site maintaining the orphan and the site that "feeds" that context to the orphan site. This assumes that at least two servers in each site exist, and that the servers that are not currently replication BHs can assume this role, at least temporarily. This will result in a full refresh of all objects from all contexts previously provided by the "feeder" site; thus including the refresh of the orphan object context.NOTE: A third option would be to break the replication connector between the orphan site and its "feeder" site. This should only be a last resort, because it has a much higher impact on other servers in the site and any downstream sites, and certainly should avoided in larger organizations when the orphan site is also a "feeder" site to additional downstream sites. MORE INFORMATIONObject Deletion, Tombstone Lifetime, Tombstone Expiry, and Garbage Collection IntervalWhen a directory object (also known as a specific Naming Context or NC) is deleted (be it a mailbox, Customer Recipient (CR), Distribution List, Connector, and so on, hidden or not), a tombstone property (date and timestamp that the delete of the object was performed) is added to the object[ASCII 146]s properties, an "IsDeleted" attribute is added and set to TRUE, and the object is "hidden" from view.These attribute changes should result in the replication of this "new" version of the object to ALL other directories. Within each directory, a garbage collection thread routinely executes (based on value specified for site\Configuration\DS Site Configuration\Garbage Collection Interval) and removes objects whose "IsDeleted" attribute is TRUE, and whose tombstone property is older than: the current date\time minus the value specified forThe defaults for Tombstone Lifetime and Garbage Collection Interval are 30 days and 12 hours, respectively. So, by default, any object whose tombstone (date the object was deleted in the Administrator program) is older than 30 days (from "now") will be garbage collected (which actually means having most properties stripped off, leaving only a small stub in the directory). Orphaned ObjectsIf conditions (configuration, hardware or network problems, and so on) prevent one or more other sites (or local site directories) from receiving an update of a naming context (NC) during the tombstone period, these other sites (and servers) never find out that the objects have been flagged for deletion. Once the tombstone expires in the originating site, the object is removed from that site's directory, and there is no longer an object to replicate. Since the tombstone never replicated to some other servers, and since the only writable copy of the object has now been deleted, these objects are orphaned in site(s) that never received a replica of the object with the "IsDeleted" flag and tombstone "timestamp".WARNING: Tombstone lifetime and Garbage Collection Interval are site-wide attributes. Reducing the Tombstone lifetime within a site to a value of only a few days can increase the possible occurrence of orphaned objects - particularly in large organizations, where it can be more difficult to assess the state of replication organization wide. There is little to gain from reducing this value, and it is not recommended. The minimum value is two days. WARNING: Use of "MTACHECK /RD" to remove directory replication messages from a backlogged MTA queue may contribute to orphaned objects. This procedure should NOT be used as a routine method of reducing MTA backlogs. The real solution is to find the cause of the backlog, and resolve that problem. If it is determined that directory replication scheduling has been set to "ALWAYS", and that this has resulted in MTA queue backlogs, then "MTACHECK /RD" might be appropriate AFTER scheduling has been correctly set. Determining the Original Context of Orphaned ObjectsView the object's raw properties. The following attributes can be revealing:
Additional query words:
Keywords : kbusage XADM |
Last Reviewed: April 14, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |