Microsoft Knowledge Base

XADM: Removing Orphaned Directory Objects

Last reviewed: June 10, 1997
Article ID: Q158521
4.00 WINDOWS kbusage

The information in this article applies to:

  • Microsoft Exchange Server, version 4.0

SYMPTOMS

Non-valid directory objects will occasionally remain in some directories even though they have been removed from the source server\site. For example, a mailbox that was deleted a week ago might still be visible in other servers or sites.

CAUSE

This might be due to replication problems or expired tombstones, or even a mismatch of restored or newly installed directories.

RESOLUTION

It is possible to delete an orphaned object if you know the exact distinguished name (DN) of the orphaned object. The directory value Obj- Dist-Name (for Object Distinguished Name) can be found for every object in the directory by looking at the object's raw-properties. This value will include the full path to the object's place of origin. For instance, the Obj-Dist-Name for a mailbox can have the following format:

   /o=Organization/ou=Site/cn=RecipientContainer/cn=UserA

When an object is deleted, a tombstone is left behind and it gets replicated to all other servers in the organization. It is the tombstone that actually causes the deletion of the object in all other directories. If the tombstone is not replicated or expires before it can get replicated, then you will end up with directory objects that will not get deleted. The default tombstone age limit is 30 days and can be changed on the "DS Site Confiruation Properties" object, General tab.

Deleting the Orphaned Object

To delete the orphaned object, a new tombstone must be created and then replicated to the rest of the organization. To do this:

  1. Find the Obj-Dist-Name of the orphaned object. To find this:

    a. Run Microsoft Exchange Server Administrator in raw mode (admin /r).

    b. Select the orphaned object. On the file menu click Raw

          Properties.
    

    c. Look for the Obj-Dist-Name attribute and note the value given for it.

  2. Examine the Obj-Dist-Name value and determine the source of the object. When looking at this entry, the first two values always refer to the organization and site names; the rest of the values refer to the containers under the site hierarchy. For example, consider this value:

          /o=Microsoft/ou=Northamerica/cn=Recipients/cn=JohnD
    

    The /O= value points to the organization and/OU= refers to the site name. The following /CN= refers to the recipient container were the object exists, and the last /CN= refers to the users DN (same as alias name). There is always at least one /CN value in addition to /O and /OU.

  3. Once the origin of the orphaned object has been identified, create an identical object through the Microsoft Exchange Server Administrator program on the original site and container(s).

  4. Wait for replication to take place or force it. The server that contains the orphaned object will see this update and ignore it because the object already exists in its directory.

  5. Once replication has taken place, delete the temporary object you created in step 3. This will create a tombstone for this object that will get replicated throughout the organization and will eventually delete the orphaned object.

The orphaned object should disappear once directory replication has taken place throughout the organization.


KBCategory: kbusage
KBSubcategory: XADM
Additional reference words: 4.00
Keywords : XADM kbusage
Version : 4.00
Platform : WINDOWS


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.

Last reviewed: June 10, 1997
©1997 Microsoft Corporation. All rights reserved. Legal Notices.