> Ahem - Children? Of a user account? What do you mean by that.... only
Well, I am not attempting to copy a user object. I copying a
organizationalUnit with four subcontainers that in turn have non-container
Well, copying a class that you know the scehma of at design time is no
trouble at all. Then you know exactly what properties to copy and what
properties not to copy. (This is not a problem if the parent is different
from the parent of the object you attempt to copy.) If you attempt to copy
an organizationalUnit you know that the name of the object is the ou
attribute so you don't copy that.
But what if you don't know the class at design time? Should you skip ou,
cn, dc or... ? In order to find out what properties to copy or not you need
to parse the schemaEntry.
The above is not a problem if the parent is different from the parent of the
object you attempt to copy since the distinguishedName will reflect the
parent and you can keep the name of the original.
Some properties depend on each other, like the name of the object and the
distinguishedName. This one is simple but although I can't think of an
example I believe there are other attributes that are automatically managed
by ADSI, ADAM or AD. Like SIDs and GUIDs.
I probably find this difficult because I lack a deep understanding of the
ADSI implementation and AD/ADAM. But getting a NotImplemented exception from
ADSI tells me that maybe even MS found a generic CopyTo method a tad
difficult. What I don't understand is why they just didn't leave out the
method altogether to avoid confusion. Could it be that ADSI uses som
directory-dependent implementation beneath the surface and som directory
services actually support this operation?