Microsoft KB Archive/927053
Article ID: 927053
Article Last Modified on 10/11/2007
- Microsoft Windows Server 2003 R2 Datacenter Edition (32-Bit x86)
- Microsoft Windows Server 2003 R2 Datacenter x64 Edition
- Microsoft Windows Server 2003 R2 Enterprise Edition (32-Bit x86)
- Microsoft Windows Server 2003 R2 Enterprise x64 Edition
- Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86)
- Microsoft Windows Server 2003 R2 Standard x64 Edition
- Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
- Microsoft Windows Server 2003, Enterprise Edition
- Microsoft Windows Server 2003, Standard Edition (32-bit x86)
- Microsoft Windows Server 2003, Web Edition
When you use the Active Directory Application Mode (ADAM) Synchronizer (Adamsync) tool to perform an aging check in Microsoft Windows Server 2003, random objects may be renamed and then moved into the ADAM Lost and Found container.
When you delete an Active Directory directory service leaf object on the source computer and then perform an aging check, the object is deleted from the destination computer. During this process, a query is run to retrieve all the child objects that belong to the leaf object. If there are no child objects, the depth of the leaf object is calculated incorrectly. Any objects that are present in the Lightweight Directory Access Protocol (LDAP) frame are incorrectly identified as the child objects of the deleted object. (The LDAP frame is returned by an LDAP query that is performed during the aging check.) These objects are then renamed by using GUIDs and moved to the Lost and Found container.
To work around this problem, manually delete objects from ADAM that are no longer required.
Microsoft has confirmed that this is a bug in the Microsoft products that are listed in the "Applies to" section.
The following scenarios do not require that you use the Adamsync aging check:
- You delete a user in Active Directory and then resynchronize data between Active Directory and ADAM. The Adamsync tool deletes the user in ADAM if the search filter does not use the objectCategory=xxx option.
Note If the search filter uses the objectCategory=xxx option, the deleted objects in Active Directory are not deleted in ADAM. This is because the objectCategory option is stripped from tombstones. In this case, you must use the workaround.
- You move an Active Directory user out of the scope of the ADAM synchronization base distinguished name and then resynchronize data. The Adamsync tool deletes the user in ADAM.
- You move a group and its members from the Adamsync base distinguished name to another organizational unit. During resynchronization, the Adamsync tool deletes the group from ADAM and then cleans up the dn-ref (memberOf) attributes of the ADAM users who are still in scope.
- You delete an non-leaf object than is in scope and then resynchronize data. The Adamsync tool deletes the object and then moves the child objects to the Lost and Found container.
Steps to reproduce the problem
In the Adamsync configuration XML file, set the aging frequency attribute to 1 as follows.
. . . <aging> <frequency>1</frequency> <num-objects>0</num-objects> </aging> . . .
- At a command prompt, type the following command, and then press ENTER:
server_name:portis the name of the ADAM server and its port.
config_nameis the ADAM partition that is specified in the configuration XML file.
- Delete one or more objects in Active Directory.
- At a command prompt, type the following command, and then press ENTER. This command performs an aging check for all objects.
- When you use the ADSIEdit tool or the LDP.exe utility to view the ADAM partition, you see that the ADAM Lost And Found container holds random objects that have not been deleted in Active Directory. These objects have all been renamed as GUIDs. When you view the attributes of one of these objects, you can see its original name.
Keywords: kbtshoot kbactivedirectory kbprb kbactivedirectoryrepl kbexpertiseadvanced KB927053