LEX Online Manual Content

Moving Directory Objects

LEX can move objects from one LDAP container to another. The destination container has to be in the same LDAP hierarchy which LEX is currently connected with. If you want to move an object, there are several different ways to do this:

To move a new object, you first have to select it either in the treeview panel or the object list panel in the LEX main window. If you are in the object list, you also could select several objects and move them all together to another directory.
You can use now the menu option Edit - Move Object to open the Choose Destination Container dialog.
Or you just use the Move Container / Move Object option from the context menu (right mouse click in the treeview or object list).
There may be situations where the options and buttons for moving objects may be disabled. This might be if the LEX ReadOnly Mode is active, or when the application focus lays on the attribute list.

This is the Choose Destination Container dialog. In this window you can decide where to move the regarding object(s):

Choosing the destination for a move operation

Referential Integrity for renamed Objects

Moving objects relies on an basic LDAP protocol method which is called 'Modify DN', because the storage place in the directory is contained in the object's distinguished name. So if we want to move object from one container to another, we actually change the distinguished names of these objects.

The Lightweight Directory Access Protocol LDAP is specified in RFC 4511. A good description of the LDAP protocol can also be found at the LDAP description page at the SelfADSI LDAP Scripting tutorial.

There is a general problem when objects are to be moved: If the DN of an moved object was stored in an attribute of another directory object - what happens with this attribute after the move operation?

A common example for such references to other objects are group memberships attributes. But there are other attributes as well which holds references and should be considered when renaming objects. This is how the different directory services handles this issue:

	Active Directory: References to other objects will be adjusted automatically by the server when objects are renamed. This is true for all attributes with DN content. A special case: There could be references even to objects in other domains in universal groups. This is more complicated, because these are objects outside of the server's own directory domain database. In this scenario the domain controller with the FSMO role 'Infrastructure Master' performs the adjustment for such references.
	OpenLDAP: When objects are renamed, OpenLDAP can adjust the references in other attributes, but it needs a special plug-in (a so called overlay) for this: For this purpose you have to activate the overlay RefInt (Referential Integrity, slapo-refint) on the OpenLDAP server.
	Novell eDirectory: References to other objects will be adjusted automatically by the server when objects are renamed - this is true for all attributes with DN content.
	Sun iPlanet / Sun Java System Directory Server: When objects are renamed, a Sun Directory Server can adjust the references in other attributes, but it needs the activation of a special plug-in for this: Referential Integrity dsconf set-server-prop -h <server> -p <port> ref-integrity-enabled:on After this configuration you have to restart the whole server daemon, furthermore you have to configure all the attributes which are to be monitored by the Referential Integrity plug-in: dsconf set-server-prop -h <server> -p <port> ref-integrity-attr:member dsconf set-server-prop -h <server> -p <port> ref-integrity-attr+:<attribute-name>
	Microsoft Exchange 5.5: An Exchange 5.5 cannot handle such references on name changes. Therefore object renaming is not allowed and all trials to rename an object will be suppressed and an error will be returned.

Moving Subtrees

Some directories don't allow moving or renaming objects which have child objects. This is also called 'Subtree Move/Rename'. Examples are older versions of Novell eDirectory, or OpenLDAP server where other backend database than hdb-db are used.

But LEX can handle this if you want: The container structure of the subtree which is to be moved is copied to the destination. After the same container structure exists at the destination, all the leaf objects which are stored in the source containers are moved - this move is real and preserves all the attributes:

Special subtree move by LEX

This LEX technique is called 'Subtree Cloning'. Please note that the containers (and only those) will be NEW objects in this case! If you source container object have important attribute properties, they are lost, because the copy operation of the container structure just takes the object names of the containers and doesn't transfer any attribute!

So if you are connected to an LDAP server which does not allow subtree move/rename, and you want to perform such an operation, you have to decide whether LEX should do the subtree cloning for you. Normally this message appears now:

Subtree move/rename warning message

If you want LEX to do the cloning without warning, just go to the application options (menu Tools - Options - Dialogs) and deactivate the Ask for subtree cloning if the directory doesnt support container renaming or moving option -or just click on the Don't show this dialog again.